On 1/11/2013 6:30 a.m., WorkingMan wrote:
TPROXY is not routing. It is packet interception, taking a packet from
the kernel TCP stack and delivering it to a local process running on
that machine. Taking packets from that same local process marked with a
special TPROXY flag and allowing them to be routed despite having a src
address of a different machine (spoofing is normally prohibited by the
kernel).
Simple really. But it places a lot of requirement pressure on the
networking and routing to handle the packets properly.
The alternative for remote host is policy based routing (if you followed
my
other thread on this for ipv4 but ipv6 should not be too different). But
as I
said before I am not able to make it work.
Unfortunately the policy routing is mandatory whenever there are
alternative routes for the packets to travel over which bypass the
interceptor proxy.
Amos
Does TPROXY setup work with remote proxy server?
That depends on how you define "works".
TPROXY (as in the particular kernel packet handling feature) is only
working on a single machine and the proxy MUST be running on that
machine. "remote" has no meaning when we are talking about data
travelling between a machine kernel and a process that kernel is running.
All the problems about local/remote are with packets reaching that
kernel in the first place. And properly configured routing works in most
cases. The difficult part is that TPROXY operates on a proxy machine
(P), packets leaving the client machine (C) have destination IP:port of
a origin server (O). If you do manage to get those packets to machine
(P) the packets leaving (P) are also addressed with source (C) to
destination (O).
How are Internet machines between (P) and (O) to know that a reply
packet addressed from (O) to (C) is actually to be delivered to (P) ?
This is a problem. You can solve in several ways:
1) having both (C) and (P) on a shared network where all the routing
infrastructure has been configured to send port-80 traffic via the (P)
machine unless specially marked.
2) having (P) configured to mark reply traffic to (C) and (C) configured
to route any non-marked traffic it receives back to (P) for processing.
3) using NAT on the traffic outbound from the gateway used by (P) such
that all the special routing is isolated on the network {
(C)<->(P)<->gateway }.
(NP: TROXY and NAT on the same box dont play nicely, so it has to be
the upstream gateway)
4) using the latest Squid releases spoofing access control to prevent
TPROXY spoofing the (P)<->(O) traffic. Making it half-transparent like
the old NAT interception.
(NP: this does not avoid any routing requirements on the (C)<->(P)
traffic.)
It appears to be for local routing only. I don't want to start trying this
if it will not support remote routing (hint: specify this in the wiki, also
it doesn't say that newer kernel seem to have all the dependency built in
the kernel out of box; and based on configuration I saw it's all there, most
of the guide out there on this is for kernel 2.6x which is old).
It talks about *minimal* kernel versions. We dont have time or enough
space in the document to list every kernel release that contains TPROXY
abilities. Just the minimum version that works, and any bugs known about
specific later kernels.
Hint: there have been no changes to TPROXY configuration since that
2.6 kernel version. If there were you would see wiki notes about changes
and what software they happened in.
Amos
