È stato pubblicato il rilascio di packet filter nftables 0.9.9, che unifica le interfacce di filtraggio dei pacchetti per IPv4, IPv6, ARP e bridge di rete (mirato a sostituire iptables, ip6table, arptables ed ebtables). Allo stesso tempo, è stata pubblicata la versione della libreria complementare libnftnl 1.2.0, che fornisce un'API di basso livello per interagire con il sottosistema nf_tables. Le modifiche richieste per il funzionamento della versione 0.9.9 di nftables sono incluse nel kernel Linux 5.13-rc1.
Il pacchetto nftables include componenti di filtro dei pacchetti eseguiti nello spazio utente, mentre il lavoro a livello di kernel è fornito dal sottosistema nf_tables, che fa parte del kernel Linux sin dalla versione 3.13. Il livello del kernel fornisce solo un'interfaccia generica indipendente dal protocollo che fornisce funzioni di base per estrarre dati dai pacchetti, eseguire operazioni sui dati e controllo del flusso.
Le stesse regole di filtraggio e i gestori specifici del protocollo vengono compilati in bytecode dello spazio utente, dopodiché questo bytecode viene caricato nel kernel utilizzando l'interfaccia Netlink ed eseguito nel kernel in una macchina virtuale speciale simile a BPF (Berkeley Packet Filters). Questo approccio consente di ridurre significativamente la dimensione del codice di filtraggio in esecuzione a livello di kernel e di spostare tutte le funzioni delle regole di analisi e la logica di lavorare con i protocolli nello spazio utente.
Principali innovazioni:
- È stata implementata la possibilità di spostare l'elaborazione della tabella di flusso sul lato dell'adattatore di rete, abilitata utilizzando il flag 'offload'. Flowtable è un meccanismo per ottimizzare il percorso di reindirizzamento dei pacchetti, in cui il passaggio completo di tutte le catene di elaborazione delle regole viene applicato solo al primo pacchetto e tutti gli altri pacchetti nel flusso vengono inoltrati direttamente. tabella ip globale { flowtable f { hook filtro priorità ingresso + 1 dispositivi = { lan3, lan0, wan } flag offload } catena forward { tipo filtro hook forward filtro priorità; la politica accetta; protocollo ip { tcp, udp } flusso add @f } catena post { tipo nat hook filtro priorità postrouting; la politica accetta; oifname "wan" mascherata } }
- Aggiunto supporto per allegare un flag di proprietario a una tabella per garantire l'uso esclusivo della tabella da parte di un processo. Quando un processo termina, la tabella ad esso associata viene automaticamente eliminata. Le informazioni sul processo vengono visualizzate nel dump delle regole sotto forma di commento: table ip x { # nomeprogramma nft flags proprietario catena y { tipo filtro hook input priorità filtro; la politica accetta; contatore pacchetti 1 byte 309 } }
- Aggiunto il supporto per la specifica IEEE 802.1ad (stack VLAN o QinQ), che definisce un mezzo per sostituire più tag VLAN in un singolo frame Ethernet. Ad esempio, per verificare il tipo di frame Ethernet esterno 8021ad e vlan id=342, è possibile utilizzare la costruzione ... ether type 802.1ad vlan id 342 per verificare il tipo esterno di frame Ethernet 8021ad/vlan id=1, annidato 802.1 q/vlan id=2 e ulteriore incapsulamento dei pacchetti IP: ... ether type 8021ad vlan id 1 vlan type 8021q vlan id 2 vlan type ip counter
- Aggiunto il supporto per la gestione delle risorse utilizzando la gerarchia unificata cgroups v2. La differenza fondamentale tra cgroups v2 e v1 è l'uso di una gerarchia di cgroups comune per tutti i tipi di risorse, invece di gerarchie separate per l'allocazione delle risorse della CPU, per la regolazione del consumo di memoria e per l'I/O. Ad esempio, per verificare se l’antenato di un socket al primo livello cgroupv2 corrisponde alla maschera “system.slice”, si può utilizzare la costruzione: ... socket cgroupv2 level 1 “system.slice”
- Aggiunta la possibilità di controllare i componenti dei pacchetti SCTP (la funzionalità richiesta per questo apparirà nel kernel Linux 5.14). Ad esempio, per verificare se un pacchetto contiene un pezzo con tipo 'dati' e campo 'tipo': ... sctp pezzo dati esiste ... sctp pezzo dati tipo 0
- L'esecuzione dell'operazione di caricamento delle regole è stata accelerata di circa due volte utilizzando il flag “-f”. Anche la produzione dell'elenco delle regole è stata accelerata.
- Viene fornito un modulo compatto per verificare se i bit di flag sono impostati. Ad esempio, per verificare che i bit di stato snat e dnat non siano impostati è possibile specificare: ... ct status ! snat,dnat per verificare che il bit syn sia impostato nella maschera di bit syn,ack: ... flag tcp syn / syn,ack per verificare che i bit fin e rst non siano impostati nella maschera di bit syn,ack,fin,rst: ... flag tcp! = fin,rst / syn,ack,fin,rst
- Consenti la parola chiave "verdetto" nelle definizioni set/map typeof: add map xm { typeof iifname . protocollo ip th dport: verdetto ;}
Fonte: opennet.ru