Ein Kettenname ist kein Hook: iptables gegen nftables

Beide Firewalls können weitergeleiteten VPN-Verkehr filtern, und sie hängen Regeln auf unterschiedliche Weise an den Paketpfad. iptables hat eingebaute Ketten innerhalb einer Tabelle, daher existiert FORWARD als benannter Hook-Punkt. nftables trennt den Namen einer Kette von ihrem Typ, ihrem Hook und ihrer Priorität, was bedeutet, dass eine reguläre Kette namens FORWARD überhaupt nichts filtert. Der Vergleich beider Modelle erklärt, warum ein Eintrag, der in einem Werkzeug richtig aussieht, im anderen keine Wirkung hat.

Eine Kette ist ein Behälter. Ob der Kernel sie heranzieht, hängt von der Implementierung ab und davon, wie das Regelset sie anhängt.

Zwei Modelle, zwei verschiedene Anhänge

In iptables liefert die filter-Tabelle drei eingebaute Ketten, INPUT, FORWARD und OUTPUT, und -N erzeugt eine benutzerdefinierte Kette, die erst wirkt, wenn aus einer von ihnen dorthin gesprungen wird. Das nftables-Handbuch definiert stattdessen Basisketten, die Typ, Hook und Priorität angeben, sowie reguläre Ketten, die das nicht tun. Eine Basiskette darf jeden beliebigen Namen tragen, und eine reguläre Kette namens FORWARD gewinnt aus ihrem Etikett keine Eigenschaften. Das ist der ganze Unterschied, und er bleibt in einer Anleitung unsichtbar, die nur Regeltext zeigt.

Kompatibilitäts-Backends liefern einen zweiten Grund, Verhalten nicht aus einem Befehlsnamen abzuleiten. Die iptables-Dokumentation nennt Vorgänge, die sich unter iptables-nft unterscheiden, also behandeln Sie natives nftables, iptables-nft und ein altes Regelset als drei Systeme statt als drei Schreibweisen eines einzigen.

Lesen Sie den Fehler in seinem echten Kontext

Eine fehlende Tabelle, ein Berechtigungsfehler, eine nicht verfügbare Kernel-Funktion und eine fehlende benannte Kette sind vier verschiedene Befunde, und nur einer betrifft die Kette. Notieren Sie Werkzeugversion, angefragte Adressfamilie und Tabelle, den Netzwerk-Namespace und den ersten exakten Fehler. Prüfen Sie dann, welche Komponente das Regelset besitzt: Ein Firewall-Dienst oder ein produktverwaltetes Gateway kann eigene Ketten und Reihenfolgen erzeugen. Eine native Kette daneben zu legen lässt die verwaltete Richtlinie unberührt und macht das Inventar unübersichtlicher.

Der Namespace eines Containers kann ein anderes Regelset enthalten als der Host, daher kann ein im falschen Kontext ausgeführter Befehl nicht zeigen, welche Kette ein weitergeleitetes Paket gesehen hat. Rechte zu erhöhen, weil eine erwartete Kette nicht sichtbar war, ist keine Diagnose.

Zähler belegen Erreichbarkeit, kein Urteil

Regelzähler sagen Ihnen, dass eine Regel erreicht wurde. Sie sagen nicht, dass eine spätere Regel den Vorgang erlaubt hat, und sie belegen nicht, dass jeder alternative Pfad verworfen wurde. Lesen Sie sie während eines harmlosen autorisierten Flusses, zusammen mit der Regelreihenfolge und dem Anhängen der Kette, und behandeln Sie sie als eine Beobachtung statt als Urteil. Ein Zähler ungleich null an einer Verwerfungsregel bedeutet, dass Verkehr sie getroffen hat; über Verkehr, der sie nicht traf, sagt er nichts.

IP-Weiterleitung im Kernel ist eine völlig eigene Einstellung. Dass eine Kette existiert, aktiviert keine Weiterleitung, und ein fehlendes vertrautes Etikett heißt nicht, dass die Weiterleitung aufgehört hat.

Beschreiben Sie den Fluss, den Sie schützen wollen

Notieren Sie eine Client-Anfrage nach der Entkapselung: ihre Quelle, ihr Ziel, die Adressfamilie und ob sie am Gateway endet oder es durchläuft. Lokale Diensteingaben und weitergeleiteter Verkehr werden an verschiedenen Punkten beobachtet, brauchen also verschiedene Regeln und verschiedene Tests. Prüfen Sie bei einem gebrückten VPN auch den Brückenpfad, denn eine Kette auf IP-Ebene kontrolliert nicht automatisch Ethernet-Frames.

Bewahren Sie unabhängigen Wiederherstellungszugang, bevor Sie ein entferntes Gateway ändern. Bestätigen Sie dann den beabsichtigten Fluss und die nötigen Verwerfungen unter demselben Regelset. Eine neue leere Kette mit vertrautem Namen ist keine Reparatur.

Der Vergleich endet mit einer Frage: Welchen Hook ruft der Kernel für dieses Paket tatsächlich auf? Beantworten Sie das, und der Kettenname spielt keine Rolle mehr.