Wohin VPN-NAT in UFWs before.rules gehört und wie man es testet

Eine NAT-Regel, die in einer Shell funktioniert, scheitert beim Einfügen in before.rules, weil diese Datei kein Skript ist. Sie ist ein Dokument im Restore-Format mit Tabellenabschnitten, Ketten-Deklarationen und einem COMMIT-Marker pro Tabelle. Eine Zeile an der falschen Stelle bricht entweder den gesamten Restore ab oder verwirft still Regeln, von denen Sie glaubten, sie seien vorhanden. Das folgende Runbook setzt das Fragment dorthin, wo das Framework es erwartet, und belegt das Ergebnis vor dem nächsten Neuladen.

Ein Shell-Befehl ist keine Restore-Datei

Eine Zeile, die mit iptables -t nat beginnt, ist eine Anweisung an die iptables-Binärdatei, während die Datei, die UFW liest, eine Beschreibung eines vollständigen Regelsatzes ist. Der Unterschied ist nicht kosmetisch: Das Restore-Format muss wissen, in welcher Tabelle es sich befindet, welche Ketten existieren und wo die Tabelle endet. Ein in dieses Dokument eingefügter Befehl ist entweder ein Syntaxfehler oder, schlimmer, eine Regel, die an die falsche Tabelle gehängt wird. Das Framework lädt diese Dateien über Restore-Werkzeuge genau deshalb, weil sie deklarativ und nicht sequenziell sind.

Das Dokument wird zudem als Ganzes geladen, sodass ein fehlerhafter Abschnitt die Anwendung des restlichen Dateiinhalts verhindern kann. Ein kleiner Fehler in einem NAT-Fragment reißt daher die Filterregeln mit, und so wird aus einer Firewall-Änderung ein Ausfall.

Setzen Sie das Fragment in den vorhandenen Tabellenabschnitt

Ein NAT-Fragment hat eine Form, und die Form ist wichtiger als der Regeltext darin. Der Tabellenkopf öffnet den Abschnitt, Ketten-Deklarationen legen die Zähler an, die Regeln folgen, und ein COMMIT schließt den Abschnitt.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Pool und Schnittstelle oben sind Platzhalter für Ihre eigenen; die Struktur ist der Teil, der es wert ist, kopiert zu werden. Wenn die Datei bereits einen *nat-Abschnitt enthält, fügen Sie die Regel in diesem Abschnitt hinzu, statt einen zweiten zu öffnen, denn das Format erwartet ein COMMIT pro Tabelle, und zwei Abschnitte für dieselbe Tabelle sind eine Reparatur, die auf ihr Eintreten wartet. Lassen Sie die Ketten-Definitionen der Distribution unangetastet, einschließlich derer, die der Anbieter für seine eigene Integration hinzugefügt hat. Das UFW-Framework-Handbuch dokumentiert die Dateien before, user und after zusammen mit der Anforderung eines passenden COMMIT.

Wenn die Datei sich als leer erweist, füllen Sie sie nicht aus einem Tutorial. Bestätigen Sie, welches Paket sie besitzt und wie die aktive Richtlinie tatsächlich aussieht, denn eine leere persistente Datei beweist nicht, dass der Kernel keine Regeln hält, und ein geladener Regelsatz beweist nicht, dass das nächste Neuladen eine vollständige Datei zum Lesen hat. Stellen Sie zuerst die unterstützte Basislinie wieder her und wenden Sie dann die Standortänderungen darauf an.

Testen Sie den Kandidaten, ohne ihn anzuwenden

Das Restore-Werkzeug kann einen Regelsatz parsen und aufbauen, ohne ihn anzuwenden, was der billigste verfügbare Test ist. Führen Sie es gegen eine geschützte Kopie statt gegen die Live-Datei aus, und lesen Sie den Fehlertext statt nur den Exit-Status. Ein Parse-Fehler nennt eine Zeile und meist eine Tabelle, was mehr ist, als ein fehlgeschlagenes Neuladen Ihnen sagt.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Das Bestehen dieser Prüfung belegt, dass das Dokument geparst wird, und sonst nichts. Es belegt nicht, dass der Kandidat noch jede Kette enthält, von der UFW abhängt, dass er nur die beabsichtigten Quellen zulässt oder dass die Fernadministration erreichbar bleibt. Das sind getrennte Prüfungen, und die letzte verdient eine zweite Sitzung, die vor dem Start geöffnet wird.

Wählen Sie das Werkzeug, das zum installierten Backend und zur Adressfamilie passt. Ein Host, der das nft-Backend über die Kompatibilitätsschicht betreibt, benötigt den entsprechenden Befehl, und IPv6-Regeln leben in einer ganz anderen Datei.

Halten Sie Weiterleitung, NAT und Zugriffsrichtlinie getrennt

Quellübersetzung behebt ein Adressierungsproblem und gewährt nichts. Weiterleitung ist eine separate Berechtigung, die von einem sysctl und von der Filtertabelle gesteuert wird, und sie ist diejenige, die man vergisst, wenn ein Tunnel routet, aber keinen Verkehr durchlässt. Zugriffsrichtlinie ist eine dritte Entscheidung darüber, welche Quellen welche Dienste erreichen dürfen, und keine NAT-Regel drückt sie aus. Gerade die Trennung der drei macht einen Fehler diagnostizierbar statt zu einem einzigen vagen Symptom.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Lesen Sie diese drei Ausgaben zusammen statt nacheinander. Eine Masquerade-Regel mit deaktivierter Weiterleitung erzeugt einen Client, der sich verbindet und nichts erreicht, was aus Client-Sicht genau wie ein Routingfehler aussieht und Leute zur falschen Datei schickt. Die Filtertabelle ist auch der Ort, an dem sich ein zu breites Accept versteckt, also prüfen Sie dort auch ihre Standardrichtlinie.

Prüfen Sie ein Neuladen, eine Ablehnung und einen VPN-Verlust

Drei Beobachtungen ergeben einen vollständigen Abnahmetest: Das Neuladen gelingt, eine erlaubte Client-Operation funktioniert, und eine Anfrage, die abgelehnt werden sollte, wird tatsächlich abgelehnt. Die dritte wird übersprungen, und sie ist der einzige Beleg dafür, dass die Richtlinie überhaupt etwas tut.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Testen Sie dann den Fehler, für den Sie entworfen haben. Lassen Sie den Tunnel fallen und beobachten Sie, was der Host tut, denn eine Richtlinie, die nur funktioniert, solange das VPN läuft, ist eine Richtlinie mit einer unausgesprochenen Abhängigkeit. Laden Sie danach noch einmal neu, um zu belegen, dass die Datei und nicht ein übrig gebliebener Laufzeitzustand das funktionierende Ergebnis erzeugt.

IPv4-NAT sagt nichts über IPv6 aus, also geben Sie die beabsichtigte Abdeckung für beide Familien in derselben Notiz wie die Regel an. Ziel ist eine kohärente verwaltete Richtlinie, und ein Fragment, das zufällig geparst wurde, ist kein Beleg dafür.