[squid-users] TProxy and client_dst_passthru

[Amos Jeffries]

On 4/03/2015 8:19 p.m., Stakres wrote:
> Hi Eliezer,
> 
> Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
> "client_dst_passthru" (off) will stop the DNS entry as explained in the
> wiki, the option directly acts on the flag "ORIGINAL_DST".

You literally have that backwards.

The cause is NAT/TPROXY.
The directive is acting on the NAT mangled dst-IP address (replace it?
yes/no).
The log flag is an effect telling you what was chosen (yes or no answer).


> As you know, ORIGINAL_DST switches the optimization off (ex: StoreID) then
> it's not possible to cache the URL (ex: http://cdn2.example.com/mypic.png).
> 
> In no tproxy/NAT mode, the client_dst_passthru works perfectly by disabling
> the DNS entry control, so optimization is done correctly.

WTF? no (and FWIW I wrote that pass-thru feature).

In "no TPROXY/NAT mode" the client *explicitly* requests Squid to fetch
a URL. Squid looks up DNS for the domain in that URL and contacts any
one of the IPs available.
 There is no client DNS lookup to do pass-thru for. The directive has no
effect whatsoever.


> But in tproxy/NAT, the client_dst_passthru has no effect, we see
> ORIGINAL_DST in logs.

In TPROXY/NAT intercept mode, the client does the DNS lookup and selects
which IP to contact. The NAT/TPROXY diverts the traffic into Squid.
Squid grabs the original client dst-IP from the kernel records. Does a
second DNS lookup to see where the URL was supposed to be going
according to more reliable sources.

 *IF* (and only if) Squid can verify the IP the client selected actually
belongs to the domain in the URL does Squid check the pass-thru directive:
 ON (default) - Squid uses the IP the client was connecting to (logs
ORIGINAL_DST);
 OFF - Squid selects a (possibly new, or not) IP to be used as the
server (logs DIRECT).

 Otherwise, when that dst-IP validation fails, Squid uses the IP the
client was connecting to. The directive has no effect whatsoever.


> 
> So, maybe I'm totaly wrong here the client_dst_passthru is not related to
> the ORIGINAL_DST, or there is an explaination why the client_dst_passthru
> does not act in tproxy/NAT...

client_dst_passthru is simply whether or not to use ORIGINAL_DST in the
cases where it is both available AND optional.
 There are other cases where it is mandatory to use, or is unavailable.


For users the key information is that:

Setting OFF enables HTTP routing optimizations and network error
recovery to take place, but severly confuses people/applications who
dont understand much about HTTP.


Setting ON reduces problems with broken web applications that (wrongly)
assume end-to-end connectivity within HTTP, or that (wrongly) assume all
connections to a given IP are going to end up at the same origin server.
Neither of those assumptions are true for HTTP whether it goes over port
80 or port 443 or a proxy.


Amos