nftables: die VPN-Freigaberegel vor dem Drop-Handle einfügen

Setzen Sie eine Freigaberegel an die falsche Stelle, verhält sie sich wie keine Freigaberegel. In nftables entscheidet die Wahl zwischen insert und add, auf welcher Seite einer referenzierten Regel die neue Anweisung landet, und ein Handle benennt die Regel im laufenden Ruleset statt ihrer Zeilennummer. Ist die Platzierung falsch, erreicht das Paket zuerst den Drop.

Der folgende Vergleich verwendet einen festen Peer und einen äußeren Listener-Austausch. Er ist bewusst eng; eine ganze Kette zu ersetzen ist eine andere Änderung mit einem anderen Risikoprofil.

Zwei Platzierungen, zwei verschiedene Ergebnisse

insert platziert eine Regel vor der referenzierten Regel. add platziert sie danach. Ist die referenzierte Regel der abschließende Drop für den Flow, erzeugen diese beiden Befehle gegensätzliche Ergebnisse, obwohl der Regeltext identisch ist.

Das Weglassen einer Position hat sein eigenes Standardverhalten, ein weiterer Grund, einen Befehl nicht aus einem Forum zu kopieren, ohne zu lesen, woran er verankert ist. Der Anker ist die ganze Entscheidung. Notieren Sie die beabsichtigte Seite, bevor Sie den Befehl tippen. insert und add unterscheiden sich in der Datei um ein Wort.

Die Platzierung ist relativ zu einer Regel in einer bestimmten Kette. Dieselbe Anweisung in eine andere Kette oder eine andere Hook-Priorität zu verschieben ändert, welche Pakete sie sieht, selbst wenn die Regelsyntax korrekt aussieht.

Ein Handle identifiziert eine Regel, keine Zeilennummer

Ein Handle wie 42 ist ein Bezeichner im aktuellen Zustand des Rulesets. Es ist nicht die zweiundvierzigste Regel und nicht stabil über Hosts, Neuaufbauten oder einen Manager hinweg, der seine Konfiguration neu lädt.

Lokalisieren Sie die Kette und den tatsächlichen abschließenden Drop, bevor Sie den Anker wählen. Bestätigen Sie dann das Handle an dieser Regel in derselben Auflistung, die den Drop zeigt, damit Nummer und Regel zusammen gelesen werden. Ein aus einer alten Auflistung gelesenes Handle kann bereits zu einer anderen Regel gehören. Lesen Sie es in der Sitzung neu, die die Änderung anwendet.

iptables --version
nft -a list ruleset

Die iptables-Version meldet, welches Backend verwendet wird. Ein iptables-nft-Ruleset und eine unabhängig verwaltete native Tabelle können koexistieren, daher ist eine Auflistung aus einem Frontend nicht automatisch das vollständige Filterbild. Prüfen Sie beide Ansichten, bevor Sie eine Kette wählen.

Finden Sie die Kette und die Regel, die tatsächlich droppt

Lesen Sie den Input-Hook, die Kettenpriorität und die Regel, die diesen Listener-Flow ablehnt. Eine inet-Tabelle kann beide Adressfamilien tragen, aber eine einzelne Regel kann weiterhin nur IPv4 treffen.

Nehmen Sie einen freigegebenen Peer, wobei 198.51.100.25 aus dem Dokumentationsbereich als Beispiel dient. Eine geprüfte native Datei könnte eine äußere Freigabe vor Handle 42 setzen:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Ersetzen Sie Familie, Tabelle, Kette, Handle, Eingangsschnittstelle und Peer nach der Prüfung. Das Beispiel verwendet die für nft 1.0.9 dokumentierte Handle-Positionsform, und sie gehört in eine Eingabedatei; das Quoting geschweifter Klammern ist eine eigene Frage, wenn der Befehl interaktiv getippt wird.

Halten Sie den Konfigurationseigentümer klar. Ein Manager, der seine Regeln neu aufbaut, kann eine Laufzeitänderung überschreiben, und ein Boot-Skript, das ein veraltetes Handle hart codiert, schlägt entweder fehl oder hängt sich an die falsche Regel.

Accept ist begrenzt, ein Drop ist endgültig

Ein Accept-Urteil beendet die Auswertung auf seinem aktuellen Pfad, aber eine später anwendbare Basiskette kann das Paket dennoch verwerfen. Ein Drop-Urteil ist endgültig. Deshalb ist ein steigender Accept-Zähler kein Beweis, dass der Flow erfolgreich war.

Untersuchen Sie alle relevanten Hook-Prioritäten statt einer Kette isoliert. Ein Paket kann einen Input-Filter passieren und dennoch von dem Hook einer anderen Tabelle bei einer anderen Priorität abgelehnt werden. Listen Sie jede Basiskette auf, die den Flow sehen kann.

Diese Regel deckt nur den äußeren Listener-Austausch ab. Transportgekapseltes ESP, natives ESP, IPv6-Peers und der entschlüsselte Verkehr im Tunnel brauchen alle eigene Richtlinien. Es ist keine vollständige Site-VPN-Firewall.

Prüfen Sie die Datei und verifizieren Sie dann das laufende Ergebnis

Führen Sie eine Syntax- und Transaktionsprüfung an der geprüften Datei aus, bevor Sie sie anwenden. Der Prüfmodus meldet, ob nft die Änderung parsen und bereitstellen kann; er wendet sie nicht an und beweist nicht, dass ein anderer Hook das Paket zulässt. Die Datei bleibt ein Vorschlag, bis der Eigentümer sie anwendet:

nft -c -f reviewed-vpn-rule.nft

Wenden Sie sie über den kontrollierten Prozess des Eigentümers an und bewahren Sie den Wiederherstellungszugang. Ist die Regel falsch, kann der Drop, dem Sie vorausgehen wollten, auch den Pfad kappen, über den Sie sie korrigieren.

Beobachten Sie nach der Änderung einen neuen erlaubten Peer-Versuch und prüfen Sie, dass Quellen außerhalb des freigegebenen Peers weiterhin abgelehnt werden. Verschieben Sie die dauerhafte Regel in den Manager, dem das Ruleset gehört, denn Laufzeit-Handles lokalisieren aktuelle Objekte, statt sie über Neustarts hinweg zu identifizieren.