Stéphane Veyret <sveyret@xxxxxxxxx> wrote:
> Le lun. 12 mars 2018 à 16:53, Florian Westphal <fw@xxxxxxxxx> a écrit :
> > > > Something like:
> > > >
> > > > chain postrouting {
> > > > type filter hook postrouting priority 0;
> > > > # tell kernel to install an expectation
> > > > # arriving on udp ports 6970-7170
> > > > # expectation will follow whatever NAT transformation
> > > > # is active on master connection
> > > > # expectation is removed after 5 minutes
> > > > # (we could of course also allow to install an expectation
> > > > # for 'foreign' addresses as well but I don't think its needed
> > > > # yet
> > > > ip dport 554 ct expectation set udp dport 6970-7170 timeout 5m
> > > > }
> > >
> > > It may be what I'm looking for. But I couldn't find any documentation
> > > about this “ct expectation” command. Or do you mean I should create a
> > > conntrack helper module for that?
> >
> > Right, this doesn't exist yet.
> >
> > I think we (you) should consider to extend net/netfilter/nft_ct.c, to
> > support a new NFT_CT_EXPECT attribute in nft_ct_set_eval() function.
> >
> > This would then install a new expectation based on what userspace told
> > us.
> >
> > You can look at
> > net/netfilter/nf_conntrack_ftp.c
> > and search for nf_ct_expect_alloc() to see where the ftp helper installs
> > the expectation.
> >
> > The main difference would be that with nft_ct.c, most properties of
> > the new expectation would be determined by netlink attributes which were
> > set by the nftables ruleset.
>
> Does this mean I should create a new structure containing expectation
> data, as required by the nf_ct_expect_init function, and that I should
> expect to find this structure at ®s->data[priv->sreg] in
> nft_ct_set_eval?
No, that would be too extreme.
I think all the information should be passed as individual netlink
attributes.
In mean time, we gained ability to set timeout policies and conntrack
helpers via nft_ct, I think you can look at how they are implemented
to get an idea of how to gather the data that gets passed to
nf_ct_expect_init().
1a64edf54f55d7956cf5a0d95898bc1f84f9b818
netfilter: nft_ct: add helper set support
and
7e0b2b57f01d183e1c84114f1f2287737358d748
netfilter: nft_ct: add ct timeout support
table ip filter {
ct timeout customtimeout {
protocol tcp;
l3proto ip
policy = { established: 120, close: 20 }
}
chain output {
type filter hook output priority filter; policy accept;
ct timeout set "customtimeout"
}
}
table inet myhelpers {
ct helper ftp-standard {
type "ftp" protocol tcp
}
chain prerouting {
type filter hook prerouting priority 0;
tcp dport 21 ct helper set "ftp-standard"
}
}
So for expectations this might look like this:
table inet foo {
ct expectation myexp {
protocol udp;
dport 6970-7170;
timeout 5m;
dmask 255.255.255.255;
smask 255.255.255.255;
}
ip dport 554 ct expectation set "myexp"
}
nft_ct object evaluation would call nf_ct_expect_alloc() based
on current pkt->skb->_nfct and it would pass all info that is configured in
'myexp' already to nf_ct_expect_init().
The tuples to expect would be taken from pkt->skb->_nfct one.
I think for initial implementation, smask/dmask isn't needed so we
could just use the full expectet address.
Later on, we could extend this to also allow sport, classes, and so on.
Using the obect infrastructure allows to assign the expectation via maps,
without extra code, for example:
ct helper set tcp dport map {21 : "cthelp1", 2121 : "cthelp1" }
ct expectation set ip protocol map { 6 : "tcpexpect" , ...
> When all this is done, I will have to also update the nftables
> command. Will I also need to update the nftables library?
You will need to touch both libnftables and nftables.
You can look at nft/libnftnl history for the helper and timeout support.
