iptables vs. nftables unter Ubuntu: Was läuft wirklich?

iptables vs nftables unter Ubuntu: Welche Variante läuft auf Ihrem Server?

Unter Ubuntu 20.04 und höher ist der Befehl iptables ein Frontend, das nftables-Regeln schreibt. Im Kernel läuft ein Paketfilter, nftables, und zwei Befehle im Userspace konfigurieren ihn. Eine Zeile mit iptables -A INPUT funktioniert weiterhin genau wie zuvor. Die dadurch erstellte Regel ist eine nftables-Regel, die nft ausgeben kann.

Prüfen Sie das auf Ihrem eigenen Server, bevor Sie davon ausgehen.

iptables -V
sudo update-alternatives --display iptables
sudo nft list ruleset

Unter Ubuntu 24.04 (iptables 1.8.10, Stand August 2026) gibt iptables -V den Wert iptables v1.8.10 (nf_tables) aus. Der Name in Klammern bezeichnet das Backend. (nf_tables) bedeutet, dass der Befehl mit nftables kommuniziert. (legacy) bedeutet, dass das alte x_tables-Backend verwendet wird, das Ubuntu weiterhin als iptables-legacy ausliefert und das der Kernel als vollständig getrennten Regelsatz verwaltet. update-alternatives gibt den Symlink hinter dieser Auswahl aus: link currently points to /usr/sbin/iptables-nft.

Auf einem frisch eingerichteten VPS ohne konfigurierte Firewall gibt sudo nft list ruleset nichts aus. Diese leere Ausgabe ist Ihr Ausgangszustand. Fügen Sie auf die alte Weise eine Regel hinzu und prüfen Sie die Ausgabe erneut.

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo nft list ruleset

# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
  chain INPUT {
    type filter hook input priority filter; policy accept;
    tcp dport 22 counter packets 0 bytes 0 accept
  }
  chain FORWARD {
    type filter hook forward priority filter; policy accept;
  }
  chain OUTPUT {
    type filter hook output priority filter; policy accept;
  }
}

Ihre iptables-Regel ist eine nftables-Regel. iptables-nft kennzeichnet die Tabellen, die der Befehl erstellt. nft gibt diese Warnung aus, wenn die Kennzeichnung erkannt wird, weil das Bearbeiten einer solchen Tabelle mit nft dazu führt, dass zwei Werkzeuge denselben Regelsatz verwalten. Sehen Sie sich an, was ein einzelner Befehl erzeugt hat: eine Tabelle, die Sie nicht benannt haben, und Chains, die Sie nicht angefordert haben. Das ist das alte Modell. Es ist die erste grundlegende Änderung, wenn Sie nftables direkt konfigurieren.

Was iptables -L vor Ihnen verbirgt

iptables -L zeigt nur die Tabelle filter an. NAT-Regeln (Network Address Translation) benötigen iptables -t nat -L, und Mangle-Regeln benötigen -t mangle. IPv6 wird mit dem separaten Befehl ip6tables verwaltet, der für jede Regel eine eigene Kopie enthält. Ein System kann daher in einer Auflistung sauber aussehen, während etwas Ihre Pakete aus einer Tabelle verwirft oder umschreibt, die Sie nie geprüft haben.

sudo nft list ruleset gibt jede Protokollfamilie, jede Tabelle, jede Chain und jede Regel in einer Ausgabe aus. Auf einem Server, den Sie nicht selbst eingerichtet haben, ist dieser einzelne Befehl der schnellste Weg, um zu sehen, was tatsächlich geladen ist. Ergänzen Sie -a, um die Regel-Handles auszugeben. Diese benötigen Sie, um eine einzelne Regel statt der gesamten Chain zu löschen.

Zwei Gewohnheiten sollten Sie an dieser Stelle korrigieren. iptables -L löst Adressen und Ports in Namen auf. Auf einem System mit einem fehlerhaften Resolver wirkt es daher, als sei der Befehl hängen geblieben: Verwenden Sie iptables -nvL. Vergewissern Sie sich außerdem mit sudo iptables-legacy -nvL, dass das Legacy-Backend leer ist. Wenn in beiden Backends Regeln vorhanden sind, wertet der Kernel beide aus, und keine der beiden Auflistungen zeigt das vollständige Bild.

Tabellen und Chains, die Sie selbst anlegen

nftables startet ohne Konfiguration. Es gibt keine filter-Tabelle, bis Sie eine anlegen. filter ist lediglich ein von Ihnen gewählter Name. Eine Chain verarbeitet Pakete nur, wenn Sie ihr einen Typ, einen Hook und eine Priorität zuweisen. Dadurch wird sie zu einer Base Chain. Eine Chain ohne diese Angaben wird nur durch ein explizites jump oder goto erreicht. Sie verursacht daher keinen Aufwand, bis etwas zu ihr springt.

Die andere große Änderung betrifft die inet-Familie. Eine inet-Tabelle verarbeitet IPv4 und IPv6 mit denselben Regeln. Dadurch entfällt eine ganze Fehlerklasse, bei der ein Port in iptables geschlossen und in ip6tables vollständig offen ist. Diese Abweichung kommt häufig genug vor, um bei ufw-Servern einen eigenen Fehlerfall darzustellen.

Hier ist ein vollständiger Regelsatz für einen Server. Er gehört in /etc/nftables.conf.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set admin_ips {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.5, 198.51.100.0/24 }
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp accept
    meta l4proto ipv6-icmp accept
    tcp dport 22 ip saddr @admin_ips counter accept
    tcp dport { 80, 443 } counter accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
  }

  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Lesen Sie Zeile 2 zweimal. flush ruleset löscht jede Tabelle auf dem Server, einschließlich der Tabellen, die ufw und Docker selbst angelegt haben. Lesen Sie weiter, bevor Sie den Befehl auf einem produktiven Server ausführen.

Die erste Regel in der Input-Chain erledigt den größten Teil der Arbeit. ct state established,related accept lässt Antworten auf von Ihnen gestartete Verbindungen wieder herein. Dadurch muss die restliche Chain nur über neue Verbindungen entscheiden. ct state invalid drop verwirft Pakete, die keiner bekannten Verbindung und keinem gültigen Verbindungsaufbau zugeordnet werden können. Alles danach ist eine explizit erlaubte Ausnahme. policy drop verarbeitet den übrigen Datenverkehr.

Prüfen Sie die Datei, bevor Sie sie laden, und halten Sie währenddessen eine zweite SSH-Sitzung offen. policy drop sperrt Sie zusammen mit einem einzigen Tippfehler in der SSH-Regel aus Ihrem eigenen Server aus.

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

nft -c -f analysiert die Datei und meldet Fehler, ohne etwas zu laden. Eine fehlerfreie Analyse erzeugt überhaupt keine Ausgabe.

Sets ersetzen lange Regellisten

tcp dport { 80, 443 } ist ein anonymes Set: eine Regel und eine Abfrage statt einer Regel pro Port. Ein benanntes Set wie admin_ips geht noch weiter, weil Sie es ändern können, während die Firewall läuft.

sudo nft add element inet filter admin_ips { 203.0.113.9 }
sudo nft list set inet filter admin_ips
sudo nft delete element inet filter admin_ips { 203.0.113.9 }

Kein Reload, keine Neunummerierung der Regeln. Die Übereinstimmungsprüfung bleibt eine einzelne Abfrage, unabhängig davon, ob das Set fünf Adressen oder fünfzigtausend Adressen enthält. flags interval ermöglicht es, in einem Set Bereiche und CIDR-Präfixe (Classless Inter-Domain Routing) wie 198.51.100.0/24 zu speichern. Ohne dieses Flag akzeptiert das Set nur einzelne Adressen. Das Laden des Präfixes schlägt dann fehl.

Elemente in Sets können auch automatisch ablaufen.

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

Bei einer Regel mit ip saddr @banned drop entfernt sich jedes Element eine Stunde nach dem Hinzufügen selbst. So sperrt die nftables-Aktion in fail2ban unter Ubuntu 24.04 eine Adresse: Sie fügt ein Element zu einem Set hinzu, statt eine Regel hinzuzufügen. Wenn Ports für Sie noch Neuland sind, beginnen Sie mit was ein Port unter Linux tatsächlich ist.

Bei einer Migration führt ein Unterschied häufig zu Problemen. nftables zählt Pakete nur, wenn Sie dies ausdrücklich anfordern. iptables -nvL zeigt immer die Zähler für jede Regel an. In nftables haben nur Regeln mit dem Schlüsselwort counter Nummern. Fügen Sie daher counter in jede Regel ein, die Sie später debuggen möchten.

Wie Hooks und Prioritäten die Reihenfolge bestimmen

Eine Base Chain gibt einen Hook an. Dieser legt fest, an welcher Stelle im Paketpfad die Chain ausgeführt wird. prerouting wird vor der Routing-Entscheidung ausgeführt. input gilt für Pakete, die an diesen Rechner adressiert sind. forward gilt für Pakete, die durch diesen Rechner geroutet werden. output gilt für Pakete lokaler Prozesse. postrouting wird zuletzt ausgeführt, direkt bevor das Paket den Rechner verlässt.

Die Priorität bestimmt die Reihenfolge der Chains innerhalb eines Hooks. Die niedrigste Zahl wird zuerst ausgeführt. nftables verwendet für die klassischen Werte Namen: raw ist -300, mangle ist -150, dstnat ist -100, filter ist 0 und srcnat ist 100. priority filter; zu schreiben ist dasselbe wie priority 0; zu schreiben.

Nun zum entscheidenden Punkt für die Frage, ob sich die Tools kombinieren lassen. Jede auf einem Hook registrierte Base Chain wird in Prioritätsreihenfolge ausgeführt. Wird ein Paket in Ihrer Chain akzeptiert, ist die Verarbeitung noch nicht abgeschlossen: accept beendet nur diese Chain. Das Paket wird an die nächste Base Chain desselben Hooks weitergereicht. drop ist überall endgültig und stoppt das Paket sofort. Eine freizügige Regel in Ihrer Tabelle kann daher einen Drop in der Tabelle von ufw nicht rückgängig machen, unabhängig davon, welche Chain zuerst ausgeführt wird. Auch Ihr accept schützt Sie nicht vor einer Chain, die später ausgeführt wird.

Zwei Base Chains desselben Hooks mit derselben Priorität werden in der Reihenfolge ihrer Registrierung ausgeführt. Diese hängt davon ab, welcher Dienst zuerst gestartet wurde. Die Reihenfolge kann sich nach einem Reboot ändern. Wenn Sie neben ufw eine eigene Tabelle betreiben müssen, geben Sie ihr eine eigene Priorität. Dadurch ist die Reihenfolge festgelegt und hängt nicht vom Startzeitpunkt ab.

Warum gibt es keine Regel für das Reverse-NAT?

Das ist die Frage, bei der die meisten Fehler gemacht werden. Hier ist die direkte Antwort: Das Connection Tracking schreibt die umgekehrte Übersetzung automatisch. Sie müssen keine zweite Regel hinzufügen.

Eine nat-Tabelle, die beide Hälften der üblichen VPS-Aufgabe übernimmt, sieht so aus.

table inet nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "enp1s0" tcp dport 8080 dnat ip to 10.0.0.5:80
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.0.0.0/24 oifname "enp1s0" masquerade
  }
}

Nur das erste Paket einer Verbindung wird gegen eine nat-Chain ausgewertet. Wenn eine Regel greift, speichert der Kernel diese Übersetzung zusammen mit dem Verbindungseintrag in der Connection-Tracking-Tabelle. Jedes spätere Paket wird in beide Richtungen anhand dieses gespeicherten Eintrags umgeschrieben. Keine Regel wird erneut gelesen. Installieren Sie das Tool conntrack und sehen Sie sich einen aktiven Eintrag an.

sudo apt install -y conntrack
sudo conntrack -L -p tcp

tcp 6 431999 ESTABLISHED src=198.51.100.20 dst=203.0.113.10 sport=54321 dport=8080 src=10.0.0.5 dst=198.51.100.20 sport=80 dport=54321 [ASSURED] mark=0 use=1

Lesen Sie den Eintrag als zwei Tupel. Die ersten vier Felder beschreiben die vom Client gesendete Verbindung an 203.0.113.10:8080, Ihre öffentliche Adresse. Die zweiten vier Felder beschreiben die Antwort, die der Kernel erwartet. Sie sind bereits umgekehrt und übersetzt und kommen von 10.0.0.5:80, dem tatsächlichen Backend. Dieses zweite Tupel ist die umgekehrte Regel. Der Kernel hat es erstellt, als die erste Regel auf das erste Paket angewendet wurde.

Schreiben Sie daher keine Regel für die Rückrichtung. Sie kann nicht greifen, weil Antwortpakete zu einer bestehenden Verbindung gehören und niemals eine nat-Chain erreichen. Falls sie dennoch greifen würde, würden Sie ein Paket übersetzen, das der Kernel bereits korrekt bearbeitet hat.

Wo eine Umschreibung platziert werden muss, ergibt sich aus demselben Mechanismus. Eine Zielübersetzung muss in prerouting ausgeführt werden, also vor der Routing-Entscheidung. Das Routing muss das neue Ziel sehen, sonst wird das Paket an den falschen Ort weitergeleitet. Vom System selbst erzeugter Datenverkehr wird aus demselben Grund im Hook output verarbeitet. Eine Quellübersetzung, einschließlich der Umschreibung eines Quellports, muss in postrouting ausgeführt werden, nachdem das Routing das ausgehende Interface ausgewählt hat. masquerade übernimmt seine Adresse von diesem Interface. Das Interface ist erst nach dem Routing bekannt.

Darum gehört eine Regel wie diese ans Ende des Pfads und nirgendwo sonst.

ip saddr 10.0.0.0/24 oifname "enp1s0" snat ip to 203.0.113.10:20000-30000

Der Portbereich schreibt zusammen mit der Quelladresse auch den Quellport um. Das ist erforderlich, wenn viele interne Clients eine öffentliche Adresse gemeinsam verwenden und ihre Quellports kollidieren. Eine Antwort trifft an einem Port in diesem Bereich ein. Conntrack ordnet sie dem Eintrag zu und stellt den ursprünglichen Quellport wieder her, bevor das Paket zugestellt wird. Auch hier ist keine zweite Regel erforderlich.

Eine praktische Folge: Wenn Sie eine NAT-Regel ändern, werden bereits bestehende Verbindungen nicht verschoben, weil ihre Übersetzung bereits gespeichert ist. Sie behalten das bisherige Verhalten bei, bis ihre Einträge ablaufen. sudo conntrack -D -p tcp --dport 8080 löscht die passenden Einträge, und sudo conntrack -F löscht alle Einträge. Verwenden Sie den zweiten Befehl auf einem NAT-System mit Vorsicht. Diese gespeicherten Übersetzungen halten die aktuellen Verbindungen aufrecht. Wenn Sie sie leeren, werden alle Verbindungen über dieses System gleichzeitig unterbrochen.

ufw und Docker schreiben jeweils eigene Regeln

ufw ist ein Frontend für iptables, das unter Ubuntu wiederum ein Frontend für nftables ist. Auf einem ufw-System gibt es daher eine ip filter-Tabelle mit zahlreichen Chains namens ufw-before-input, ufw-user-input und so weiter sowie eine ip6 filter-Kopie derselben Struktur. Sehen Sie sich diese mit sudo nft list ruleset | grep ufw an. Diese Chains werden aus den Dateien in /etc/ufw erzeugt, und ufw reload schreibt sie bei jedem Durchlauf vollständig neu. Deshalb verschwindet eine manuell hinzugefügte iptables-Regel beim nächsten Reload. Die ufw-Grundlagen für einen VPS erläutern diesen Datei-Aufbau.

Docker programmiert die Firewall selbst und berücksichtigt ufw nicht. Das Veröffentlichen eines Ports mit -p 80:80 schreibt eine DNAT-Regel in die nat-Tabelle und eine Accept-Regel in den Forward-Pfad. Beide werden vor den Benutzer-Chains von ufw verarbeitet. Das Ergebnis überrascht viele beim ersten Mal: ufw deny 80 ist geladen, und der Container ist trotzdem aus dem Internet erreichbar. Die Lösung befindet sich in der DOCKER-USER-Chain, die Docker für Ihre Regeln bereitstellt. Warum Docker-Container ufw ignorieren erklärt den Ablauf. Mit sudo nft list ruleset | grep -i docker sehen Sie, welche Regeln auf Ihrem System vorhanden sind.

Lesen Sie nun die flush ruleset-Zeile aus der obigen Konfiguration erneut. Sie löscht jede Tabelle, einschließlich der Tabellen, die von diesen beiden Tools verwaltet werden. Auf einem Docker-Host funktionieren veröffentlichte Ports nicht mehr, bis sudo systemctl restart docker die Chains neu erstellt. Diese eine Zeile ist die häufigste Ursache dafür, dass Administratoren beim Aufräumen einer Firewall ihre eigenen Dienste offline nehmen.

Regeln, die einen Reboot überstehen

Keines der beiden Regelwerke ist allein persistent. Der Kernel verwirft beim Herunterfahren alle Regeln. Jede Seite löst das mit einem eigenen Paket.

Bei nftables wird /etc/nftables.conf von nftables.service eingelesen. Ubuntu liefert diesen Dienst deaktiviert aus. Prüfen Sie ihn daher, bevor Sie sich darauf verlassen.

systemctl is-enabled nftables
sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

Bei iptables heißt das Paket iptables-persistent. Es installiert netfilter-persistent und speichert die Regeln in /etc/iptables/rules.v4 und /etc/iptables/rules.v6.

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

Führen Sie nicht beide Varianten aus. Zwei Dateien, die jeweils das Firewall-Regelwerk enthalten sollen, laufen auseinander. Welche Datei zuletzt geladen wird, lässt sich anhand der Dateien nicht zuverlässig vorhersagen.

Ein verwandtes Problem tritt beim Export eines aktiven Regelwerks auf. sudo nft -s list ruleset > /etc/nftables.conf erfasst alles, was zu diesem Zeitpunkt geladen ist, einschließlich der Tabellen von ufw und Docker. Wenn Sie diesen Export beim Boot wiederherstellen, erhalten Sie eine eingefrorene Kopie von Regeln, die diese Werkzeuge eigentlich selbst erstellen sollen. Sobald die Werkzeuge starten, kommt eine zweite Kopie hinzu. Exportieren Sie nur Ihre eigene Tabelle mit sudo nft -s list table inet filter. Das Flag -s lässt die Zähler weg. Diese gehören nicht in eine Konfigurationsdatei.

Sollten Sie Ihren VPS auf native Regeln umstellen?

Lassen Sie ufw unverändert, sofern Sie keine Funktion benötigen, die sich damit nicht abbilden lässt. ufw deckt den üblichen Anwendungsfall eines VPS ab: standardmäßig den gesamten Verkehr ablehnen und nur wenige Ports öffnen. Wenn Sie dies ohne konkreten Grund durch ein von Hand geschriebenes Regelwerk ersetzen, haben Sie dieselbe Firewall und zusätzlich ein weiteres Regelwerk zu warten.

Verwenden Sie native Regeln, wenn Sie etwas benötigen, das außerhalb des Modells von ufw liegt: NAT und Portweiterleitungen, Sets, die Sie zur Laufzeit aktualisieren, eine Regel für beide Adressfamilien oder selbst festgelegte Prioritäten für Chains. Das sind konkrete Gründe. ufw kann keine dieser Anforderungen abbilden.

Wenn Sie auf native Regeln umstellen, dann vollständig. Führen Sie sudo ufw disable und sudo systemctl disable --now ufw aus. Prüfen Sie mit sudo nft list ruleset, dass die Tabellen von ufw entfernt wurden. Laden Sie anschließend Ihre eigene Datei. Ein System, auf dem ufw und ein von Hand geschriebenes Tabellenwerk parallel laufen, lässt den Netzwerkverkehr weiterhin passieren. Die aktive Policy ist dann jedoch die Vereinigung zweier Regelwerke, die in einer durch den Start der Dienste festgelegten Reihenfolge ausgewertet werden. Niemand kann anhand einer der beiden Dateien allein erkennen, wie sich das System tatsächlich verhält.

Migration eines vorhandenen iptables-Regelsatzes

iptables-translate konvertiert eine Regel und gibt die entsprechende nftables-Form aus. Am System wird dabei nichts geändert.

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT

nft add rule ip filter INPUT tcp dport 22 counter accept

iptables-restore-translate -f /etc/iptables/rules.v4 erledigt dasselbe für einen vollständig gespeicherten Regelsatz. Betrachten Sie die Ausgabe als ersten Entwurf. Die Konvertierung erfolgt mechanisch und Regel für Regel. Deshalb erhalten Sie die alten Namen für Tabellen und Chains, zwei getrennte Regelsätze für IPv4 und IPv6 sowie keine Sets, die den Umstieg sinnvoll machen. Schreiben Sie den Regelsatz von Hand als eine gemeinsame inet-Tabelle neu. Prüfen Sie ihn anschließend mit nft -c -f, bevor er auf einem produktiven Server eingesetzt wird.

Die Adressen in diesen Beispielen stammen aus den Dokumentationsbereichen 203.0.113.0/24 und 198.51.100.0/24. enp1s0 ist ein Schnittstellenname. Ermitteln Sie Ihre Werte mit ip route show default und ip -br addr, statt meine zu kopieren, da aktuelle Ubuntu-Images nur selten etwas eth0 nennen.

FAQ

Ist iptables auf Ubuntu veraltet?

Der Befehl wird nicht entfernt und funktioniert weiterhin unter Ubuntu 24.04. Geändert hat sich, was im Hintergrund passiert: iptables ist ein Frontend, das über das Backend iptables-nft nftables-Regeln schreibt. Prüfen Sie Ihre Konfiguration mit iptables -V. Der Befehl gibt unter 24.04 iptables v1.8.10 (nf_tables) aus. Das alte Backend x_tables wird weiterhin als iptables-legacy ausgeliefert. Es verwaltet einen vollständig getrennten Regelsatz. Legen Sie Regeln daher in genau einem Backend an, nicht in beiden.

Benötige ich eine zweite Regel, um NAT auf dem Rückweg rückgängig zu machen?

Nein. Connection Tracking speichert die Übersetzung, sobald das erste Paket einer Verbindung auf eine nat-Regel trifft. Jedes weitere Paket in beide Richtungen wird anhand dieses gespeicherten Eintrags umgeschrieben. sudo conntrack -L zeigt dies als zwei Tupel pro Verbindung: zuerst die ursprüngliche Richtung, danach die bereits umgekehrte Antwort. Eine Regel für die Rückrichtung hilft nicht, weil Antwortpakete keine nat-Kette erreichen.

Kann ich ufw und eigene nftables-Regeln gleichzeitig verwenden?

Das funktioniert, führt aber zu Problemen. Jede Base Chain an einem Hook wird ausgeführt. Die aktive Richtlinie ist daher eine Kombination aus beiden Regelsätzen. Die Reihenfolge ergibt sich aus der Priorität und bei gleicher Priorität daraus, welcher Dienst zuerst gestartet wurde. Ein drop in einem der beiden Regelsätze ist endgültig. Ein accept in Ihrem Regelsatz verhindert nicht, dass der andere Regelsatz dasselbe Paket verwirft. Verwenden Sie nur ein Werkzeug. Wenn Sie nftables verwenden, deaktivieren Sie zuerst ufw und prüfen Sie mit sudo nft list ruleset, ob dessen Tabellen entfernt wurden.

Wie bleiben nftables-Regeln nach einem Reboot unter Ubuntu erhalten?

Legen Sie den Regelsatz in /etc/nftables.conf ab, prüfen Sie ihn mit sudo nft -c -f /etc/nftables.conf und führen Sie anschließend sudo systemctl enable --now nftables aus. Der Dienst ist standardmäßig nicht aktiviert. Daher sollten Sie einmal systemctl is-enabled nftables ausführen. Wenn Sie diese Datei erzeugen, exportieren Sie mit sudo nft -s list table inet filter nur Ihre eigene Tabelle. Ein vollständiger list ruleset-Export enthält auch die Tabellen, die ufw und Docker selbst verwalten.