Migrare a nftables prima che iptables-legacy sparisca da Debian

A novembre 2025, sulla mailing list debian-devel, il kernel team di Debian ha aperto il Mass Bug Filing che annuncia la rimozione di iptables-legacy, e il piano dichiarato non lascia spazio a interpretazioni: le interfacce legacy del kernel usate da iptables, arptables ed ebtables sono deprecate e ormai disabilitate di default nel kernel, i pacchetti e i binari legacy verranno eliminati con Debian 14 "forky", e dopo il rilascio di forky sparirà anche il supporto lato kernel. In forky il vecchio stack potrà ancora funzionare, ma senza alcun supporto e con l'etichetta di deprecato stampata sopra. Nel frattempo systemd 259 ha già tolto a networkd e nspawn la capacità di creare regole NAT via iptables, solo nftables, uno dei cambi di rotta che ho messo in fila analizzando le novità operative di quella release: quando l'init system e la distribuzione madre spingono nella stessa direzione nello stesso anno, la direzione non è più in discussione. La direzione è una sola e la velocità sta aumentando: il layer di compatibilità che da anni permette di far finta di niente sta esaurendo il suo mandato. La buona notizia è che per la maggior parte dei VPS moderni la migrazione è già avvenuta a tua insaputa; quella meno buona è che i sistemi dove non è avvenuta sono esattamente quelli con gli script più vecchi e meno documentati. In questo articolo la checklist completa: come scoprire in trenta secondi da che parte stai, e i sette passi per portare un firewall iptables storico su nftables nativo senza chiuderti fuori dalla macchina.

TL;DR

• Verifica (30 secondi): iptables -V. Se dice (nf_tables) sei sul backend moderno; se dice (legacy) la migrazione ti riguarda davvero.
• Controlla il doppio stack: iptables-legacy -L -n e nft list ruleset insieme: regole in entrambi = configurazione da bonificare.
• Traduzione automatica: iptables-restore-translate -f regole.txt converte il salvataggio iptables in sintassi nftables: base da revisionare, non da eseguire alla cieca.
• Destinazione: ruleset nativo in /etc/nftables.conf + systemctl enable nftables; poi neutralizza gli script legacy (rc.local, hook di rete) e allinea Fail2ban con banaction = nftables-multiport.
• Sicurezza anti-lockout: ogni switch si prova con la console del provider pronta e con la sessione SSH vecchia aperta finché la nuova non è verificata.

Come scopro se sono ancora su iptables-legacy?

La risposta sta in un comando, perché da anni Debian gestisce la convivenza dei due mondi con le alternatives. iptables -V risponde con la versione e il backend fra parentesi: iptables v1.8.x (nf_tables) significa che i tuoi comandi iptables sono già tradotti verso il sottosistema moderno del kernel, ed è il default su Debian dalla buster in poi; iptables v1.8.x (legacy) significa che qualcuno, o qualche pacchetto, ha commutato le alternatives verso il binario storico, e sei nel perimetro del problema. Il quadro completo lo danno tre comandi in fila:

iptables -V
update-alternatives --display iptables | head -3
iptables-legacy -L -n 2>/dev/null | head   # regole caricate sul VECCHIO stack
nft list ruleset | head                     # regole nel sottosistema nuovo

Il caso patologico da riconoscere subito è il doppio stack: regole presenti sia nell'output di iptables-legacy sia in nft list ruleset. Succede più spesso di quanto si creda, tipicamente dopo migrazioni a metà o per colpa di un tool che parla con un backend mentre gli script di avvio parlano con l'altro, e produce il peggio dei due mondi: il pacchetto in ingresso attraversa entrambi gli stack, il comportamento effettivo è l'intersezione di due policy che nessuno ha mai pensato insieme, e il debugging diventa un esercizio di archeologia. Se ti riconosci qui, la migrazione non è procrastinabile: è già in corso, solo male.

C'è un dettaglio del piano Debian che rende il rischio meno teorico di quanto sembri: le interfacce legacy sono ormai disabilitate di default nel kernel, il che significa che il vecchio stack smette di essere qualcosa che "c'è comunque" e diventa qualcosa che c'è solo dove la configurazione lo riabilita. Tradotto in pratica: uno script iptables-legacy che oggi funziona sulla tua macchina aggiornata di versione in versione può fallire in silenzio sulla prossima installata da zero, e il fallimento di uno script firewall ha due esiti possibili, la macchina spalancata o la macchina irraggiungibile, a seconda di dove lo script si interrompe. È la classe di sorpresa che conviene incontrare in un laboratorio, non in un ripristino d'emergenza.

Vale la pena chiarire anche cosa NON sparisce, perché sul tema circola confusione. Il layer iptables-nft, quello che ti fa usare la sintassi iptables sopra il kernel moderno, non è oggetto di questa rimozione: a sparire sono i binari -legacy e, dopo forky, le interfacce kernel su cui poggiano. Quindi la migrazione ha due livelli di ambizione: il livello minimo, assicurarsi che tutto passi dal backend nf_tables, che ti mette al riparo dalla rimozione; e il livello giusto, passare alla sintassi nativa di nftables, che è il punto d'arrivo raccomandato anche dalla pagina ufficiale della wiki Debian e quello che questa checklist costruisce, perché continuare a scrivere iptables nel 2026 significa formarsi su una sintassi in via di pensionamento.

Nel mio lavoro sui parchi VPS delle PMI questo genere di transizione silenziosa è pane quotidiano dei subentri: nel mio profilo professionale trovi come lavoro su hardening e messa in sicurezza di macchine ereditate, dove il firewall scritto da qualcuno che non c'è più è un classico del genere.

La checklist di migrazione, passo per passo

Passo 1: fotografa l'esistente. Prima di toccare qualunque cosa, il censimento: iptables-save > /root/fw-legacy-backup.txt (e ip6tables-save, che tutti dimenticano, lasciando IPv6 scoperto o spalancato). Questo file è insieme il tuo backup, la tua documentazione e la materia prima della traduzione. Leggilo davvero: nella mia esperienza il salvataggio di un firewall storico contiene sempre regole morte, riferimenti a IP che non esistono più, catene di tool disinstallati anni fa. La migrazione è l'occasione per potare, non per trasportare fossili: ogni regola che non sai spiegare è una regola da capire adesso o da eliminare adesso, perché tradurla senza capirla significa solo trasferire il debito tecnico su una sintassi nuova, con gli interessi maturati nel viaggio.

Passo 2: traduci con lo strumento apposta. La suite iptables moderna include i traduttori ufficiali, ed è un lusso che poche migrazioni tecnologiche offrono:

iptables-restore-translate -f /root/fw-legacy-backup.txt > /root/fw-nft-bozza.nft
ip6tables-restore-translate -f /root/fw6-legacy-backup.txt >> /root/fw-nft-bozza.nft

L'output è sintassi nftables legittima, ma trattalo come una bozza da revisionare, non come un artefatto finito: i moduli esotici possono non avere traduzione diretta (il traduttore li segnala nei commenti), e la traduzione meccanica riproduce la struttura storica invece di sfruttare ciò che nftables fa meglio, come i set per le liste di IP e le tabelle inet che unificano IPv4 e IPv6 in un colpo solo, dimezzando le regole da mantenere. Un assaggio del guadagno, perché rende l'idea meglio di ogni argomento: la blocklist che in iptables era duecento righe fotocopiate diventa

set blocklist {
    type ipv4_addr; flags interval;
    elements = { 203.0.113.0/24, 198.51.100.7 }
}
# ... e una sola regola: ip saddr @blocklist drop

e aggiornare la lista diventa un nft add element atomico invece di una ricarica completa del firewall. È il genere di semplificazione che si apprezza alla terza modifica, e per sempre.

Passo 3: componi il ruleset di destinazione. La casa del firewall diventa /etc/nftables.conf, caricata dal servizio dedicato: systemctl enable nftables. Qui non riparto da zero perché la configurazione completa di un firewall nftables per un VPS, policy default-deny, rate limiting SSH, anti spoofing, l'ho già scritta ed è il complemento naturale di questo pezzo: la trovi nella guida alla configurazione di nftables su VPS. Il lavoro di questo passo è fondere la tua bozza tradotta con quella struttura pulita, e validare la sintassi prima di caricare: nft -c -f /etc/nftables.conf controlla senza applicare, ed è il comando che separa una migrazione da un lockout.

Passo 4: allinea gli inquilini del firewall. Il firewall non è mai solo: altri software scrivono regole, e vanno commutati insieme a te. Fail2ban in testa: la banaction va portata su nftables-multiport (o nftables-allports) in jail.local, altrimenti i ban continueranno a finire nello stack sbagliato, dove non incontrano più il traffico. Docker è il caso più delicato, tanto che figura esplicitamente fra i pacchetti citati nel MBF: il demone gestisce le proprie regole in autonomia sul backend iptables-nft, e la regola pratica è non mescolare mai le tue regole con le sue catene, tenendo le tue policy nella tabella nftables tua e lasciando che Docker amministri le sue. E qualunque VPN, pannello o script di provisioning che invochi iptables va censito adesso: la lista si costruisce con un grep -r iptables /etc/ /usr/local/bin/ 2>/dev/null che riserva quasi sempre sorprese.

Passo 4-bis: valuta se un wrapper fa al caso tuo. La checklist assume che il firewall tu voglia scriverlo e capirlo, che per un VPS esposto resta la mia raccomandazione. Ma esiste una via legittima per chi vuole solo uscire dal legacy con il minimo attrito: i wrapper moderni. La stessa wiki Debian suggerisce firewalld per chi non vuole mantenere script propri, e chi già usa ufw sta comunque poggiando sul backend moderno. Il criterio di scelta è onesto: se il tuo firewall è "porte 22, 80 e 443 aperte e basta", un wrapper ti dà la migrazione quasi gratis; se hai rate limiting, set dinamici, NAT o policy per interfaccia, il ruleset nativo è più leggibile di qualunque astrazione che ci si appoggi sopra.

Passo 5: neutralizza gli avviatori storici. Il firewall legacy non vive solo nelle regole ma nei meccanismi che le caricano al boot: righe in rc.local, hook in /etc/network/if-up.d/, unit systemd artigianali, il pacchetto iptables-persistent. Vanno trovati e disattivati tutti, perché il sintomo classico della migrazione lasciata a metà è la macchina che dopo il riavvio ricarica lo stack vecchio sopra quello nuovo, ricreando il doppio stack del quale al passo zero ti eri appena liberato.

Passo 6: lo switch, con le cinture allacciate. Il momento del passaggio segue la regola d'oro che ho già raccontato nella sequenza per lavorare via SSH senza chiudersi fuori: console del provider verificata prima, sessione SSH esistente che resta aperta, caricamento del ruleset nuovo, e connessione di prova da un altro terminale prima di dichiarare vittoria. Per i paranoici giustificati, un at che azzera il firewall fra dieci minuti se non lo cancelli è la rete di sicurezza che non costa niente, si disinnesca con un comando quando la prova di connessione riesce, e una volta nella vita ripaga tutto. Infine il riavvio di collaudo, perché un firewall si giudica a freddo: la macchina deve tornare su con il ruleset giusto, uno solo, e con iptables-legacy -L -n ormai vuoto.

Passo 7: iscrivi la migrazione nel calendario del parco. Se gestisci più macchine, il censimento del passo 1 va fatto su tutte adesso, con la migrazione calendarizzata per lotti: il costo marginale della seconda macchina è una frazione della prima, e arrivare a forky con il parco già nativo significa leggere le release notes di Debian 14 con la serenità di chi quel capitolo l'ha chiuso un anno prima.

Le deprecazioni annunciate con anni di anticipo sono il modo in cui l'open source ti regala il tempo di fare le cose bene. Il paradosso è che proprio quell'abbondanza di preavviso le rende procrastinabili all'infinito: nessuna delle macchine ancora su iptables-legacy oggi è di qualcuno che non è stato avvisato, e lo stesso varrà per chi arriverà impreparato a forky.

C'è un ultimo argomento per farlo adesso e non con l'acqua alla gola, ed è di formazione più che di tecnica: nftables non è una sintassi nuova per le stesse idee, è un modello più pulito, tabelle e catene che crei tu invece di ereditare, famiglie inet unificate, set e mappe come cittadini di prima classe, e il tempo che investi oggi a padroneggiarlo lo reinvesti su ogni firewall che scriverai nei prossimi dieci anni, incluso quello che systemd, i container e ogni nuovo componente dell'ecosistema ormai danno per scontato. Se il censimento del tuo parco rivela firewall storici, doppi stack o script di avvio misteriosi, e preferisci che la migrazione la conduca qualcuno che l'ha già fatta molte volte, con la finestra concordata e il piano anti-lockout scritto, contattami per una consulenza: su un VPS tipico la migrazione completa sta in una mezza giornata, verifiche a freddo comprese.