for using TPROXY, you should set up triangle routing that sometimes
make headache. if you don't want triangle routing, you could make your
proxy act as bridge.
It's true that we have invisible proxy, for better you could strip off
the squid signature at the below error page by modifyng the source.
For some sites (like rapidshare) that requires uniqe ip address for
concurency download, it's solved by using tproxy.
for isp, using this proxy (tproxy feature) below bandwidth limiter of
client (not located at above), the client will get faster access, but
not saving the backbone bandwidth.
But if you put this proxy above the bandwidth limiter, it could hog
your backbone. you should put double limiter between this proxy to get
saving backbone bandwidth.
On Sat, May 30, 2009 at 10:23 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> Gavin McCullagh wrote:
>>
>> Hi,
>>
>> there's been a lot of talk about TPROXY being added back into the linux
>> kernel and squid changing to support it.
>>
>> Currently, we do transparent proxying by policy routing port 80 traffic to
>> the proxy server then using DNAT (iptables) on the proxy server.
>> Could someone point me to something that explains the benefit of TPROXY
>> over DNAT? We would look to migrate over if there's a substantial
>> benefit.
>>
>> Thanks in advance,
>> Gavin
>>
>
> The only documentation I know of that attempts to compare is the readme by
> Balabit.
> http://www.balabit.com/downloads/files/tproxy/README.txt
>
> The following is based on my knowledge of TPROXYv4, I can't speak for the
> older obsolete TPROXYv2.
>
> Not requiring NAT to operate it is not limited in quite the same ways. It's
> also much more efficient from an application viewpoint and has the
> possibility of being coded to support other protocols such as IPv6 where NAT
> is not possible. (Though kernel support still has to be written for
> non-IPv4).
>
> The other side is that it is a true source-spoofing mechanism which is both
> a pro and con. It's a real invisible proxy. But triangle-of-doom routing
> causes greater havoc and much harder to fix.
>
>
> Overall, I see it as a much better alternative to the NAT methods if both
> are available to you and one needs to be used. But is not really something
> to normally go out and look for specially.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
> Current Beta Squid 3.1.0.8 or 3.0.STABLE16-RC1
>
Received on Sat May 30 2009 - 12:07:17 MDT
This archive was generated by hypermail 2.2.0 : Sat May 30 2009 - 12:00:02 MDT