Re: [PATCH] %>la for intercepted connections

On 08/09/11 02:21, Tsantilas Christos wrote:
> On 09/07/2011 05:03 AM, Amos Jeffries wrote:
>> On Tue, 06 Sep 2011 19:04:29 +0300, Tsantilas Christos wrote:
>>> I am sending a new patch which does not touch the current ">la"
>>> formating code but instead adjust the "la" formatting code to follow
>>> rules as discussed by Amos.
>>>
>>> Please look in the cf.data.per documentation and the
>>> LFT_CLIENT_LOCAL_USED_IP/LFT_CLIENT_LOCAL_USED_PORT enum names I am
>>> using...
>>>
>>
>> * LFT_LOCAL_LISTENING_ would be a bit more descriptive for the enum. The
>> documentation could also use the word "listening" to be clearer on where
>> it comes from.
>> ie:
>> + la Local listening IP address the client connection uses.
>> + lp Local listening port number the client connection uses.

Perhapse: s/uses/was connected to/

That would avoid implication that the client software has a choice
and/or knowledge of the IP.

>
> I have my doubts that the listening IP address is what we want to log here.
>
> Normally an administrator needs to now the IP address the client
> connected to. It needs the IP address and not listening address.
> In the case of intercepted connections this information does not exist
> so why not get this info from listening IP address?
> Moreover it is practical to have ONE formating code for the above (eg
> easier to create a script for log analysis)
>

Your clients scripts apparently need to record Squid receiving IP for
some kind of analysis.

There is an email from a consultant in Africa waiting to be approved
moderation in squid-dev (I got it already via netfilter). Who needs to
reliably and definitively match logged details to packet flow measurements.

To cater for both sets of user requirements we must have tags which can
log both details individually and simultaneously with no confusion as to
whether the data is coming from the packet or the receiving squid port.

  I would prefer only using al->cache->port->a.local for IP same as
port, but this would show dashes in the forward/accel traffic to a
wildcard listener. This case client destination was guaranteed to be
the proxy itself and we can safely avoid the dash by using
tcpClient->local. In all other cases the receiving IP is configured as
listening port in http_port or undefined.
  See the scenarios below.

>>
>> * The IP address display needs a re-structure. al->tcpClient is possibly
>> a backup source on non-intercepted requests if cache.port->s.IsAnyAddr()
>> [only this case]. Otherwise always use cache.port->s or dash.
>>
>> + case LFT_LOCAL_LISTENING_IP:
>> + if (al->cache.port == NULL) {
>> + break; // dash
>> + } else if (al->cache.port->s.IsAnyAddr()) {
>> + if (al->tcpClient != NULL &&
>> + !(al->request != NULL && (al->request->flags.spoof_client_ip ||
>> al->request->flags.intercepted))) {
>> + out = al->tcpClient->local.NtoA(tmp, sizeof(tmp));
>> + } // else dash.
>> + } else {
>> + out = al->cache.port->s.NtoA(tmp, sizeof(tmp));
>> + }
>> + break;
> My original code was not good, I agree...
> I have in my mind something like this:
> case LFT_LOCAL_LISTENING_IP:
> + if ((al->request->flags.spoof_client_ip ||
> al->request->flags.intercepted) && al->cache.port) {
> + if (!al->cache.port->s.IsAnyAddr())
> + out = al->cache.port->s.NtoA(tmp, sizeof(tmp));
> + } else if (al->tcpClient != NULL)
> + out = al->tcpClient->local.NtoA(tmp, sizeof(tmp));
> + break;
>
> If it is an intercepted connection use the listening address (if it is
> available), else use the IP address used by the client to connect to squid.
> Is it OK?
>

That seems okay. Confusing to read, but is slightly more efficient than
what I suggested with the same cases covered.

For the record these are the permutations we seek to cover...

Scenario 1: client 192.168.0.3 connects to google (74.125.237.81). Gets
intercepted into Squid.

1a) squid.conf: http_port 3129 intercept|tproxy

  tcpClient->remote == 192.168.0.3:$random (%>a:%>p)
  tcpClient->local == 74.125.237.81:80 (%>la:%>lp)
  al->cache.port->s.local == 0.0.0.0:3129 (%la:%lp) [log "-"]

1b) squid.conf: http_port 192.168.0.1:3129 intercept|tproxy

  tcpClient->remote == 192.168.0.3:$random (%>a:%>p)
  tcpClient->local == 74.125.237.81:80 (%>la:%>lp)
  al->cache.port->s.local == 192.168.0.1:3129 (%la:%lp) [log 192...]

Scenario 2: client 192.168.0.3 connects to Squid asking for
http://google.com

2a) squid.conf: http_port 3128 [accel]

  tcpClient->remote == 192.168.0.3:$random (%>a:%>p)
  tcpClient->local == 192.168.0.1:3128 (%>la:%>lp)
  al->cache.port->s.local == 0.0.0.0:3128 (%la:%lp) [log 192...]

2b) squid.conf: http_port 192.168.0.1:3128 [accel]

  tcpClient->remote == 192.168.0.3:$random (%>a:%>p)
  tcpClient->local == 192.168.0.1:3128 (%>la:%>lp)
  al->cache.port->s.local == 192.168.0.1:3128 (%la:%lp) [log 192...]

Senario 3: squid generates an internal request.

  tcpClient == NULL (%>a:%>p,%>la:%>lp) [log "-"]
  al->cache.port == NULL (%la:%lp) [log "-"]

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.15
   Beta testers wanted for 3.2.0.11