Kill-Switches versagen in eine Richtung, die Leute nicht erwarten: Sie sollen Verkehr blockieren, solange der Tunnel unten ist, und die Pakete, die den Tunnel aufbauen, sind selbst Verkehr. Das ist der ganze Fehler. Ein Regelsatz, der alles verwirft, was nicht durch den Tunnel geht, verwirft auch den Handshake, der ihn aufbauen würde, also wiederholt der Client in einer Schleife, und der Fehler gehört zu der Stufe, die zuerst geprüft wird. Bevor Sie eine Firewall erweitern, finden Sie heraus, welche der drei Stufen abgelehnt wird: die Namensauflösung, das äußere Paket zum Peer oder die Antwort, die zurückkommt.

Wie der Tunnel und sein eigener Transport voneinander abhängen

Lesen Sie einen VPN-Client als zwei Netzwerkzustände, die einen Socket-Pfad teilen. Bevor der Tunnel existiert, öffnet der Client einen Socket auf dem physischen Adapter und sendet verschlüsselte Frames an Adresse und Port des Peers. Erst wenn dieser Austausch gelingt, erzeugt er das Tunnelgerät und installiert Routen. Ein Kill-Switch ist eine Richtlinie über den zweiten Zustand, so weit geschrieben, dass sie für beide gilt.

Schnittstellenbasierte Regeln sind die übliche Form: Akzeptieren Sie, was durch tun0 oder wg0 hinausgeht, verwerfen Sie den Rest des Ausgangspfads. Diese Formulierung kann die eigene Verbindung des Clients zum Server nicht ausnehmen, deshalb fügt eine korrekte Implementierung diese Ausnahme ausdrücklich hinzu, und Sie tun es auch, wenn Sie Regeln von Hand schreiben. Regeln pro Anwendung unter Windows und macOS umgehen einen Teil davon, indem sie einen Prozess statt einer Schnittstelle abgleichen, aber der Prozess muss trotzdem hinaus, bevor der Tunnel existiert.

Drei Stufen, in der Reihenfolge, in der sie auftreten

Die erste Stufe ist die Auflösung. Wenn das Profil einen Hostnamen statt einer wörtlichen Adresse speichert, braucht der Client eine DNS-Antwort, bevor er etwas senden kann. Ein Profil, das DNS auf den Resolver des Tunnels zeigt, erzeugt eine Sackgasse: Der Resolver ist nur über den Tunnel erreichbar, den die Abfrage erst ermöglichen soll. Außerhalb des Tunnels aufzulösen oder den Endpunkt an eine Adresse zu binden, beseitigt die Unklarheit.

Die zweite Stufe ist das äußere Paket, das erst das Routing und dann die Firewall überstehen muss, in dieser Reihenfolge. wireguard-tools übernimmt die Routing-Hälfte davon für WireGuard, indem es seine eigenen Pakete markiert und eine Richtlinienregel hinzufügt, damit sie die eben installierte Standardroute überspringen; die Manpage von wg-quick beschreibt diese Regel und die Tabelle, die sie verwendet. Bauen Sie dieses Routing von Hand nach, oder lassen Sie ein zweites Werkzeug die Regeln umschreiben, und die markierten Pakete können in den Tunnel zurückgeschickt werden, den sie aufbauen sollen.

Die dritte Stufe ist der Rückweg. Ein Handshake ohne Antwort ist kein Beweis für ein ausgehendes Verwerfen; er passt ebenso gut zu einer eingehenden Serverregel oder einem NAT-Gerät, das die Zuordnung vergessen hat. Trennen Sie das, bevor Sie den Client anfassen.

What you seeStageWhere to look
The client log repeats a resolve step and no packets appear on the wire1, name lookupResolver path while the tunnel is down
The send counter on the physical adapter stays flat2, routingPeer route and policy rules
The send counter rises and a firewall drop counter rises2, firewallRule order, mark, and interface match
Packets leave and nothing comes back3, return pathServer input rules, NAT, listening port

Clients protokollieren das Symptom, das sie erkennen, nicht die Stufe, die versagt hat, deshalb ist die Tabelle meist schneller als das Protokoll.

Zähler entscheiden schneller als Protokolle

Unter Linux, nft list ruleset oder iptables -vnL OUTPUT gibt einen Paketzähler pro Regel aus. Verbinden Sie sich einmal, lassen Sie es scheitern und lesen Sie dann die Zähler erneut. Eine Regel, deren Zähler sich bewegt hat, ist eine Regel, die der Handshake getroffen hat; wenn sich nirgends etwas bewegt hat, erreichte das Paket die Firewall nie. Ich habe gesehen, wie ein Regelsatz seinen eigenen Handshake verwarf, und nur die Zähler sagten es.

Um „nie die Firewall erreicht“ von „nie den Host verlassen“ zu unterscheiden, beobachten Sie die Schnittstelle selbst. ip -s link show dev wlan0 meldet gesendete Pakete, und tcpdump -ni wlan0 udp port 51820 zeigt die Frames. Bleibt es flach, während der Client es erneut versucht, liegt der Fehler oberhalb von netfilter: eine fehlende Peer-Route, eine Richtlinienregel, die in ein Gerät zeigt, das es noch nicht gibt, oder ein Socket-Fehler, den der Client schluckt.

Testen Sie Ausnahmen gegen Dokumentationsadressen wie 203.0.113.10, damit ein Versehen nicht den Host eines anderen sondiert.

Eine veraltete Endpunkt-Ausnahme liest sich wie ein Serverausfall

Die irreführendste Variante erscheint, nachdem sich die Peer-Adresse geändert hat: Ein Dienst für dynamische Adressen hat sie verschoben, der Host wurde neu aufgebaut, oder die Ausgangsadresse Ihres Netzwerks ist eine andere. Die Ausnahme nennt noch die alte Adresse, also treffen Pakete an die neue die Verwerfungsregel. Dieselbe Konfiguration funktionierte gestern, und deshalb beginnt man mit der Fehlersuche am Server.

Ein Hostname innerhalb einer Firewallregel rettet Sie nicht. In nftables wird der Name beim Laden des Regelsatzes aufgelöst, also fixiert er die Adresse, die in diesem Moment existierte, und veraltet wie eine wörtliche. Die dauerhafte Lösung ist, die Ausnahme zu aktualisieren, wenn sich der Endpunkt ändert, und sie eng zu halten: eine Peer-Adresse, ein Transportport. Ein Bereich, der breit genug ist, eine Adressänderung zu überleben, ist auch breit genug, um fremden Verkehr hinauszulassen.

Wenn der Kill-Switch auf dem Serverhost läuft

Dieselbe Abhängigkeit gibt es am anderen Ende, und dort ist sie leichter zu übersehen. Wenn die Maschine, die als Ihr VPN-Server dient, auch einen Desktop-Client mit Kill-Switch oder ein von einem Laptop kopiertes Firewallprofil ausführt, gelten dessen Verwerfungsregeln für den Dienst, der die Tunnel beendet. Antworten auf einen Client-Handshake werden verworfen, also kann sich jeder Client nicht verbinden, während der Server gesund aussieht und seine Tunnelschnittstelle ungenutzt bleibt.

Dieser Host braucht drei enge Akzepte vor dem Verwerfen: den Lauschport auf der physischen Schnittstelle, die Tunnelschnittstelle für entschlüsselten Verkehr und die Weiterleitung vom Tunnel dorthin, was die Clients erreichen sollen. Lesen Sie den installierten Satz mit nft list ruleset, iptables -S, oder pfctl -sr , bevor Sie etwas ändern, und denken Sie daran, dass ein gespeicherter Regelsatz einen Neustart überlebt, sodass ein Fehler dort den Prozess überlebt, der ihn gemacht hat.

Wiederherstellungsreihenfolge, die die Maschine geschlossen hält

Arbeiten Sie sich vom Profil nach außen vor. Lesen Sie die Peer-Adresse und den Port, die der Client nutzt, bestätigen Sie, dass der Hostname ohne den Tunnel aufgelöst wird, und fügen Sie dann eine Ausnahme für diese Adresse und diesen Port nur auf dem physischen Adapter hinzu. Verbinden Sie sich erneut und beobachten Sie den Sendezähler; ein abgeschlossener Handshake ist das Signal, dass Stufe zwei repariert ist.

Lassen Sie den Rest der Verwerfungsrichtlinie beim Testen an Ort und Stelle. Eine harmlose Prüfung ist, eine Verbindung zu einer unabhängigen Dokumentationsadresse zu versuchen und zu bestätigen, dass sie weiterhin ausläuft, was zeigt, dass der Kill-Switch arbeitet und nicht abgeschaltet ist. Ziehen Sie die Ausnahme enger, sobald der Tunnel stabil ist, und lassen Sie keine dauerhafte Alles-erlauben-Regel für das Client-Binary liegen, nur weil sie bequem ist.

Wenn der Tunnel hochkommt und die Anwendung weiterhin scheitert, sind die restlichen Stufen nicht diese: geteiltes DNS, MTU und Routing pro Anwendung erzeugen jeweils einen verbundenen Tunnel mit kaputtem Verkehr, und jede hat eine andere erste Prüfung.

Ähnliche Artikel