Migrazione da iptables a nftables: conversione passo per passo e test

La migrazione da iptables a nftables è per molte infrastrutture Linux un passo necessario: nftables offre strumenti moderni per la gestione delle regole del firewall, strutture dati più efficienti e aggiornamenti atomici che minimizzano le finestre di indisponibilità durante il caricamento delle regole. In questa guida pratica descrivo un flusso riproducibile dall’inventario alla conversione fino ai test e al rollback. La guida è rivolta ad amministratori, ingegneri di sistema e operatori che devono tenere sotto controllo l’esercizio, le interfacce e le interazioni con Docker.

Perché passare da iptables a nftables?

iptables è cresciuto storicamente; nftables è una più recente API del kernel con un toolset userspace (nft) che gestisce le regole come un unico „ruleset“ centralizzato. I vantaggi sono un overhead CPU inferiore con grandi insiemi di regole, Set/Map per lookup performanti e operazioni di sostituzione delle regole atomiche. Questo è particolarmente rilevante se gestite molte voci dinamiche (per es. liste IP) o workload containerizzati.

Definizioni: „ruleset“ indica l’insieme di tutte le tabelle, chain e regole. „conntrack“ è il connection tracking nel kernel, che gestisce connessioni esistenti ed è essenziale per firewall stateful.

Preparazione: inventario, dipendenze e prerequisiti

Prima di convertire, fate l’inventario di host, servizi, uso di Docker, filtri esterni (Load Balancer, VPN) e di tutte le estensioni di iptables. Verificate la versione del kernel, l’installazione di libnftables e quale backend iptables è attualmente in uso (legacy vs nft).

Passaggi concreti

# iptables Regelwerk sichern (IPv4 und IPv6)
iptables-save > /root/iptables-save-$(date +%F).rules
ip6tables-save > /root/ip6tables-save-$(date +%F).rules

# Paket- und Kernel‑Status dokumentieren (Debian/Ubuntu Beispiel)
dpkg -l | egrep "nftables|iptables|libnft" > /root/pkg-list-$(date +%F).txt
uname -r > /root/kernel-version-$(date +%F).txt

Tooling: cosa aiuta e dove sono i limiti?

Strumenti disponibili:

• iptables-translate — converte singole regole iptables nella sintassi nftables; utile per la revisione manuale.
• iptables-save / iptables-RESTore — consolidati per il dump e il ripristino completo di regole iptables.
• nft — lo strumento centrale per nftables (caricare, verificare, elencare).

Importante: la conversione automatica non è mai affidabile al 100%. Match complessi, estensioni proprietarie, NFLOG, manipolazioni raw o moduli kernel speciali richiedono controllo manuale.

Migrazione da iptables a nftables: procedura (passo dopo passo)

1. Riprodurre l’ambiente di staging

Replicate la configurazione host, gli stack Docker e i profili di rete in un ambiente di test. Eseguite test con carichi e profili di connessione realistici in modo che gli effetti su conntrack e le pRESTazioni siano visibili.

2. Traduzione automatica e aggregazione

Un pattern comune è: leggere il dump di iptables, convertire le regole singolarmente con iptables-translate e trasferirle in un file nftables strutturato. In questo modo si possono raggruppare regole e creare set.

# Regeln per Script übersetzen und in Datei sammeln
iptables-save | grep -E "^-A" | while read -r rule; do
  # Regel ohne Präfix -A an iptables-translate übergeben
  trimmed=$(echo "$rule" | sed 's/^-A //')
  echo "$trimmed" | xargs -I '{}' iptables-translate '{}'
done > /root/translated.rules

3. Strutturazione e utilizzo dei set

Raggruppate regole simili in Tables/Chains e utilizzate Set per liste IP, porte o intervalli di porte — questo riduce il numero di regole e aumenta le pRESTazioni di lookup.

# Beispiel: Set für IPs und Anwendung in einer Chain
nft add table inet filter
nft 'add set inet filter trusted { type ipv4_addr; flags interval; }'
nft add element inet filter trusted { 10.10.0.1, 10.10.0.0/24 }

nft 'add chain inet filter input { type filter hook input priority 0; policy drop; }'
nft add rule inet filter input ip saddr @trusted accept

4. Verifica della sintassi e scambio atomico

Usate „nft -c -f“ per la verifica della sintassi e „nft replace ruleset“ per lo scambio atomico del ruleset attivo.

# Syntaxcheck
nft -c -f /root/created-nft-rules.conf

# Atomarer Austausch
nft replace ruleset < /root/created-nft-rules.conf

# Aktuellen Stand prüfen
nft list ruleset

5. Canary Rollout

Distribuite il nuovo ruleset inizialmente su pochi host. Monitorate la raggiungibilità, la latenza, la CPU e conntrack. In caso di problemi gli host canary consentono un rollback mirato senza impatto sul RESTo del cluster.

Test: funzionalità, analisi dei pacchetti e automazione

Testate su tre livelli: funzionale (raggiungibilità/policy), percorso dei pacchetti (tcpdump/pcap) e Connection Tracking (conntrack). Test automatizzati in CI garantiscono che le modifiche vengano validate prima del rilascio in produzione.

Esempi di comandi di test

# Reachability Test
curl -sS --connect-timeout 5 http://10.0.5.10:8080/health || echo "Service unreachable"

# Paketsammlung für Debug
tcpdump -i eth0 host 10.0.5.10 and port 8080 -c 200 -w /tmp/trace.pcap

# Conntrack Überblick
conntrack -L | head -n 50

Host Docker: opzioni e insidie

Docker crea nativamente iptables‑Chains (DOCKER, DOCKER‑USER) per NAT e port‑forwarding. Due approcci praticabili:

• Consentire a Docker di continuare a gestire iptables e affidarsi allo strato di compatibilità della distribuzione (iptables‑nft).
• Eseguire Docker con „–iptables=false“ e gestire manualmente tutte le regole NAT/filter — richiede significativamente più competenze.

Entrambe le strade hanno vantaggi e svantaggi. Nei sistemi di produzione è in genere meno rischioso testare progressivamente lo strato di compatibilità.

Test pratici per Docker

# docker daemon konfigurieren, damit es iptables nicht verändert
cat /etc/docker/daemon.json
# optional
# {
#   "iptables": false
# }
systemctl RESTart docker

# Überprüfen, ob DOCKER-USER Chain vorhanden ist
iptables -L DOCKER-USER -n

Conntrack: persistenza, limiti e timeout

conntrack conserva informazioni di stato sulle connessioni. Durante una migrazione le connessioni esistenti possono continuare a funzionare finché le voci di conntrack non vengono perse. Un reload del kernel o un ordine errato nel riavvio dei servizi di rete può però causare interruzioni delle connessioni.

Parametri sysctl rilevanti

# Beispiel: conntrack Kapazität erhöhen
sysctl -w net.netfilter.nf_conntrack_max=262144
# Persistenz in /etc/sysctl.d/99-nf.conf
# net.netfilter.nf_conntrack_max=262144

Motivazione: con un alto numero di connessioni un valore troppo basso di conntrack_max può provocare lo scarto di nuove connessioni. Pianificate le modifiche e misurate prima/dopo l’aggiustamento.

Ottimizzazione delle pRESTazioni: Set, Mappe e atomicità

Gli nftables‑Sets riducono il numero di regole di confronto dirette. Per tabelle molto grandi utilizzate flag come „interval“ o combinate con Counters per individuare i punti caldi. Aggiornamenti atomici prevengono incoerenze durante i Deployments.

Strategia di rollback e accesso d’emergenza

Un piano di rollback chiaramente documentato e testato è imprescindibile. Conservate gli iptables‑Saves in modo revisionabile e testate il ripristino in staging.

Esempio: ripristino rapido su iptables

# 1. Aktuelle nft Regeln sichern
nft list ruleset > /root/nft-backup-$(date +%F).conf

# 2. Vorherigen iptables Dump wiederherstellen
iptables-RESTore < /root/iptables-save-2023-09-01.rules
ip6tables-RESTore < /root/ip6tables-save-2023-09-01.rules

# 3. Docker neu starten (falls nötig)
systemctl RESTart docker

Suggerimento aggiuntivo: hinterlegen Sie das Rollback‑Playbook als ausführbares Script, das Teammitglieder nach einer kurzen Einweisung bedienen können.

Problemi frequenti und misure preventive

• Conflitti con firewalld/ufw: disattivate o migrate, altrimenti questi servizi sovrascrivono le regole al boot.
• Address Family Mismatch: indirizzi IPv6 in una tabella IPv4 causano errori; preferite la family „inet“ per regole comuni.
• Persistenza assente: abilitate il servizio systemd per nftables o assicuratevi che i vostri strumenti di gestione della configurazione ripristinino il file al boot.
• Il port‑forwarding di Docker perde connessione: testate i Port‑Mappings dopo ogni reload e verificate le catene DOCKER.

Quando rinviare la migrazione?

Rinviate la migrazione se siete in prossimità di finestre di rilascio importanti, se applicazioni third‑party critiche utilizzano estensioni proprietarie di iptables o se i vostri team Ops non sono sufficientemente esperti nel comportamento di Conntrack e nella gestione delle reti Docker. La migrazione è un progetto di infrastruttura e richiede tempo per test e formazione.

Riferimento rapido: comandi utili

# Regeln anzeigen
nft list ruleset

# Syntaxcheck
nft -c -f /path/to/file.conf

# Conntrack Übersicht
conntrack -L | wc -l

# Backup iptables
iptables-save > /root/iptables-backup.rules

# RESTore iptables
iptables-RESTore < /root/iptables-backup.rules

Accettazione, monitoraggio e esercizio operativo

Dopo il Go‑Live: esportate i Counters, collegate i Log‑Prefixes al vostro logging centrale e create dashboard per i tassi di DROP e l’utilizzo del conntrack. Pianificate smoke‑test regolari e mantenete host Canary come punto di verifica.

Routine di manutenzione

• Verifica giornaliera dei contatori DROP nelle prime settimane operative
• Validazione settimanale dei percorsi di rete dei container
• Sessioni di revisione mensili con registro delle modifiche

Conclusione

La migrazione da iptables a nftables è un passo valido per la manutenibilità a lungo termine, le pRESTazioni e la gestione coerente delle regole IPv4/IPv6. Fondamentali sono un’inventariazione accurata, test in staging, la validazione automatica e manuale delle regole convertite e un piano di rollback testato. Sui host Docker è particolarmente necessario procedere con cautela e verificare in dettaglio l’interazione con le catene DOCKER/DOCKER‑USER. Con controlli supportati da CI, Canary‑Rollouts e monitoraggio otterrete un percorso di migrazione stabile e riproducibile senza interruzioni operative.

Questa guida offre script di verifica concreti, indicazioni per il troubleshooting e una strategia di rollback praticabile, che possono essere integrati direttamente nei processi operativi esistenti. Iniziate in staging, automatizzate i test e amplifycate la visibilità del monitoring prima di passare in produzione.

Prassi: Governance e CI per la migrazione da iptables a nftables

Per una migrazione sicura da iptables a nftables non basta un singolo run. Istituite „Policy as Code“: le regole devono essere versionate in un repository, le modifiche devono passare la review, test automatizzati e un rollout graduale. Questo è particolarmente importante quando i controlli di accesso sono collegati strettamente a soluzioni software aziendali o a software di business.

Indicazioni architetturali per ambienti distribuiti

• Fonte di configurazione: un repository Git centrale con environments (staging, canary, prod) previene il drift.
• Distribuzione: Usate GitOps-Agents o strumenti CM, in modo che gli host ottengano la stessa configurazione nftables basata sullo stato.
• Cluster HA: Prestate attenzione all’ordine deterministico nell’applicazione (prima i nodi passivi), così le sessioni TCP esistenti non vengono interrotte inutilmente.

Verifiche e CI‑Gate

I controlli automatizzati devono coprire almeno i seguenti punti: sintassi, idempotenza, regressione delle policy (apertura di nuove porte), smoke test sulle prestazioni (numero di regole, dimensione dei set) e una simulazione del controllo pacchetti con pcap‑snippets.

# Beispiel: einfacher CI-Job (Pseudo-YAML) prüft ruleset
jobs:
  validate-nft:
    script:
      - nft -c -f changed.rules.conf    # Syntaxprüfung
      - ./tests/check-no-open-ports.sh  # Policy-Regressions-Test
      - ./tests/simulate-traffic.sh     # Paketpfad-Simulation

Operazioni: Persistenza, idempotenza e hook di rollback

Assicuratevi di avere una routine di applicazione idempotente. Un servizio systemd o un task del CM dovrebbe verificare se il ruleset è cambiato e applicarlo attivamente solo in quel caso. In questo modo evitate reload inutili e possibili interruzioni delle connessioni.

# Beispiel systemd-Unit für idempotentes Anwenden
[Unit]
Description=Apply nftables ruleset atomically
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/nft replace ruleset < /etc/nftables/rules.conf
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Monitoring, Audit und Alerting

Raccogliete metriche per chain e counter delle regole. Per integrazioni con monitoring‑stack potete esportare i contatori via cron e metterli a disposizione del node_exporter tramite il Textfile‑Collector. Gli alert dovrebbero attivarsi in caso di aumenti improvvisi dei DROP, di diminuzione della capacità di conntrack o di discrepanze nel numero di regole.

# Counters exportieren (Textfile für Prometheus node_exporter)
mkdir -p /var/lib/node_exporter/textfile_collector
nft list ruleset | grep counter -n > /var/lib/node_exporter/textfile_collector/nft_counters.prom

Compliance e gestione delle modifiche

Documentate ogni impostazione di regola con il responsabile, l’ID del ticket e la descrizione dell’impatto. Per soluzioni software integrate ai processi è utile taggare le regole con application‑tag (es. app:webshop), in modo che le query di audit possano essere mappate alle aree di business.

In sintesi: la migrazione è al contempo implementazione tecnica e processo organizzativo. Con versionamento, CI‑gates, deployment idempotenti, monitoring mirato e hook di rollback chiari minimizzate i rischi e garantite che requisiti di sicurezza e operatività vengano rispettati in modo riproducibile anche dopo la migrazione.

Indicazioni operative per la migrazione da iptables a nftables

Negli ambienti live non conta solo la conversione, ma anche come orchestrare stati, contatori e rollout distribuiti. Utilizzate aggiornamenti atomici dei set („nft replace element“) per modificare liste IP o liste di porte senza effettuare un reload completo del ruleset; questo minimizza le interruzioni delle connessioni e preserva le voci di conntrack. Tenete presente che un „nft replace ruleset“ completo può azzerare i contatori—esportate i contatori prima di modifiche critiche se è necessaria la continuità del monitoring.

Nei cluster HA o durante rolling updates: operate con un ordine deterministico (prima i nodi passivi), testate il comportamento con sessioni reali e automatizzate il rollback. Aggiungete metadati alle regole (es. app:webshop) e versionate i ruleset in Git, in modo che le verifiche rispetto a software aziendale specifico o a business service siano tracciabili e auditabili.