The release of the nftables 0.9.9 packet filter has been published, unifying the filtering interfaces for IPv4, IPv6, ARP, and network bridges (aimed at replacing iptables, ip6table, arptables, and ebtables). At the same time, the related library libnftnl 1.2.0 has been released, providing a low-level API for interaction with the nf_tables subsystem. The necessary changes for the nftables 0.9.9 release are included in the Linux kernel 5.13-rc1.
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:
- The ability to offload flowtable processing to the network adapter has been implemented, enabled via the ‘offload’ flag. The flowtable is an optimization mechanism for packet redirection paths, where the complete processing of all rule chains is applied only for the first packet, while all other packets in the flow are forwarded directly. table ip global { flowtable f { hook ingress priority filter + 1 devices = { lan3, lan0, wan } flags offload } chain forward { type filter hook forward priority filter; policy accept; ip protocol { tcp, udp } flow add @f } chain post { type nat hook postrouting priority filter; policy accept; oifname "wan" masquerade } }
- Support has been added for attaching a flag to the table for binding to an owner, which allows exclusive use of the table by the process. When the process ends, the table bound to it is automatically deleted. Information about the process is displayed in rule dumps as a comment: table ip x { # progname nft flags owner chain y { type filter hook input priority filter; policy accept; counter packets 1 bytes 309 } }
- Support for the IEEE 802.1ad specification (VLAN stacking or QinQ) has been added, defining means for substituting multiple VLAN tags into a single Ethernet frame. For example, to check the type of the external Ethernet frame 8021ad and vlan id=342, you can use the construct … ether type 802.1ad vlan id 342 to check the external type of the Ethernet frame 8021ad/vlan id=1, nested 802.1q/vlan id=2, and further encapsulate the IP packet: … ether type 802.1ad vlan id 1 vlan type 8021q vlan id 2 vlan type ip counter
- Support for resource management through a unified cgroups v2 hierarchy has been added. A key distinction of cgroups v2 from v1 is the use of a common cgroups hierarchy for all resource types, instead of separate hierarchies for CPU resource allocation, memory consumption regulation, and input/output. For example, to check if a socket's ancestor at level one of cgroupv2 matches the mask “system.slice,” you can use the construction: … socket cgroupv2 level 1 “system.slice”
- The ability to check the components of SCTP packets has been added (required functionality will appear in Linux kernel 5.14). For example, to check for the presence of a chunk of type ‘data’ in the packet and the field 'type': … sctp chunk data exists … sctp chunk data type 0
- The execution of rule loading operations has been accelerated by approximately twice using the ‘-f’ flag. The listing of rules has also been expedited.
- A compact form for checking the setting of bits in flags has been provided. For example, to check that the status bits snat and dnat are not set, you can specify: … ct status ! snat,dnat to check that the syn bit is set in the syn,ack bitmask: … tcp flags syn / syn,ack to check that the fin and rst bits are not set in the syn,ack,fin,rst bitmask: … tcp flags != fin,rst / syn,ack,fin,rst
- The use of the keyword ‘verdict’ in the typeof definitions for set/map has been allowed: add map x m { typeof iifname . ip protocol . th dport : verdict ;}
Source: opennet.ru
