Se ha publicado la versión 0.9.9 del filtro de paquetes nftables, unificando las interfaces de filtrado de paquetes para IPv4, IPv6, ARP y puentes de red (destinado a reemplazar iptables, ip6table, arptables y ebtables). Al mismo tiempo, se ha lanzado la biblioteca complementaria libnftnl 1.2.0, que proporciona una API de bajo nivel para interactuar con la subsistema nf_tables. Los cambios necesarios para el funcionamiento de la versión nftables 0.9.9 están incluidos en el núcleo de Linux 5.13-rc1.
El paquete nftables incluye componentes del filtrador de paquetes que funcionan en el espacio de usuario, mientras que a nivel del núcleo, el trabajo es realizado por el subsistema nf_tables, incluido en el núcleo de Linux desde la versión 3.13. A nivel del núcleo, solo se proporciona una interfaz general, independiente del protocolo específico, que ofrece funciones básicas para extraer datos de paquetes, realizar operaciones con datos y gestionar flujos.
Las reglas de filtrado y los controladores específicos del protocolo se compilan en bytecode en el espacio de usuario, que luego se carga en el núcleo a través de la interfaz Netlink y se ejecuta en el núcleo en un espacio especial una máquina virtual, similar a BPF (Berkeley Packet Filters). Este enfoque permite reducir significativamente el tamaño del código de filtrado que opera a nivel de núcleo y trasladar todas las funciones de análisis de reglas y la lógica de trabajo con protocolos al espacio de usuario.
Novedades principales:
- Se ha implementado la capacidad de trasladar el procesamiento de flowtable al lado del adaptador de red, habilitada mediante la bandera ‘offload’. Flowtable es un mecanismo de optimización de ruta que redirige paquetes, aplicando el procesamiento completo de todas las cadenas de reglas solo al primer paquete, mientras que los demás paquetes en el flujo se direccionan directamente. 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 } }
- Se ha añadido soporte para el adjunto de una bandera a la tabla que permite enlazarla con su propietario, garantizando el uso exclusivo de la tabla por parte del proceso. Al finalizar el proceso, la tabla vinculada se elimina automáticamente. La información sobre el proceso se muestra en el volcado de reglas como un comentario: table ip x { # progname nft flags owner chain y { type filter hook input priority filter; policy accept; counter packets 1 bytes 309 } }
- Se ha añadido soporte para la especificación IEEE 802.1ad (apilamiento de VLAN o QinQ), que define los medios para superponer varias etiquetas VLAN en un solo cuadro Ethernet. Por ejemplo, para verificar el tipo de cuadro Ethernet externo 8021ad y vlan id=342 se puede utilizar la siguiente construcción: … ether type 802.1ad vlan id 342 para verificar el tipo de cuadro Ethernet externo 8021ad/vlan id=1, anidado 802.1q/vlan id=2 y posterior encapsulación de un paquete IP: … ether type 802.1ad vlan id 1 vlan type 8021q vlan id 2 vlan type ip counter
- Se ha agregado soporte para la gestión de recursos mediante una jerarquía unificada de cgroups v2. La principal diferencia entre cgroups v2 y v1 es la aplicación de una jerarquía común de cgroups para todos los tipos de recursos, en lugar de jerarquías separadas para la distribución de recursos de CPU, control del consumo de memoria y entrada/salida. Por ejemplo, para verificar si el antepasado del socket en el primer nivel de cgroupv2 cumple con la máscara «system.slice», se puede usar la construcción: … socket cgroupv2 nivel 1 «system.slice»
- Se ha añadido la posibilidad de verificar las partes de los paquetes SCTP (la funcionalidad necesaria estará disponible en el núcleo de Linux 5.14). Por ejemplo, para comprobar la existencia de un chunk de tipo ‘data’ en el paquete y el campo ‘type’: … sctp chunk data exists … sctp chunk data type 0
- La ejecución de la operación de carga de reglas se ha acelerado aproximadamente al doble utilizando la bandera «-f». También se ha acelerado la salida de la lista de reglas.
- Se ha proporcionado una forma compacta de verificar la configuración de bits en las banderas. Por ejemplo, para comprobar que los bits de estado snat y dnat no están establecidos, se puede indicar: … ct status ! snat,dnat para verificar que el bit syn está establecido en la máscara de bits syn,ack: … tcp flags syn / syn,ack para verificar que los bits fin y rst no están establecidos en la máscara de bits syn,ack,fin,rst: … tcp flags != fin,rst / syn,ack,fin,rst
- Se permite el uso de la palabra clave «verdict» en las definiciones de typeof para set/map: add map x m { typeof iifname . ip protocol . th dport : verdict;}
Fuente: opennet.ru
