On 10.12.2019 20:12, Roman Mamedov wrote:
On Tue, 10 Dec 2019 17:54:49 +0100
"Jason A. Donenfeld" <[email protected]> wrote:
iptables rules and nftables rules can co-exist just fine, without any
translation needed. Indeed if your iptables is symlinked to
iptables-nft, then you'll insert nftables rules when you try to insert
iptables rules, but it really doesn't matter much either way (AFAIK).
I figured I'd prefer nftables over iptables if available because I
presume, without any metrics, that nftables is probably faster and
slicker or something.
nftables is slower than iptables across pretty much every metric[1][2]. It
only wins where a pathological case is used for the iptables counterpart (e.g.
tons of single IPs as individual rules and without ipset). It is a disaster
that it is purported to be the iptables replacement, just for the syntax and
non-essential whistles such as updating rules in place or something. And
personally I don't prefer the new syntax either. It's the systemd and
pulseaudio story all over again, where something more convoluted, less reliable
and of lower quality is passed for a replacement of stuff that actually worked,
but was deemed "unsexy" and arbitrarly declared as deprecated.
[1] http://www.diva-portal.org/smash/get/diva2:1212650/FULLTEXT01.pdf
[2] https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables/
As far as I know both of them are maintained in the same repository and
both use the same userspace library to interact with the kernel and down
there all the rules are translated into BPF code which in turn is
compiled into machine code by kernel BPF JIT compiler. So identical
rules should show exactly the same performance. nft syntax is odd and
its curvy braces aren't easy to pass in command line, it is more
difficult to delete rules from nft table, but it also allows to arrange
rules into separate chains easier and also provide a native way to
define sets which are then processed very efficiently as seen in [2].
Anyway netfilter infrastructure developers have chosen nft as
replacement to iptables and it will slowly phase it out, but this will
be a very slow process and it is already going for 10 years now,
everything is written in iptables.
I don't see a big problem. Just choose any of the console command
present on the system and print warning if neither of them is found.
wg-quick shows its log in console and these rules will not cause any
problems in most setups anyway. If this is such an issue then it can be
opted by a command line argument (i.e. use iptables, nft or none) but it
is already an overshoot. Personally I don't even think that the issue
should be fixed in wireguard. The weak host model affects any other
network setups and all the other vpn's just as wireguard and even if
wg-quick patch it somehow for wireguard interface the end system will
still be open to attacks on other interfaces. The strong host model
should be chosen as default by kernel developers or configured system
wide by an administrator.
Also.. what about other systems, windows, android etc?
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
