[tproxy] Fwd: Tproxy changes for performing dual NAT

[Balazs Scheidler]

On Tue, 2007-11-20 at 14:26 +0100, KOVACS Krisztian wrote:
> Hi,
> 
> On k, nov 20, 2007 at 12:23:25 +0100, Balazs Scheidler wrote:
> > > > > I'm just working on that issue. I hope I'll be able to finish it this
> > > > > evening, or maybe tomorrow.
> > > > > 
> > > > 
> > > > And what is your solution? I was thinking about something like a
> > > > "natsocket" match, but that looks ugly.
> > > 
> > > I've discussed this with Patrick and we have basically two options:
> > > 
> > > * to use the original source address for SNAT-ted connections (I don't
> > >   think we'd need a separate match: I guess using the SNAT-ted address in
> > >   the socket match is absolutely useless);
> > 
> > Yeah, but in that way the "socket" match would pull in the dependency on
> > the NAT module unconditonally.
> 
> Not necessarily: that part could be enclosed by #ifdef CONFIG_NF_NAT
> guards.

I might be missing something, but if you are talking about compile time
dependency: a kernel might contain both NAT _and_ tproxy in its
configuration, e.g. the dependency in the socket match would be there.
Most distribution kernels are like that.

At runtime you'd pull in the NAT module, even if nothing else uses it,
and even if the user does not have _any_ NAT rules.

This is suboptimal.

> 
> > > * to re-introduce the tproxy table and do the socket matching and marking
> > >   in tproxy.
> > > 
> > > The first option seems pretty ugly and could work for SNAT but does not
> > > solve the problem with DNAT: we have the same incompatibility with
> > > nat/PREROUTING DNAT rules at the moment.
> > > 
> > > The second one is a step backwards and would break our 'user interface'
> > > _again_ (sigh), but I tend to think that it is the only correct solution...
> > > 
> > 
> > I see. 
> 
> Erm, more feedback would be really reassuring... ;)

Would you move the TPROXY target back to this table again?

I was wondering if the name 'tproxy' is the best, can you see any other
useful function of the table apart from tproxy?

a table-to-be-consulted-after-nat :) hmm 'mangle_afternat' or postnat,
or something?

I'm not against naming it tproxy, but the first reason to drop the
tproxy table was to avoid a tproxy specific table.



-- 
Bazsi