[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
IP.
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.
Regards.
More information about the tproxy
mailing list