Megjelent az nftables 1.0.0 csomagszűrő kiadása, amely egységesíti a csomagszűrési interfészeket IPv4, IPv6, ARP és hálózati hidak számára (célja az iptables, ip6tables, arptables és ebtables helyettesítése). Az nftables 1.0.0 működéséhez szükséges változtatásokat a Linux 5.13 kernelbe beépítették. A jelentős verziónövelés nem jár radikális változásokkal, csupán a tizedes számok folytatásának következménye (az előző kiadás 0.9.9 volt).
Az nftables csomagba tartoznak a felhasználói térben működő csomagszűrő komponensek, míg a kernel szintjén az nf_tables alrendszer látja el a feladatot, amely a Linux kernel 3.13-as verziójától kezdve érhető el. A kernel szintjén csak egy általános interfész áll rendelkezésre, amely független a konkrét protokolltól, és alapvető funkciókat biztosít a csomagokból származó adatok kinyerésére, az adatokkal végzett műveletekre és az adatfolyam kezelésére.
Közvetlenül a szűrési szabályok és a protokollspecifikus kezelők felhasználói térben bájt kódba vannak fordítva, majd ezt a bájt kódot a Netlink interfész segítségével betöltik a kernelbe, ahol speciális környezetben végrehajtásra kerül. virtuális gépben, amely a BPF (Berkeley Packet Filters) eljárásra emlékeztet. Ez a megközelítés jelentősen csökkenti a kernel szinten működő szűrési kód méretét, miközben az összes szabályok parszolásával és a protokollokkal kapcsolatos logikával kapcsolatos funkciót a felhasználói térbe helyezi.
Főbb újítások:
- A set-listákban hozzáadva a „*” maszkelemet, amely bármilyen olyan csomagra hat, amely nem illeszkedik a halmazban meghatározott egyéb elemekhez. table x { map blocklist { type ipv4_addr : verdict flags interval elements = { 192.168.0.0/16 : accept, 10.0.0.0/8 : accept, * : drop } } chain y { type filter hook prerouting priority 0; policy accept; ip saddr vmap @blocklist } }
- Lehetővé vált változók definiálása a parancssorból a „--define” opció segítségével. # cat test.nft table netdev x { chain y { type filter hook ingress devices = $dev priority 0; policy drop; } } # nft --define dev="{ eth0, eth1 }" -f test.nft
- A map-listákban lehetővé vált állapotmegőrző (stateful) kifejezések alkalmazása: table inet filter { map portmap { type inet_service : verdict counter elements = { 22 counter packets 0 bytes 0 : jump ssh_input, * counter packets 0 bytes 0 : drop } } chain ssh_input { } chain wan_input { tcp dport vmap @portmap } chain prerouting { type filter hook prerouting priority raw; policy accept; iif vmap { "lo" : jump wan_input } } }
- Hozzáadva a „list hooks” parancs, amely kiadja a megadott csomagcsalád kezelőinek listáját: # nft list hooks ip device eth0 family ip { hook ingress { +0000000010 chain netdev x y [nf_tables] +0000000300 chain inet m w [nf_tables] } hook input { -0000000100 chain ip a b [nf_tables] +0000000300 chain inet m z [nf_tables] } hook forward { -0000000225 selinux_ipv4_forward 0000000000 chain ip a c [nf_tables] } hook output { -0000000225 selinux_ipv4_output } hook postrouting { +0000000225 selinux_ipv4_postroute } }
- A «queue» block allows the combination of jhash, symhash, and numgen expressions for distributing packets to queues in user space. … queue to symhash mod 65536 … queue flags bypass to numgen inc mod 65536 … queue to jhash oif . meta mark mod 32 «queue» can also be combined with map lists to select the queue in user space based on arbitrary keys. … queue flags bypass to oifname map { «eth0» : 0, «ppp0» : 2, «eth1» : 2 }
- Possibility has been provided for disclosing variables that include a set list into multiple maps. define interfaces = { eth0, eth1 } table ip x { chain y { type filter hook input priority 0; policy accept; iifname vmap { lo : accept, $interfaces : drop } } } # nft -f x.nft # nft list ruleset table ip x { chain y { type filter hook input priority 0; policy accept; iifname vmap { «lo» : accept, «eth0» : drop, «eth1» : drop } } }
- The combination of vmaps (verdict maps) with ranges is allowed: # nft add rule x y tcp dport . ip saddr vmap { 1025-65535 . 192.168.10.2 : accept }
- The syntax for NAT mappings has been simplified. The specification of address ranges is allowed: … snat to ip saddr map { 10.141.11.4 : 192.168.2.2-192.168.2.4 } or explicit IP-címek and ports: … dnat to ip saddr map { 10.141.11.4 : 192.168.2.3 . 80 } or combinations of IP ranges and ports: … dnat to ip saddr . tcp dport map { 192.168.1.2 . 80 : 10.141.10.2-10.141.10.5 . 8888-8999 }
Forrás: opennet.ru
