Foi publicado o lançamento do filtro de pacotes nftables 0.9.9, unificando as interfaces de filtragem de pacotes para IPv4, IPv6, ARP e pontes de rede (destinado a substituir iptables, ip6table, arptables e ebtables). Simultaneamente, foi liberada a versão da biblioteca auxiliar libnftnl 1.2.0, que fornece uma API de baixo nível para interação com o subsistema nf_tables. As alterações necessárias para operação do nftables 0.9.9 estão incluídas no núcleo do Linux 5.13-rc1.
O pacote nftables inclui componentes do filtro de pacotes que operam no espaço do usuário, enquanto a funcionalidade no nível do núcleo é assegurada pelo subsistema nf_tables, que faz parte do núcleo do Linux a partir da versão 3.13. No nível do núcleo, é fornecida apenas uma interface geral, independente de protocolo específico, que oferece funções básicas para a extração de dados de pacotes, execução de operações sobre dados e controle de fluxo.
As regras de filtragem e os manipuladores específicos de protocolos são compilados em bytecode no espaço do usuário, após o que esse bytecode é carregado no núcleo por meio da interface Netlink e executado no núcleo em uma máquina virtual, semelhante ao BPF (Berkeley Packet Filters). Essa abordagem permite reduzir significativamente o tamanho do código de filtragem que opera no nível do núcleo e deslocar todas as funções de análise de regras e lógica de operação com protocolos para o espaço do usuário.
Principais novidades:
- Foi implementada a possibilidade de transferir o processamento do flowtable para o lado do adaptador de rede, ativada através da flag 'offload'. O flowtable é um mecanismo de otimização do caminho de redirecionamento de pacotes, onde a passagem completa por todas as cadeias de processamento de regras é aplicada apenas para o primeiro pacote, enquanto todos os outros pacotes no fluxo são encaminhados diretamente. 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 } }
- Adicionada a suporte para anexar uma tabela de flags à vinculação com o proprietário, permitindo o uso exclusivo da tabela pelo processo. Ao finalizar o processo, a tabela vinculada a ele é automaticamente removida. As informações sobre o processo são exibidas no despejo de regras na forma de um comentário: table ip x { # progname nft flags owner chain y { type filter hook input priority filter; policy accept; counter packets 1 bytes 309 } }
- Adicionada a suporte para a especificação IEEE 802.1ad (empilhamento VLAN ou QinQ), que define meios para a inserção de várias tags VLAN em um único quadro Ethernet. Por exemplo, para verificar o tipo de quadro Ethernet externo 8021ad e vlan id=342, pode-se usar a construção … ether type 802.1ad vlan id 342 para verificar o tipo externo do quadro Ethernet 8021ad/vlan id=1, o 802.1q/vlan id=2 aninhado e o encapsulamento do pacote IP: … ether type 8021ad vlan id 1 vlan type 8021q vlan id 2 vlan type ip counter
- Adicionada a suporte para gerenciamento de recursos usando uma hierarquia unificada de cgroups v2. A principal diferença entre cgroups v2 e v1 é a aplicação de uma hierarquia comum de cgroups para todos os tipos de recursos, em vez de hierarquias separadas para alocação de recursos CPU, controle de consumo de memória e entrada/saída. Por exemplo, para verificar se o ancestral do soquete no primeiro nível do cgroupv2 está sob a máscara "system.slice", pode-se usar a construção: … socket cgroupv2 level 1 "system.slice"
- Adicionada a possibilidade de verificar os componentes dos pacotes SCTP (funcionalidade necessária que estará disponível no Kernel Linux 5.14). Por exemplo, para verificar a existência de um chunk no pacote com tipo 'data' e campo 'type': … sctp chunk data exists … sctp chunk data type 0
- A operação de carregamento de regras foi acelerada em cerca de duas vezes com o uso da flag "-f". A listagem de regras também foi acelerada.
- Fornecida uma forma compacta de verificar a configuração de bits nas flags. Por exemplo, para verificar se os bits de status snat e dnat não estão definidos, pode-se indicar: … ct status ! snat,dnat para verificar se o bit syn está definido na máscara de bits syn,ack: … tcp flags syn / syn,ack para verificar se os bits fin e rst não estão definidos na máscara de bits syn,ack,fin,rst: … tcp flags != fin,rst / syn,ack,fin,rst
- Permitido o uso da palavra-chave "verdict" nas definições de typeof para set/map: add map x m { typeof iifname . ip protocol . th dport : verdict ;}
Fonte: opennet.ru
