Re: [squid-users] Conditional cache_peer based on transparent/non transparent connection?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 26 Mar 2012 11:32:19 +1300

On 26.03.2012 00:53, Ed W wrote:
> Hi, I have an upstream cache_peer which requires authentication. My
> local network squid accepts explicit proxy clients, and does
> transparent redirection on everyone else.
>
> Clearly I can't use the cache_peer for the transparently proxied
> clients, however, how could I use it only for explicit proxy clients?
> (ie those with a proxy set in their browser). The cache_peer line
> uses login=PASSTHRU so we never get involved with the authentication
> on the local squid
>
> Thoughts on how I could achieve this please (without two squid
> instances)? Squid 3.2.0.16
>

The thing to understand first is that the squid->peer connection is
independent from the client->squid connection. Including proxy login
details.

With PASSTHRU, Squid is instructed to use *exactly* the same login
details as on the client connection. Down to and including absence of
credentials when none are given. If you are intercepting traffic between
the client and that peer, then the browser will have no issues being
challenged by it and presenting credentials that PASSTHRU allows past
(NTLM proxy-auth PASSTHRU can fail due to pinning-related issues).

To answer your question directly:
  * You can use myportname ACL to detect which port the traffic arrived
on and skip the peer.

It may not be necessary to skip the peer though...

* You can use other login= settings than PASSTHRU and supply
credentials for that peer. After all Squid is only seeking permission
for *itself* to relay requests upstream, why should the upstream need to
know your downstream clients login details?

* You can use a combination of myportname and external ACL. So the
myportname determines when the external helper gets runs and that
supplies credentials to get the intercepted requests into the upstream
peer. Non-intercepted traffic (no matching the myportname) gets the
client-supplied credentials.

Amos
Received on Sun Mar 25 2012 - 22:32:25 MDT

This archive was generated by hypermail 2.2.0 : Mon Mar 26 2012 - 12:00:03 MDT