[tproxy] [tproxy,regression] tproxy broken in 2.6.32

[KOVACS Krisztian]

Hi,

On szo, nov 28, 2009 at 12:36:14 -0500, jamal wrote:
> On Sat, 2009-11-28 at 18:07 +0100, Patrick McHardy wrote:
> 
> > Right, its source validation. But the setup is valid, its asking for
> > specifically marked packets to be delivered locally for transparent
> > proxying. There's no requirement that rules using marks must resolve
> > to RTN_UNICAST.
> 
> True, but that requirement is needed for source validation;->
> i.e it is source address validation imposing the requirement
> that we must have a RTN_UNICAST route. The tproxy iproute setup entered
> a route that was not RTN_UNICAST. I think that the packet deserves to be
> beaten with a club then dropped hard into an abyss (Feel free to come up
> with  something more medievial to do to it Patrick;-> )
> 
> It doesnt make sense to have a source address that is not unicast
> belonging to a host or pretending to belong to a host.

The source address *is* unicast. 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. Your modification has
the assumption that routing is symmetrical, and that reply packets will
have the same mark. That assumption is not necessarily right, and I think
it's not entirely unreasonable to think that not only tproxy setups will
be broken by the change.

> So i didnt introduce that logic thats causing this pain.

Well, it depends whether or not you consider the initial setup valid.

> If it worked before it was hack or fluke imo ;-> If we think that
> source address validation needs to check for something else
> additionally, i think thats a separate topic (but doesnt
> seem worth a change)

My only concern is that this definitely breaks current setups, and while
we do have a workaround we don't have a way to let all users know what
needs to be done...

-- 
KOVACS Krisztian