[tproxy] New challenge: a design issue

Ming-Ching Tiew mingching.tiew at redtone.com
Thu Dec 13 06:36:22 CET 2007

Hi there, I just realized a new challenge, and this seems 
potentially more difficult than the older ones. It has to
do with the fundamental difference between tproxy4
and tproxy2.

Let's for convenient sake call the spoofing mechanism
of tproxy4 as early spoofing, ie spoofing is decided
from the start, the code do a bind from the start ! 

And in tproxy2 I call it as late spoofing, ie spoofing occurs 
later after OS routing has been made ( correct me if I am 
wrong, that's what I noticed from the behaviour of the 
system ).

But how does it affects squid then ?

In squid, there is this thing call 'tcp_outgoing_address',
basically this is a mechanism where squid could select
an outgoing (source ) address, base on elaborate ACL
mechanism available in squid. For example, one can
select an outgoing address based on the URL he wants
to visit.

With tproxy2, they both work together, the packets
starts off with the selected tcp_outgoing_address,
which allows the operating system to make a policy 
routing based on the source address, and then subsquently, 
the tproxy takes over to spoof using the original http request 

However, in tproxy4 this feature cannot coexist with
early spoofing. Either I use squid's tcp_outgoing_address
or I used the spoof-ed sender address. And for tproxy users, 
spoofing sender address is more important, and therefore 
there is no way to use squid's ACL to influence the outgoing 
path. All outgoing path decisions will have to be made 
external to squid then.


More information about the tproxy mailing list