[systemd-devel] nftables

[Daniel Wagner]

Hi Daniel,

On 02/22/2016 11:39 AM, Daniel Mack wrote:
> On 02/22/2016 11:04 AM, Daniel Wagner wrote:
>> On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:
>>> I haven't been following the recent (well... the last ~2 years ^^')
>>> work on nftables but I believe there are still people using the
>>> iptables format. The use the iptables- nftables compatible tool, and
>>> it mimics iptables through nftables. Verify it, but if it's the
>>> generic way, then it would be as usual in ConnMan.
> 
> It aims for that, yes, but in my tests there were quite some uncovered
> corner cases when it comes to command line compatibility. But I wonder
> why this is related to ConnMan - does it call out to the binary?

We are using libxtables direcly which is a huge pain as it was never
design to be used as we do it. We didn't want to call iptables via shell
all the time.

>>> If not, then you will have to come with a strategy that fits all. And
>>> that's when it
>>> might become tricky. As you noticed, ConnMan will have to avoid conflicts.
> 
> I haven't followed the discussions. What kind of conflicts is this about?

For iptables, we are maintaining our own input and output chain and
insert into the main chain. And than we hope no one is killing the
chain. It gets tricky after crash or restart to sync up correctly.

In short we toetipping around trying to avoid to mess with other
iptables rules.

>>> I believe it will be a bit easier than with iptables though.
>>> - you pull the current context:
>>>   -> if there is nothing, it will be easy ConnMan will just push
>>> whatever it will want.
>>>   -> if something is there, integrating will have to play nice.
>>> Basically: finding the
>>>     input entry point to jump on a custom ConnMan table (you'll probably
>>> need that
>>>     for each IP version), get you rules applied or return if nothing.
> 
> IMO, ConnMan, or any other tool for that matter, should never mess with
> rules it hasn't created itself.

Yes, completely agree.

> nftables makes this easy, as it allows
> for namespaces in the rule sets, through custom tables. 

Ah, so that sounds like I was looking. This is the answer to my initial
question :)

> If any other
> tool installs other tables with conflicting rules, I don't think ConnMan
> should care really.

That is the plan.

> With iptables, this is just a bit trickier due to
> the custom jump label that you have to install in the INPUT and OUTPUT
> chains.

Yep.

> Right now, there are two parts of systemd that touch packet filter
> configurations, nspawn and networkd, and the code already takes care of
> not touching any rule that it has no business with.
> 
>> Lennart posted the headsup on systemd moving from iptables to
>> nftables [1]. I don't know how far those plans have gotten but I think
>> it would be good idea to coordinate this with systemd-networkd.
>>
>> @Tom do you happen to know what the status is on this?
> 
> It was me who worked on this, and I postponed the branch a while ago
> until we know how the kernel APIs look like that we want to use for a
> per-unit packet filtering mechanism. Back then, it looked like this
> could only be achieved with nftables, which is why I reworked all the
> code in systemd.

Ah, I though Tom was working on this. Sorry about that.

> Now, things are not that clear anymore, so the decision was postponed. I
> hope to catch up with this soon, but eventually, I think we should move
> to nftables as well. Note, however, that iptables and nftables may
> coexist on a system.

My hope is that if ConnMan just uses nftables, the kernel needs to sort
out the problems. I know I live in a naive world. :)

>>> About coding around, it's a bit messy. There is one library,
>>> libnftnl. It's not build on top of libnl. I am not entirely sure, but
>>> I think you can hook your own netlink access functions to it. By
>>> default it uses libmnl... You'll have to verify that. Ask Marcel what
>>> he would prefer as well. Afaik, there is still the plan to move 
>>> ConnMan to ell, so keeping it's custom netlink access would make
>>> sense then, I guess.
>>
>> I really like to avoid coding directly netlink. The libnftnl doesn't look
>> too bad. 
> 
> You can have a look at the outdated branch of mine here:
> 
>   https://github.com/zonque/systemd/commits/nftnl

Thanks for the pointer.

cheers,
daniel