> Date: Sun, 16 Feb 2020 01:50:19 +1300
> From: Amos Jeffries
> To: squid-users@lists.squid-cache.org
> Subject: Re: [squid-users] squid-users Digest, Vol 66, Issue 17
>
> On 16/02/20 12:42 am, Scott wrote:
> >> Date: Fri, 14 Feb 2020 11:03:50 -0500
> >> From: Alex Rousskov
> >>
> >> On 2/14/20 10:36 AM, Scott wrote:
> >>
> >>> I know it's derivable by other means, but it would be nice to have a
> >>> logformat format code that provided the client and server IP version
> >>> numbers.
> >>
> >>> eg: >v for Client IP version (4 or 6) and >>
> >>
> >> Other than client and server, Squid can log a few other IP addresses,
> >> including:
> >>
> >> >a Client source IP address
> >> >la Local IP address the client connected to
> >> la Local listening IP address the client connection was...
> >> >> >> icap:: >>
> >>
> >> If we add support for automated IP version extraction, it should be
> >> supported as a single new parameter for all existing %codes that log IP
> >> addresses rather than new %codes (one %code for each of the existing
> >> %codes that log IP addresses). For example:
> >>
> >> %>a{version}
> >>
> >> FWIW, personally, I am not sure we should add such a %code option
> >> because, I presume, the same information can be obtained simply by
> >> checking the first character of the logged IP address for being '['.
> >> Said that, I am open to hearing arguments why it should be added.
> >>
> >>
> >> Cheers,
> >>
> >> Alex.
> >>
> >
> > Thanks Alex,
> >
> > bear in mind that normally Squid handles but two connections (c->squid,
> > squid->peer/origin), despite the fact that there are normally four
> > addresses
> > (client, squid-inside, squid-outside, peer/origin). If it were agreed to
> > support such a logging function, why would one bother having >a{version}
> > and
> >> la{version} when both MUST be the same? Same goes for >
>
> If you are using an IPv6 enabled Squid on a Hybrid-stack machine you may
> notice that it does not have IPv4 listeners at all. Squid talks to IPv4
> clients through IPv6 :: or a v4-mapping address.
>
>
>
> > That's the whole point of "<" and ">". These two qualifiers are linked to
> > the inside and outside IP versions, not the "l" in ">la" and " > why I suggested a new variable "v" with two sides/directions (>/<).
> >
> > As to the suggestion that one differentiate IP versions by the signifier
> > '[',
> > from my experience "%>a" in logformat does NOT provide surrounding square
> > brackets.
>
> For Squid %a codes the more correct sign is when the IP contains
> a ':' it is IPv6 or later.
>
>
> >
> > The argument I would make (and I do appreciate you hearing it) is that
> > programmatically (think grep/awk or pcre filtering) it's much easier to
> > determine how much traffic (client/server) is either v4 or v6 is by using a
> > fixed field rather than positive/negative lookaheads in the address codes
> > (given the lack of []).
>
> IMO it would be better to implement the long outstanding request for
> SNMP counters providing that information. No need to parse the logs then.
>
> Amos
>
I don't believe SNMP is the best place for per-connection metrics/telemetry.
SNMP is better suited to aggregated numerical data.
If I'm already logging proxy connections and gathering per-connection data
such as IP endpoints, URIs, HTTP methods, etc. then I think it also makes
sense to log the IP version. In my case I am very interested in
client->proxy and proxy->peer/origin sessions and whether they are IPv4 or 6.
I would lose all context were the protocol version be stored in some SNMP
gauge. Also having to 'grep' a field to get the version seems a bit b-grade.
It's just a feature request that I thought some other people would also
appreciate. I'll just knock up a patch for myself.
Hey while you're here Amos, did you see a post from me a few days ago
regarding ssl::server_name matching the Host: header in non-TLS connections?
I didn't get any response and was wondering if the documentation should
mention it.
Cheers
Scott
> Date: Sat, 15 Feb 2020 09:58:42 -0400
> From: Felipe Polanco
> To: Amos Jeffries
> CC: Squid Users
> Subject: Re: [squid-users] Question regarding TPROXY and sslBump
>
>Thanks for the reply,
>Speaking strictly about TPROXY, are there any limitations compared to
>regular transparent intercept?
>We have full control of the network and TCP routing.
>We have done regular https intercept in the past and is working fine,
>but now we would like to try TPROXY in bridging mode instead of routing
>mode.
>Thanks,
>
>On Sat, Feb 15, 2020 at 3:17 AM Amos Jeffries <[1]squ...@treenet.co.nz>
>wrote:
>
> On 15/02/20 10:28 am, Felipe Polanco wrote:
> > Hi,
> >
> > Can squid running in TPROXY mode intercept and decrypt HTTPS
> payload
> > with sslBump?
> >
> Maybe. It can do so about as well as NAT intercept
