On 9/06/2015 10:32 a.m., Stakres wrote: > Hi Amos, > > Ok, it does confirm our tests. > > Is there a way to do this: > users -> squid1 tproxy -> squid2/squid3 tproxy -> internet (seeing the user > ips) ? > or is it impossible ? Only by intercepting the squid1 port 80 outgoing connections. cache_peer cannot do that. > > in the wiki, there is an option "no-tproxy" in the cache_peer, it would be > nice to have a "keep-tproxy" I think you misunderstand how TPROXY works. It is part of the *TCP connection* state. There are different TCP connections inbound and outbound from each Squid. Software X opens a TPROXY listening port, TCP connections delivered there are remembered by the kernel. When software X opens outgoing connections and tells the kernel they were received via the TPROXY port the kernel then allows software X to bind() the src/dst IPs on those outgoing TCP connections to any of the IPs it has on the open connections to the TPROXY listening port. Now... * the *dst-IP* on a cache_peer connection is the peer proxy IP. Always, otherwise it would not arrive at the peer. * Squid interceptors will ensure that any port 80/443 outgoing TCP connection is going to the same server TPROXY tells it the client was going to (ORIGINAL_DST). ** Therefore if squid1 has a cache_peer pointing at a TPROXY kernel rule on squid2/squid3 the outbound connections from squid2/squid3 will be guaranteed to be sent back to themselves. Repeat until either squid2/squid3 notices the loop, or the server TCP sockets are all gone, or server runs out of memory, or the TCP networking stack collapses. Whichever occurs first and none of it nice. ** due to CVE-2009-0801. The rather innocent vuln text description is the tip of an iceberg of problems worthy of sinking the titanic. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
