Re: [squid-users] tproxy configuration

On 17/07/2012 10:44 p.m., nipun_mlist Assam wrote:
>> what do you want to achieve? everything that can be achieved using WCCP can
>> be achieved in other way with tproxy.
>>
>> Eliezer
>>
> WCCP makes sure that only traffic on some specific ports(generally
> port 80 and 443) goes via Squid box. In case of tproxy all the traffic
> will flow via squid box if it has to work as a router and that may
> affect the performance of the squid box.

The Squid box always has to do routing, even as a regluar proxy. How do
you expect the packets to flow through it unless they are routed to
their destinations?

"All the traffic" is wrong. The Squid box does *not* have to route
everything on the network. Nor even does it have to see anything beyond
port 80 traffic.

The rules you place on the Cisco decide what packets goes to the Squid
box. WCCP is just a tunnel and special routing table. You create regular
policy routing to pass packets through the WCCP GRE tunnel, you can do
the same with a regular interface/outerface straight to pass only only
port 80 or 443 packets to a Squid box "router" without WCCP. The only
thing WCCP actually gains you is ability to split between multiple
caches and easy failover when the cache(s) go down.

> I don't know if the tproxy feature can be achieved without making the
> squid box a router.

No it can't. You just have to understand what a router *is* a bit
better. When the packets arrive they are addressed to places which are
not the Squid box. The kernel TCP security will only allow non-local
packets to enter a box which is a router or bridge. If you choose
"bridge" the packets have to be shifted into router mode for the box NAT
systems to recieve. So either way you need routing just to receive the
packets into Squid.

TPROXY is a method of interception which preserves the client IP (or
IPv6) as if the proxy was not there. Two abilities which NAT
interception cannot provide. It still receives packets from the packet
routing system of the kernel just like NAT.

Amos
Received on Tue Jul 17 2012 - 11:29:56 MDT