Warum ein Kill-Switch beim Serverwechsel den Verkehr abwürgt
Warum ein Kill-Switch während eines Serverwechsels den Verkehr blockiert, was der Client in diesem Zeitfenster tut und wie man eine normale Pause von einer hängenden Sperre unterscheidet.
Sie wählen einen Server, der näher aussieht, drücken auf Verbinden, und der Browser lädt nicht mehr weiter, bevor der neue Tunnel steht. Das Symbol springt in einen Verbindungszustand und bleibt dort, während jeder Tab in eine Zeitüberschreitung läuft. Diese Pause ist meist der Kill-Switch, der wie vorgesehen arbeitet: Der Verkehr ist blockiert, solange der Client keinen Tunnel hat, durch den er ihn schicken kann. Ob die Pause akzeptabel ist, hängt davon ab, was der Client in diesen Sekunden tut und ob die Sperre aufgehoben wird, wenn er es behauptet.
Was der Client zwischen zwei Servern tut
Ein Endpunktwechsel besteht aus mehreren Schritten, nicht aus einem Schalter. Der Client reißt den aktuellen Tunnel ab, aktualisiert seine Sperrregeln, löst den neuen Endpunkt auf und erreicht ihn außerhalb des Tunnels, dann installiert er die neuen Routen und hebt die Sperre auf. Die Lücke, die Sie spüren, liegt zwischen dem ersten und dem letzten Schritt.
Die Reihenfolge ist hier wichtiger als die Geschwindigkeit. Wenn die Sperrregeln vor der Ausnahme für den neuen Endpunkt greifen, kann der Client den Handshake nicht abschließen und bleibt im Verbinden-Zustand, bis ein Timeout eintritt. Ist die Ausnahme eine Kopie der Adresse des alten Servers, sieht der neue Handshake wie jedes andere ausgehende Paket aus und wird verworfen. Beide Fälle sehen im Browser gleich aus, weshalb ein Wechsel, der sich nach sechs Sekunden erholt, und einer, der sich nie erholt, dieselbe Ursache haben können.
Der neue Endpunkt braucht ein Loch in der Sperre
Um den Tunnel aufzubauen, muss der Client Pakete an Adresse und Port des neuen Servers über die physische Schnittstelle senden, zum Beispiel UDP 51820 bei einem typischen WireGuard-Profil oder 1194 und 443 bei OpenVPN, was auch immer Ihr eigenes Profil vorgibt. Dieser Verkehr liegt nicht in dem Tunnel, der gerade entsteht, also verschluckt ihn eine Sperre für das ganze Gerät, sofern keine passende Erlaubnisregel existiert.
Profile auf Basis von Hostnamen fügen eine zweite Anforderung hinzu: die Auflösung selbst. Löst der Client den Endpunkt auf, bevor die Sperre hochgeht, kann er eine zwischengespeicherte Adresse nutzen; sobald aber das Profil die Adressen wechselt oder der Cache-Eintrag veraltet, läuft der Handshake auf eine Adresse zu, die die Erlaubnisregel nicht abdeckt. IPv6 macht das sichtbar, denn ein Endpunkt mit dualem Stack kann sowohl einen A- als auch einen AAAA-Record veröffentlichen, und eine Erlaubnisregel, die nur die v4-Adresse abdeckt, lässt den Client gegen eine gesperrte v6-Adresse erneut versuchen.
Optionsnamen und Voreinstellungen unterscheiden sich je nach Client und Version, lesen Sie deshalb die dokumentierte Liste für Ihren, statt aus Screenshots zu raten. Die Einstellungsreferenz von OpenVPN Connect unter openvpn.net/connect-docs/app-settings-windows ist ein Beispiel dafür, wie ein Client seine Sperr- und Split-Tunnel-Optionen beschreibt.
Fail-closed ist eine Zustandsmaschine, kein Schalter
Die meisten Clients drücken die Sperre als Firewall-Richtlinie in drei Zuständen aus: Tunnel oben, Verkehr läuft durch den Tunnel und keine Sperre; Tunnel unten, Sperre aktiv; und Übergang, Sperre aktiv plus vorübergehende Ausnahmen für den Endpunkt. Im dritten Zustand leben die Fehler, denn er muss sich innerhalb weniger Sekunden zweimal ändern, und ihn nicht zu verlassen sieht genau wie eine dauerhafte Sperre aus.
Der Mechanismus unterscheidet sich je nach Plattform, und der Fehler ebenso. Filter der Windows Filtering Platform tragen Gewichte, ein Sperrfilter, der Ihre Erlaubnis überstimmt, verwirft also weiter Pakete, obwohl die Erlaubnis existiert, und Filter, die ein beendeter Clientprozess hinterlassen hat können den Rechner offline halten, nachdem die App weg ist. macOS-Clients schreiben pf-Regeln meist in einen Anchor, wo Regelreihenfolge und schnelle Entscheidungen bestimmen, welche Regel greift. Linux-Clients verwalten üblicherweise eine nftables- oder iptables-Kette mit Drop-Richtlinie und ausdrücklichen Freigaben für Endpunkt, Tunnelschnittstelle und Loopback. Androids Always-on-VPN mit der Option, Verbindungen ohne VPN zu blockieren, ist die strengste Variante der Gruppe, weil das System die Sperre geräteweit und nicht pro App anwendet.
WireGuard braucht eine eigene Anmerkung, denn AllowedIPs ist ein Routenauswahlfeld, kein Blocker. Es entscheidet, welche Ziele in den Tunnel gehen; es tut nichts, um ein Paket ohne Tunnel daran zu hindern, über WLAN hinauszugehen. In einem Aufbau nur mit WireGuard und ohne Firewallregel ist der Kill-Switch in Wahrheit das Fehlen einer Route, und nach einem verworfenen Handshake kann ein echtes Paket über die physische Schnittstelle hinausgehen.
Messen Sie die Lücke, statt auf das Symbol zu starren
Beobachten Sie Pakete, nicht die Statusleuchte. Starten Sie unter Linux in einem Terminal einen langsamen Ping auf eine öffentliche Adresse und fangen Sie im anderen den Transportport des Tunnels auf der physischen Schnittstelle ab:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Wechseln Sie im Client den Server, während beide laufen. Drei Dinge zählen: wie lange die Pings aussetzen, ob die Aufzeichnung zeigt, dass der Handshake den neuen Endpunkt erreicht, und ob der Verkehr vor oder nach dem Wechsel des Client-Zustands auf verbunden wiederkehrt. Endet die Ping-Lücke zuerst, wurde die Sperre entweder zu früh aufgehoben, oder der Tunnel steht, bevor es die Anzeige zugibt. Endet die Lücke später, ist die Anzeige optimistisch.
Unter Windows schreibt netsh wfp show state eine Momentaufnahme, in der Sie nach Sperrfiltern suchen können, die noch vorhanden sind, während der Client behauptet, getrennt zu sein. Unter macOS listet sudo pfctl -sr die geladenen Regeln und ihre Reihenfolge. Kombinieren Sie eine der Momentaufnahmen mit dem eigenen Log des Clients; die Zeitachse aus Ihrem Ping sagt Ihnen, ob die Sperre spät endete oder nie.
Normaler Ausfall gegenüber einer hängenden Sperre
Etwas Unterbrechung ist der Sinn der Funktion, deshalb sollten Sie erst einschätzen, bevor Sie irgendeine Einstellung ändern:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Landen Sie in der zweiten oder fünften Zeile, schalten Sie den Kill-Switch nicht zum Testen ab, denn das macht aus einem Routingfehler ein Leck. Starten Sie den Dienst des Clients neu oder starten Sie die Maschine neu, wo Filter ein Beenden des Prozesses überleben, und sehen Sie dann nach, ob die Sperre verschwindet. Tut sie es, liegt der Fehler in der Aufräumphase des Wechsels und nicht in der Sperre selbst.
Bestätigen Sie vor dem nächsten Wechsel vier Dinge: Die Endpunkt-Erlaubnis deckt jede Adressfamilie ab, die Ihr Profil auflöst, das Client-Log zeigt den abgeschlossenen Übergang, Ihr Ping-Test misst die Lücke statt das Symbol, und das Beenden des Clients stellt die normale Verbindung wieder her. Ein Kill-Switch, der während des Wechsels hält und danach freigibt, tut seine Arbeit. Einer, der früh oder nie freigibt, ist es wert, debuggt zu werden.