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. >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 + 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) + 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 > 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. >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 ;-) 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. regards -- Slavko https://www.slavino.sk/
