From: Vasili Pupkin <diggest@gmail.com>
To: Roman Mamedov <rm@romanrm.net>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "jwollrath@web.de" <jwollrath@web.de>,
"wireguard@lists.zx2c4.com" <wireguard@lists.zx2c4.com>
Subject: Re: [PATCH] wg-quick: linux: add support for nft and prefer it
Date: Wed, 11 Dec 2019 00:56:22 +0300 [thread overview]
Message-ID: <a8f51c8e-d0e8-aaa6-024f-70b65007559f@gmail.com> (raw)
In-Reply-To: <20191210221215.56c2f30d@natsu>
On 10.12.2019 20:12, Roman Mamedov wrote:
> On Tue, 10 Dec 2019 17:54:49 +0100
> "Jason A. Donenfeld" <Jason@zx2c4.com> 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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-12-10 21:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 15:48 Jason A. Donenfeld
2019-12-10 16:52 ` Jordan Glover
2019-12-10 16:54 ` Jason A. Donenfeld
2019-12-10 17:05 ` Jordan Glover
2019-12-10 17:11 ` Jason A. Donenfeld
2019-12-10 17:12 ` Roman Mamedov
2019-12-10 17:28 ` Davide Depau
2019-12-10 17:33 ` Matthias Urlichs
2019-12-10 17:36 ` Jason A. Donenfeld
2019-12-10 18:00 ` Roman Mamedov
2019-12-10 18:58 ` Jordan Glover
2019-12-10 19:15 ` Jason A. Donenfeld
2019-12-10 20:30 ` Jordan Glover
2019-12-10 20:34 ` Jason A. Donenfeld
2019-12-10 21:56 ` Vasili Pupkin [this message]
2019-12-10 22:09 ` Jason A. Donenfeld
2019-12-10 22:27 ` Vasili Pupkin
2019-12-12 11:21 ` Jason A. Donenfeld
2019-12-10 17:31 ` Vasili Pupkin
2019-12-10 17:38 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8f51c8e-d0e8-aaa6-024f-70b65007559f@gmail.com \
--to=diggest@gmail.com \
--cc=Jason@zx2c4.com \
--cc=jwollrath@web.de \
--cc=rm@romanrm.net \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).