Re: [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 25, 2023 at 11:10:17AM +0000, Jeremy Sowden wrote:
> On 2023-03-25, at 11:35:47 +0100, Phil Sutter wrote:
> > On Fri, Mar 24, 2023 at 11:59:04PM +0100, Florian Westphal wrote:
> > > Jeremy Sowden <jeremy@xxxxxxxxxx> wrote:
> > > > +ip daddr 10.0.0.1 tcp dport 55900-55910 dnat ip to 192.168.127.1:5900-5910/55900;ok
> > > > +ip6 daddr 10::1 tcp dport 55900-55910 dnat ip6 to [::c0:a8:7f:1]:5900-5910/55900;ok
> > >
> > > This syntax is horrible (yes, I know, xtables fault).
> > >
> > > Do you think this series could be changed to grab the offset register from the
> > > left edge of the range rather than requiring the user to specify it a
> > > second time?  Something like:
> > >
> > > ip daddr 10.0.0.1 tcp dport 55900-55910 dnat ip to 192.168.127.1:5900-5910
> > >
> > > I'm open to other suggestions of course.
> >
> > Initially, a map came to mind. Something like:
> >
> > | dnat to : tcp dport map { 1000-2000 : 5000-6000 }
> >
> > To my surprise, nft accepts the syntax (listing is broken, though). But
> > IIUC, it means "return 5000-6000 for any port in [1000;2000]" and dnat
> > does round-robin?
> 
> That does ring a bell.  IIRC, when I initially looked into this, I did
> have a look at maps to see if they might already offer analogous func-
> tionality.
> 
> > At least it's not what one would expect. Maybe one could control the
> > lookup behaviour somehow via a flag?
> 
> Thanks for the suggestion.

Yes, one possibility would be to explore a new flag in the NAT engine.

As said in previous email, this really has to work with NAT maps in nftables.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux