Re: [squid-users] tproxy2 patch for squid3

>> 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

--