Add nftables::simplerule

[nbarrientos]

Add a Firewall-like interface covering some simple cases to ease migration of rules.

Closes #17.

[LionelCons]

Good start!

My initial comments (subject to discussion) are the following.

I do not see where $setname is used.

There should be both dport and sport parameters. They should accept an integer or an array of integers.

Similarly, there should be saddr and daddr parameters accepting a string or an array of strings.

There is the question of IPv4 versus IPv6. I wonder whether the proto should be for instance tcp (= TCP for IPv4 and IPv6) or tcp4 (= TCP for IPv4) or tcp6 (= TCP for IPv6). If not, we might need a way to differentiate ip and ip6.

[nbarrientos]

I do not see where $setname is used.

Yup, it's a leftover (I used nftables::set as starting point). It's fixed now, thanks.

There should be both dport and sport parameters. They should accept an integer or an array of integers.

I've implemented a richer dport, allowing a single port, a range and an array of ports. The same could be done for sport.

Similarly, there should be saddr and daddr parameters accepting a string or an array of strings.

This is tricky as the matcher for the rule would be different if the address (or the range in CIDR notation) is an IPv4 or an IPv6 one. It could be a single parameter of type Array[Variant[Stdlib::IP::Address::V6, Stdlib::IP::Address::V4]] and then in the template depending on the type of the element we do ip or ip6 in the statement.

[LionelCons]

Thanks for these changes.

For ports, please note that there is also the question of port names. Do we allow port=>'http'? If yes then it is more flexible but there will be less data validation (I mean more invalid data allowed).

For addresses, there is a similar question: do we allow set names like in saddr=>'@trusted-ips'?

In this tradeoff between flexibility and data validation I don't know where to put the cursor...

[nbarrientos]

I've just added a proposed implementation for daddr and the counter bit. I won't add the dual saddr and sport until we've reached satisfactory implementations and interfaces for their counterparts. I'll stop here for the time being, lemme know what you think.

[nbarrientos]

For ports, please note that there is also the question of port names. Do we allow port=>'http'? If yes then it is more flexible but there will be less data validation (I mean more invalid data allowed).

Yes, it makes sense, but what about dport => ['http', 'https']? That should be legal too.

[traylenator]

Yes, it makes sense, but what about dport => ['http', 'https']? That should be legal too.

No. Espeically since you are permitted numerics in service names the validation loss is too great and your never know what is in the /etc/services file on the destination host exactly.

[duritong]

I like it so far

[nbarrientos]

So, shall I implement saddr and sport and document the interface? What do we finally do about the destination table? What about iifname and oifname?

[traylenator]

So, shall I implement saddr and sport and document the interface? What do we finally do about the destination table? What about iifname and oifname?

saddr and sport I would say are useful, apart from anything else it's presumably same code as daddr and dport.

As for i/oname can leave for now and add later if requested. It would be reasnable request.

[nbarrientos]

sport and saddr added. Some documentation added, too.

[duritong]

all good, but you need to rebase

[traylenator]

@LionelCons anything to add ?

[LionelCons]

Yes, I have something to add...

This is excellent work, thank you very much!