Migration von iptables zu nftables: Schritt‑für‑Schritt‑Konvertierung und Tests

Die Migration von iptables zu nftables ist für viele Linux‑Infrastrukturen ein notwendiger Schritt: nftables bietet moderne Mittel zur Verwaltung von Firewallregeln, effizientere Datenstrukturen und atomare Updates, die Ausfallfenster beim Laden von Regeln minimieren. In dieser praxisorientierten Anleitung beschreibe ich einen reproduzierbaren Ablauf von Inventarisierung über Konvertierung bis zu Tests und Rollback. Die Anleitung richtet sich an Administratoren, System Engineers und Operatoren, die Betrieb, Schnittstellen und Docker‑Interaktionen im Blick behalten müssen.

Warum von iptables zu nftables wechseln?

iptables ist historisch gewachsen; nftables ist eine neuere Kernel‑API mit einem Userspace‑Toolset (nft), das Regeln als ein zentrales „ruleset“ verwaltet. Vorteile sind geringerer CPU‑Overhead bei großen Regelwerken, Sets/Maps für performante Lookups und atomare Regeln‑Ersatzoperationen. Das ist besonders relevant, wenn Sie viele dynamische Einträge (z. B. IP‑Listen) oder containerisierte Workloads betreiben.

Begriffserklärung: „ruleset“ bezeichnet die Gesamtheit aller Tabellen, Chains und Regeln. „conntrack“ ist das Connection Tracking im Kernel, das bestehende Verbindungen verwaltet und für zustandsbehaftete Firewalls essentiell ist.

Vorbereitung: Inventarisierung, Abhängigkeiten und Voraussetzungen

Bevor Sie konvertieren, inventarisieren Sie Hosts, Services, Docker‑Nutzung, externe Filter (Load Balancer, VPN) und alle iptables‑Erweiterungen. Prüfen Sie Kernel‑Version, libnftables‑Install und das aktuell genutzte iptables‑Backend (legacy vs nft).

Konkrete Schritte

# 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: Was hilft, und wo sind die Grenzen?

Verfügbare Werkzeuge:

• iptables-translate — übersetzt einzelne iptables‑Regeln in nftables‑Syntax; gut für manuelle Nacharbeit.
• iptables-save / iptables-restore — bewährt zum Sichern und Rückspielen kompletter iptables‑Dumps.
• nft — Kernwerkzeug für nftables (laden, prüfen, listen).

Wichtig: Automatische Konvertierung ist niemals 100% fehlerfrei. Komplexe Matches, proprietäre Erweiterungen, NFLOG, raw‑Manipulationen oder spezielle Kernelmodule erfordern manuelle Kontrolle.

Migration von iptables zu nftables: Vorgehensweise (Schritt für Schritt)

1. Staging‑Umgebung abbilden

Replizieren Sie Hostkonfiguration, Docker‑Stacks und Netzwerkprofile in einer Testumgebung. Testen Sie mit realistischen Last‑ und Verbindungsprofilen, damit conntrack‑ und Performance‑Auswirkungen sichtbar werden.

2. Automatische Übersetzung und Aggregation

Ein übliches Muster ist: iptables‑Dump lesen, Regeln einzeln mit iptables-translate konvertieren und in eine strukturierte nftables‑Datei überführen. So lassen sich Regeln gruppieren und Sets erzeugen.

# 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. Strukturierung und Nutzung von Sets

Fassen Sie gleichartige Regeln in Tables/Chains zusammen und verwenden Sie Sets für IP‑Listen, Ports oder Port‑Bereiche — das reduziert die Regelanzahl und erhöht Lookup‑Performance.

# 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. Syntaxprüfung und atomarer Austausch

Nutzen Sie „nft -c -f“ für Syntaxprüfungen und „nft replace ruleset“ für atomaren Tausch des aktiven rulesets.

# 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

Führen Sie das neue ruleset zuerst auf wenigen Hosts ein. Überwachen Sie Reachability, Latenz, CPU und conntrack. Bei Problemen erlauben Canary‑Hosts gezieltes Zurückrollen ohne Clusterweiteren Einfluss.

Tests: Funktionalität, Paketanalyse und Automatisierung

Testen Sie drei Ebenen: Funktional (Reachability/Policy), Paketpfad (tcpdump/pcap) und Connection Tracking (conntrack). Automatisierte Tests in CI sorgen dafür, dass Änderungen vor dem Produktivwechsel validiert werden.

Beispiele für Testkommandos

# 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

Docker‑Hosts: Optionen und Fallstricke

Docker erzeugt nativerweise iptables‑Chains (DOCKER, DOCKER‑USER) für NAT und Port‑Forwarding. Zwei praktikable Ansätze:

• Weiterhin Docker mit iptables erlauben und auf die Distribution‑Kompatibilitätsschicht (iptables‑nft) vertrauen.
• Docker mit „–iptables=false“ betreiben und alle NAT/Filterregeln selbst verwalten — erfordert deutlich mehr Know‑how.

Beide Wege haben Vor‑ und Nachteile. Bei produktiven Systemen ist der schrittweise Test der Kompatibilitätsschicht meist risikoärmer.

Praktische Docker‑Tests

# 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: Erhaltung, Limits und Timeouts

conntrack hält Zustandsinformationen zu Verbindungen. Bei Migration können bestehende Verbindungen weiterlaufen, solange conntrack‑Entries nicht verloren gehen. Ein Reload des Kernels oder eine falsche Reihenfolge beim Neustart von Netzwerkdiensten kann jedoch zu Verbindungsabbrüchen führen.

Wichtige Sysctl‑Parameter

# 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

Begründung: Bei hohem Verbindungsaufkommen kann ein zu kleines conntrack_max dazu führen, dass neue Verbindungen verworfen werden. Planen Sie Änderungen und messen Sie vor/nach der Anpassung.

Performance‑Optimierung: Sets, Maps und Atomicity

nftables‑Sets reduzieren die Anzahl direkter Vergleichsregeln. Für sehr große Tabellen nutzen Sie flags wie „interval“ oder kombinieren Sie mit Counters, um Hotspots zu erkennen. Atomare Updates verhindern Inkonsistenzen während Deployments.

Rollback‑Strategie und Notfallzugang

Ein klar dokumentierter und getesteter Rollback‑Plan ist unerlässlich. Bewahren Sie iptables‑Saves revisionssicher auf und testen Sie das Wiederherstellen in Staging.

Beispiel: Schnelles Rückrollen auf 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

Zusätzlicher Tipp: Hinterlegen Sie das Rollback‑Playbook als ausführbares Script, das Teammitglieder nach einer kurzen Einweisung bedienen können.

Häufige Stolperfallen und präventive Maßnahmen

• Konflikte mit firewalld/ufw: Deaktivieren oder migrieren, sonst überschreiben diese Dienste Regeln beim Boot.
• Address Family Mismatch: IPv6‑Adressen in einer IPv4‑Table verursachen Fehler; bevorzugen Sie die „inet“‑Family für gemeinsame Regeln.
• Fehlende Persistenz: Aktivieren Sie systemd‑Service für nftables oder stellen Sie sicher, dass Ihre Konfigurationsmanagement‑Tools die Datei beim Boot wiederherstellen.
• Docker Port‑Forwarding verliert Verbindung: Testen Sie Port‑Mappings nach jedem Reload und prüfen Sie DOCKER‑Chains.

Wann Migration verschieben?

Schieben Sie Migration auf, wenn Sie kurz vor großen Release‑Fenstern stehen, wenn kritische Third‑Party‑Applikationen proprietäre iptables‑Extensions nutzen oder wenn Ihre Ops‑Teams nicht ausreichend in Conntrack‑Verhalten und Docker‑Netzwerkverwaltung geübt sind. Migration ist ein Infrastrukturprojekt und braucht Zeit für Tests und Training.

Kurzreferenz: Nützliche Befehle

# 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

Abnahme, Monitoring und laufender Betrieb

Nach dem Go‑Live: Exportieren Sie Counters, binden Sie Log‑Prefixes an Ihr zentrales Logging und erstellen Sie Dashboards für DROP‑Raten und conntrack‑Auslastung. Planen Sie regelmäßige Smoke‑Tests und behalten Sie Canary‑Hosts als Prüfstein bei.

Wartungsroutine

• Tägliche Überprüfung der DROP‑Zähler in den ersten Betriebswochen
• Wöchentliche Validierung der Container‑Netzwerkpfade
• Monatliche Review‑Sessions mit Änderungsprotokoll

Fazit

Die Migration von iptables zu nftables ist ein lohnender Schritt für langfristige Wartbarkeit, Performance und konsistente Verwaltung von IPv4/IPv6‑Regeln. Entscheidend sind gründliche Inventarisierung, Staging‑Tests, automatische und manuelle Validierung der konvertierten Regeln sowie ein getesteter Rollback‑Plan. Besonders bei Docker‑Hosts sollten Sie vorsichtig vorgehen und die Interaktion mit DOCKER/DOCKER‑USER Chains detailliert prüfen. Mit CI‑gestützten Prüfungen, Canary‑Rollouts und Monitoring erreichen Sie einen stabilen, reproduzierbaren Migrationspfad ohne Betriebsunterbrechung.

Diese Anleitung bietet konkrete Prüfskripte, Troubleshooting‑Hinweise und eine praktikable Rollback‑Strategie, die direkt in bestehende Betriebsprozesse integriert werden können. Beginnen Sie in Staging, automatisieren Sie Tests, und erweitern Sie Ihre Monitoring‑Sicht, bevor Sie in die Produktion gehen.

Praxis: Governance und CI für die Migration von iptables zu nftables

Für eine sichere Migration von iptables zu nftables reicht ein einmaliger Run nicht aus. Etablieren Sie „Policy as Code“: Regeln liegen versioniert in einem Repository, Changes durchlaufen Review, automatisierte Tests und ein abgestuftes Rollout. Das ist besonders wichtig, wenn Zugriffskontrollen prozessnah an individuelle Unternehmenssoftware oder an Business-Software gekoppelt sind.

Architekturhinweise für verteilte Umgebungen

• Konfigurationsquelle: Ein zentrales Git-Repo mit environments (staging, canary, prod) verhindert Drift.
• Verteilung: Nutzen Sie GitOps-Agents oder CM‑Tools, damit Hosts zustandsorientiert dieselbe nftables-Konfiguration beziehen.
• HA-Cluster: Achten Sie auf deterministische Reihenfolge beim Anwenden (zuerst passive Knoten), damit bestehende TCP‑Sessions nicht unnötig abreißen.

Prüfungen und CI‑Gate

Automatisierte Checks sollen mindestens folgende Punkte abdecken: Syntax, Idempotenz, Policy-Regression (öffnen neuer Ports), Performance‑Smoke (Regelanzahl, Set‑Größen) und eine simulierte Paketprüfung mit 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

Betrieb: Persistenz, Idempotenz und Rollback‑Hooks

Stellen Sie eine idempotente Anwendungsroutine sicher. Ein systemd-Service oder ein CM‑Task sollte prüfen, ob das ruleset sich ändert, und nur dann aktiv anwenden. So vermeiden Sie unnötige Reloads und mögliche Verbindungsunterbrechungen.

# 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

Erfassen Sie Metriken pro Chain und Rule-Counter. Für Integrationen in Monitoring‑Stacks können Sie die Zähler per Cron exportieren und dem Node‑Exporter Textfile‑Collector anbieten. Alerts sollten bei sprunghaften DROP‑Anstiegen, sinkender conntrack‑Kapazität oder abweichender Regelanzahl ausgelöst werden.

# 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 und Change Management

Dokumentieren Sie jede Regelsetzung mit Verantwortlichem, Ticket‑ID und Auswirkungsbeschreibung. Bei prozessnahen Softwarelösungen ist es hilfreich, Regeln mit Anwendungstags (z. B. app:webshop) zu versehen, damit Audit‑Queries auf Geschäftsbereiche abbildbar sind.

Kurz gesagt: Migration ist technische Umsetzung und organisatorischer Prozess zugleich. Mit Versionierung, CI‑Gates, idempotenten Deployments, gezieltem Monitoring und klaren Rollback‑Hooks minimieren Sie Risiken und stellen sicher, dass Sicherheits- und Betriebsanforderungen auch nach der Umstellung reproduzierbar eingehalten werden.

Betriebshinweise für die Migration von iptables zu nftables

Bei Live‑Umgebungen entscheidet nicht nur die Konvertierung, sondern auch, wie Sie Zustände, Zähler und verteilte Rollouts orchestrieren. Nutzen Sie gezielt atomare Set‑Updates („nft replace element“), um IP‑Listen oder Port‑Listen ohne kompletten ruleset‑Reload zu ändern; das minimiert Verbindungsunterbrechungen und erhält conntrack‑Einträge. Beachten Sie, dass ein kompletter „nft replace ruleset“ Counters zurücksetzen kann—exportieren Sie Zähler vor kritischen Änderungen, wenn Monitoring‑Kontinuität nötig ist.

In HA‑Clustern oder bei Rolling‑Updates: Arbeiten Sie mit einer deterministischen Reihenfolge (zuerst passive Knoten), testen Sie das Verhalten mit realen Sessions und automatisieren Sie das Rollback. Versehen Sie Regeln mit Metadaten (z. B. app:webshop) und versionieren Sie rulesets im Git, so lassen sich Prüfungen gegen individuelle Unternehmenssoftware oder Business‑Services nachvollziehen und auditen.