The release of the nftables 1.0.0 packet filtering framework has been published, unifying packet filtering interfaces for IPv4, IPv6, ARP, and network bridges (aiming to replace iptables, ip6tables, arptables, and ebtables). Necessary changes for the nftables 1.0.0 release have been integrated into the Linux kernel 5.13. The significant version number change is not due to any drastic changes but is merely the result of a continued decimal numbering progression (the previous release was 0.9.9).
The nftables package includes user-space packet filter components, while the nf_tables subsystem, which is part of the Linux kernel since version 3.13, handles operations at the kernel level. At the kernel level, only a general interface is provided, which is independent of specific protocols and offers basic functions for extracting data from packets, performing data operations, and managing the flow.
The filtering rules themselves and protocol-specific handlers are compiled into bytecode in user space, after which this bytecode is loaded into the kernel via the Netlink interface and executed in the kernel in a special environment resembling BPF (Berkeley Packet Filters). This approach significantly reduces the size of the filtering code running at the kernel level and offloads all functions related to rule parsing and protocol logic into user space. virtual machineFull support for lightweight tunnel templates, such as vxlan, geneve, and erspan, has been provided: table netdev global { tunnel t1 { id 10 ip saddr 192.168.2.10 ip daddr 192.168.2.11 sport 1025 dport 20020 ttl 1 erspan { version 1 index 2 } } tunnel t2 { id 10 ip saddr 192.168.3.10 ip daddr 192.168.3.11 sport 1025 dport 21021 ttl 1 erspan { version 1 index 2 } } chain in { type filter hook ingress device veth0 priority 0; tunnel name ip saddr map { 10.141.10.12 : "t1", 10.141.10.13 : "t2" } fwd to erspan1 } } Before loading the rules, a network interface erspan1 must be created: ip link add dev erspan1 type erspan external
Key innovations:
- Support for the wildcard element ‘*’ has been added to set lists, which triggers for any packets not matching other elements defined in the set. 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 } }
- The ability to define variables from the command line using the ‘--define’ option has been provided. # 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
- The application of permanent (stateful) expressions is permitted in map lists: 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 } } }
- The ‘list hooks’ command has been added to output the list of handlers for a specified family of packets: # 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 } }
- In the "queue" blocks, it is allowed to combine the 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 The "queue" can also be combined with map lists to select a queue in user space based on arbitrary keys. … queue flags bypass to oifname map { "eth0" : 0, "ppp0" : 2, "eth1" : 2 }
- The ability to expose variables, including the set list, in multiple maps has been provided. 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 } } }
- Combining vmaps (verdict map) 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. It is allowed to specify address ranges: … snat to ip saddr map { 10.141.11.4 : 192.168.2.2-192.168.2.4 } or explicit (the key to connect to is specified, and iroh finds the associated host and establishes an encrypted connection using the QUIC protocol). Direct P2P connections are established whenever possible, but if not, it falls back to using relays, which are also employed for host discovery by keys. You can run your own relay or connect to public relays supported by the community. 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 }
Source: opennet.ru
