La publication de la version 0.9.9 du filtre de paquets nftables a été effectuée, unifiant les interfaces de filtrage des paquets pour IPv4, IPv6, ARP et les ponts réseau (visant à remplacer iptables, ip6tables, arptables et ebtables). Parallèlement, la version 1.2.0 de la bibliothèque associée libnftnl, fournissant une API de bas niveau pour interagir avec le sous-système nf_tables, a également été publiée. Les modifications nécessaires au fonctionnement de nftables 0.9.9 sont incluses dans le noyau Linux 5.13-rc1.
Le paquet nftables comprend des composants du filtre de paquets fonctionnant dans l'espace utilisateur, tandis qu'au niveau du noyau, le fonctionnement est assuré par la sous-système nf_tables, intégré dans le noyau Linux depuis la version 3.13. Au niveau du noyau, une interface générale est fournie, indépendante du protocole spécifique, offrant des fonctions de base pour l'extraction de données des paquets, l'exécution d'opérations sur les données et la gestion de flux.
Les règles de filtrage et les gestionnaires spécifiques aux protocoles sont compilés en bytecode dans l'espace utilisateur, après quoi ce bytecode est chargé dans le noyau via l'interface Netlink et exécuté dans le noyau dans une structure spéciale une machine virtuelle, similaire aux BPF (Berkeley Packet Filters). Cette approche permet de réduire considérablement la taille du code de filtrage fonctionnant au niveau du noyau et de transférer toutes les fonctions de parsing des règles et de logique de traitement des protocoles dans l'espace utilisateur.
Les principales nouveautés :
- La possibilité de décharger le traitement du flowtable vers l'adaptateur réseau a été implémentée, activée par le biais du drapeau 'offload'. Le flowtable est un mécanisme d'optimisation du chemin de redirection des paquets, où le passage complet par toutes les chaînes de traitement des règles ne s'applique qu'au premier paquet, tandis que tous les autres paquets du flux sont transmis directement. 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 } }
- Le support de l'attachement d'un drapeau à la table pour lier au propriétaire a été ajouté, permettant d'assurer l'utilisation exclusive de la table par le processus. À la fin du processus, la table qui lui est liée est automatiquement supprimée. Les informations sur le processus sont affichées dans le dump des règles sous forme de commentaire : table ip x { # progname nft flags owner chain y { type filter hook input priority filter; policy accept; counter packets 1 bytes 309 } }
- Le support de la spécification IEEE 802.1ad (VLAN stacking ou QinQ) a été ajouté, définissant les moyens pour insérer plusieurs balises VLAN dans un seul trame Ethernet. Par exemple, pour vérifier le type de trame Ethernet 8021ad extérieure et vlan id=342, la construction suivante peut être utilisée : … ether type 802.1ad vlan id 342 pour vérifier le type extérieur de la trame Ethernet 8021ad/vlan id=1, imbriquée 802.1q/vlan id=2 et l'encapsulation ultérieure du paquet IP : … ether type 802.1ad vlan id 1 vlan type 8021q vlan id 2 vlan type ip counter
- Le support de la gestion des ressources via une hiérarchie unifiée de cgroups v2 a été ajouté. La principale différence entre cgroups v2 et v1 est l'application d'une hiérarchie commune de cgroups pour tous les types de ressources, au lieu de hiérarchies séparées pour la distribution des ressources CPU, la régulation de la consommation de mémoire et l'entrée/sortie. Par exemple, pour vérifier si l'ancêtre du socket au premier niveau de cgroupv2 correspond au masque «system.slice», vous pouvez utiliser la construction : … socket cgroupv2 niveau 1 «system.slice»
- La possibilité de vérifier les parties composants des paquets SCTP a été ajoutée (la fonctionnalité nécessaire sera disponible dans le noyau Linux 5.14). Par exemple, pour vérifier la présence d'un chunk de type 'data' et du champ 'type': … sctp chunk data exists … sctp chunk data type 0
- L'exécution de l'opération de chargement des règles a été accélérée d'environ deux fois grâce au drapeau «-f». La sortie de la liste des règles a également été accélérée.
- Une forme compacte de vérification de l'installation des bits dans les drapeaux a été fournie. Par exemple, pour vérifier que les bits de l'état snat et dnat ne sont pas installés, vous pouvez indiquer : … ct status ! snat,dnat pour vérifier que le bit syn est installé dans le masque de bits syn,ack : … tcp flags syn / syn,ack pour vérifier que les bits fin et rst ne sont pas installés dans le masque de bits syn,ack,fin,rst : … tcp flags != fin,rst / syn,ack,fin,rst
- L'utilisation du mot-clé «verdict» dans les définitions typeof pour set/map est autorisée : add map x m { typeof iifname . ip protocol . th dport : verdict;}
Source : opennet.ru
