Blockiert die UFW-Notbremse dein VPN? Erlaube den Peer

Du bist der Checkliste gefolgt: ausgehend verwerfen, den Tunnel erlauben, ufw aktivieren. Dann wartet der Client am Handshake und verbindet nie, oder er verbindet und keine Seite lädt. Beide Fehler kommen aus derselben Lücke. Die Regel, die den Tunnel existieren lässt, fehlt, weil der Tunnel keine Schnittstelle ist, über die deine Pakete das Gerät verlassen.

Warum eine Allow-Regel auf tun0 anfangs auf nichts passt

tun0 wird vom Client erst angelegt, nachdem eine Sitzung existiert. Die Datagramme, die diese Sitzung aufbauen, sind gewöhnliche UDP-Pakete an den Anbieter auf Port 1194, und sie verlassen das Gerät über wlan0 oder eth0 mit der physischen Quelladresse. allow out on tun0 passt nur auf Verkehr, dessen ausgehende Schnittstelle tun0 ist, also passt es während des Handshakes auf gar nichts.

Setz default deny outgoing darüber, und die äußeren Pakete werden verworfen, bevor die Schnittstelle überhaupt erscheint. Der Client versucht es erneut, läuft in einen Timeout und meldet einen TLS- oder Handshake-Fehler, was Leute durch Zertifikate und MTU jagen lässt, während die Firewall die Verbindung still frisst. Die Regel, die deinen Verkehr eindämmen sollte, verhindert, dass dieser Verkehr eingedämmt wird.

Die Reflex-Korrektur macht das Leck dauerhaft. sudo ufw allow out on wlan0, oder die Voreinstellung zurück auf Erlauben zu stellen, bringt den Tunnel hoch und lässt die Maschine ohne Notbremse: Beim nächsten Ausfall des Tunnels läuft alles wieder über den physischen Adapter. Ich habe genau dieses Paar Änderungen einen Nachmittag gekostet, bevor ich herausfand, welches Paket ich eigentlich filtere.

Was die zwei Paketmengen brauchen

Dein Verkehr kreuzt die Firewall zweimal, in zwei Formen. Das innere Paket läuft von der Tunneladresse über tun0 hinaus. Das äußere Paket läuft von der physischen Adresse zum Peer, und es ist das Einzige, was auf der Leitung sichtbar ist. Eine Regel pro Form:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Ersetze Adresse und Port durch die aus deinem eigenen Profil. WireGuard-Peers antworten meist auf 51820/udp; OpenVPN-Profile, die über TCP 443 laufen, brauchen stattdessen diesen Port. Die Details unterscheiden sich, die Form nicht: Beide Regeln sind eng, und zusammen definieren sie die einzigen Ziele, die die Maschine erreichen kann, während der Tunnel liegt.

Die Reihenfolge ist der zweite Mythos. Bei rohem iptables liest du die Kette von oben nach unten und überlegst, welche Regel gewinnt. ufw ist kein dünner Wrapper um die Liste, die du getippt hast; es kompiliert deine Regeln in eigene Ketten und wählt die Einfügepunkte. ufw status gibt sie in ufw-Reihenfolge aus, nicht in deiner. Wenn eine Regel ignoriert aussieht, vergleiche ufw show added mit dem kompilierten Satz aus iptables -S | grep ufw, bevor du irgendetwas umschreibst.

Die Ausnahme muss eine Adresse breit bleiben

Eine Peer-Regel ist nur korrekt, solange sie die Adresse nennt, die der Client anwählt. Anbieter wechseln Endpunkte, und ein Profil, das einen Hostnamen auflöst, folgt einer DNS-Änderung zu einer neuen Adresse, während die Regel weiter auf die alte zeigt. Wenn ein Tunnel, der monatelang lief, nicht mehr hochkommt, vergleiche die Adresse in der Regel mit der, die der Client anstrebt, bevor du irgendetwas erweiterst.

Eine Erweiterung auf ein ganzes Subnetz oder auf jedes Ziel auf Port 1194 macht die Richtlinie wieder zu einer Firewall mit Loch. Die Ausnahme ist die Notbremse; sobald sie breit ist, bleibt nichts mehr zu bremsen. Halte sie auf einer einzigen Adresse und hinterlasse einen Kommentar, der Profil und Anbieter nennt, denn in sechs Monaten wird die Adresse willkürlich aussehen.

Namensauflösung verdient eine eigene Zeile. Die Abfrage passiert, bevor der Tunnel existiert, über die physische Schnittstelle, also kann eine strenge Ausgehend-verwerfen-Richtlinie den Client unfähig lassen, seinen eigenen Server zu finden. Erlaube Port 53 zur Adresse deines Resolvers, oder löse einmal auf und lege die Adresse im Profil fest. DNS auf jeder Schnittstelle zu erlauben ist eine Entscheidung, keine Voreinstellung.

Bau die Richtlinie, bevor der Tunnel gebraucht wird

ufw enable wendet die ganze Richtlinie auf einmal an und lädt ihre Ketten neu, und das Ändern einer Voreinstellung auf einer laufenden Firewall lädt sie ebenfalls neu. Das ufw-Handbuch warnt, dass dies bestehende Verbindungen wie SSH abbrechen kann. Deshalb gehen die Befehle in dieser Reihenfolge, mit der SSH-Regel vor dem Aktivieren und einer offenen Konsolensitzung:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset bleibt bewusst außerhalb dieses Blocks. Es löscht jede Regel und deaktiviert die Firewall, und auf einem entfernten Host ist das folgende Aktivieren das, was deine Sitzung abbricht. Wenn du trotzdem zurücksetzt, füge die SSH-Regel hinzu und bestätige einen zweiten Weg hinein über eine Konsole, bevor du weitermachst.

Die Reihenfolge ist nicht kosmetisch. Regeln, die hinzugefügt werden, während ufw läuft, spülen nichts, aber in dem Moment, in dem du eine Voreinstellung umdrehst, werden die Ketten neu geladen, und eine Sitzung, die die alte Richtlinie erlaubte, geht mit. Mach die Voreinstellungen, die Erlaubnisse und das Aktivieren in einem Durchgang, solange du noch einen Weg hinein hast, der nicht von der Maschine abhängt.

Teste den blockierten Zustand und behalte das Rückgängigmachen

Eine ungetestete Notbremse ist eine Vermutung. Trenne den Client absichtlich und versuche, eine Seite zu laden: Es muss fehlschlagen. Verbinde dich wieder, und es muss sich erholen, ohne eine Regel anzufassen. sudo ufw status verbose bestätigt die Voreinstellungen und den Protokollierungszustand, und ufw status numbered zeigt, welche Testregel zu löschen ist, wenn sie ihren Zweck überlebt.

Halte das umgekehrte Skript neben dem vorwärts gerichteten. Eine Maschine mit Ausgehend-verwerfen und einem toten Tunnel kann ihre eigene Reparatur nicht herunterladen, also muss das Rückgängigmachen auf der Platte liegen und von einer Konsole lesbar sein:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Führe es aus, wenn der Tunnel schon liegt und die Regeln herunter müssen, nicht als Routineschritt. Bevor du das Terminal schließt, sollten vier Dinge gelten: Die Peer-Regel nennt genau eine Adresse, DNS hat eine benannte Ausnahme, das Aktivieren kam nach den Erlaubnissen, und das Ziehen des Tunnels tötet normalen Verkehr, ohne den Client endgültig zu töten.