Re: [tproxy] [tproxy,regression] tproxy broken in 2.6.32
Hi, On szo, nov 28, 2009 at 02:44:02 -0500, jamal wrote:
The source address *is* unicast.
Sorry - I meant the route type is unicast. The fact that an address is unicast or not is already dealt with by the time you get to source address validation (in ip_input())
The problem is that the routing setup is asymmetrical, as Patrick has already mentioned: we're using a mark to force certain packets (those that have matching sockets on the host) being delivered locally.
In the other direction, reply packets won't be marked by the iptables rules and thus will be routed on egress just fine.
In that case i dont understand the reluctance to use unicast routes. Maybe you can explain and put me at ease because i see youve put extra effort to use local addresses.
The short answer is: it doesn't work with unicast routes. The story is that we really do want to deliver these packets locally, as if the destination IP address was locally configured on the host. The only way I know of to get the packet to ip_local_deliver() is by using a local route. (Now that you mentioned this I've actually gave it a try. Changing 'local' in the route to 'unicast' doesn't work at all: incoming packets get dropped because forwarding is not enabled on the ingress interface.) -- KOVACS Krisztian
participants (1)
-
KOVACS Krisztian