[squid-users] Squid cache_peer in tproxy

[Amos Jeffries]

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