[tproxy] Fwd: Tproxy changes for performing dual NAT

[KOVACS Krisztian]

Hi,

On k, nov 20, 2007 at 02:45:59 +0100, Balazs Scheidler wrote:
> 
> 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.

I don't see why I'd force a dependency on NAT this way. To get the
original address I only need the conntrack entry pointer (if we have one).
And that's available even if we don't have NAT or conntrack loaded, it's
just that either nfct is NULL or the NAT_DONE_* bits in the conntrack
entry status field not set.

> > > > * 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?

Well, I guess we don't have any other choice if we would like to support
NAT...

> 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.

That's a good point. Let's ask Patrick.

-- 
KOVACS Krisztian