>> Regular client-side transparent proxying is easily accomplished by >> redirecting network traffic using -j DNAT, -j REDIRECT, or -j TPROXY (I do >> not know why this seems needed). However, server-side transparency requires >> a little more kick. >> https://lists.balabit.hu/pipermail/tproxy/2006-July/000273.html >> >> This patch actually brew in my homemade version of squid3 and worked long >> before tproxy even hit the squid2.6 scene. CAP_NET_ADMIN must be accounted >> for >> by the user, and in my case, is easily done through the MultiAdmin linux >> kernel >> module. > >Comments: > >Your patch does not handle persistent connections.
I am not too well into the squid code. I was happy to find the function at all where connection setup is done, since squid is asynchronous. >If there is multiple >clients talking to the same server their requests may get intermixed, no >longer keeping the source IP binding. If multiple client-proxy streams are multiplexed into one proxy-webserver stream, we anyhow have a hard time to bind to all address at once. Does this explain why some client-proxy connections time out after 30 seconds? >Why the commConnectStart2 function instead of extending >commConnectStart? Other places where commConnectStart may be called from would be falsely tproxified, that was the idea. Yes, it's more of a hack rather than a clean implementation. But it did what I need, and, except for some timeout connections every now and then (like 1% of all connections), work. Jan Engelhardt --
