Hi Slavko, On Tue, 30 Jan 2024 19:34:30 +0000 Slavko <linux@xxxxxxxxxx> wrote: > Dňa 30. januára 2024 17:57:21 UTC používateľ Kerin Millar <kfm@xxxxxxxxxxxxx> napísal: > > >It is easy to say that it is pointless if not the one to be responsible for implementing and maintaining the code and trying to take into account diverse - and occasionally conflicting - user desires. There have been various set-related bugs in nftables over the years. Complexity surely matters to someone. There are multiple open bugs now that concern both performance and memory usage. Efficiency surely matters to someone. > > Please, aproximate my English, it is far from good... > > I mean mostly that, that IPv6 becomes reality, and soon or later (the later > is IMO more realistic) will replace IPv4 at all, thus all L3 addresses will > become 128 bites long. Sure, here will be always penalty in using 128b > addresses in compare to 32b addresses, but world is (slowly) moving > to IPv6, thus that penalty is something, which cannot be avoided. > > Debate these penalties sounds for me exactly as debate when 64b > OSs started. I remember "arguments" in that time -- twice of memory > consumption, twice of binary sizes, etc... While all these arguments > are (or can be) right, they are pointless, as IPv6 is here and is not > avoidable in future and we all should to learn to live with that, despite > if we want or don't want it. I see. Fair enough. > > >For it to improve, you could put forward a concrete suggestion as to how it might be improved, be it supporting logical disjunctions in rules, supporting a generic address type in sets or whatever else. > > I am not able to provide real suggestions, as i don't speak C and i > have minimal knowledge about netfilter/nftables/kernel internals, > thus i can be totally wrong. > > Anyway, i have some ideas from user (admin) point of view, of > course. I can imagine this: > > + sets will store protocol agnostic L3 addresses and it doesn't > matter (for me) if IPv4 will be mapped to IPv6 or these L3 sets > will internally maintain two sets -- one for IPv4 and one for IPv6 Now that you mention it, I thought that I recalled someone filing a related issue at bugzilla but it seems that my memory is playing tricks on me. I can find no such issue now, although there is one that (sort of) proposed an equivalent to the list:set type of ipset. That one was rejected. > + nftables syntax will provide some sort of abstraction, as it already > provides eg. for UDP/TCP ports (th dport), eg. "nh saddr" (nh as > network header) It would require some new syntax and/or grammar, indeed. > + nftables will provide abstraction for ICMP(v6) types, something > as it already provides for reject, to one can build common rule > for both, including the one common set/verdict map -- for me > it doesn't matter if it will internally map namex to protocol's proper > values, or specific names must be prefixed eg. by ipv4 and/or ipv6 I could see that working well enough for types that both protocols have in common, such as echo-request. > > > That would, at least, be a step along the road to (potentially) convincing whoever is going to do the work that it is justified. > > Yes, that was initial idea of my reply, we all (users, admins, devs) > have to provide own point of view and find best possible solution. Yes, absolutely. > > >On my part, and despite having been a user of nftables for many years now, I would prefer to see its QA and documentation improve ahead of - though not wholly at the expense of - new features being added. > > While i played with nftables for years, i use it only on one of > my servers yet, and even this machine uses mix of iptables > and nftables rules (the real blocklists are still using ipset), > the ip(6)tables is used only to drop traffic, all other logic is > done from nftables. Nothing extra, just slightly more than > basic firewall, it uses sets to limit (per IP/net) logging, > connections, dynamic blocking, and every used set must be > doubled... > > My nft sets doesn't contain huge amount of addresses, as long > time blocking is done by ipsets, with (semi) persistent and from > fail2ban (up some tens of days). > > I implemented it about year ago, and yes, the documentation > is hard to read. Most of it is ip family only, some parts are > hard to understand, and even more hard to combine together. > But i cannot be sure, if it is not by lack of my English... But > my feel from docs is, that they are exactly as my notes -- > perfect for me, but hard to understand for all others ;-) That seems a fair assessment to me. While iptables has the advantage of being simpler in many ways, the iptables(8) man page probably does a better job of on-boarding new users to the underlying concepts. Rusty Russell's guides and HOWTOs were also rather good in their day. Technical writing is a talent unto itself and some people are just naturally good at it (no offense intended to the current team, of course). > > I found as very useful examples from announces in this ML's > archive. IMO these announces should be copied to (or be > linked from) the wiki. I agree. We (this includes myself) could be making more of an effort to do this. -- Kerin Millar
