Kill-Switch blockiert weiterhin den Datenverkehr, nachdem die VPN-Verbindung getrennt wurde

Der Tunnel ist weg, das Netzwerksymbol sieht normal aus, und nichts lädt. Du hast die VPN-Verbindung getrennt, sie deinstalliert oder neu gestartet, und die Blockade, die dich während eines Abbruchs schützen sollte, steht noch. Das Client-Fenster kann es nicht erklären, denn der Client ist nicht das, was dich blockiert: Die Entscheidung wurde in deinem Namen in den Kernel geschrieben, und nichts blieb zurück, um sie zu entfernen. Unter Windows sitzt dieser Zustand in der Windows Filtering Platform; unter Linux ist es ein Regelsatz in iptables oder nftables, oft mit einem Snapshot, der beim Start erneut eingespielt wird. Was folgt, ist die Reihenfolge, die ich verwende: den Zustand lesen, das engste Objekt löschen, das den Fehler erklärt, und dann alles finden, was es immer wieder zurücksetzt.

Ein Kill-Switch ist Kernel-Zustand, keine Einstellung

Desktop-Clients setzen Blockaden um, indem sie Filter hinzufügen, die Datenverkehr außerhalb des Tunnels verweigern. Unter Windows sind das WFP-Filter auf der Verbindungsumleitungs- und der Transportschicht, und einige davon sind persistent: Sie werden im Richtlinienspeicher der Base Filtering Engine aufgezeichnet und beim Start der Maschine wiederhergestellt, bevor irgendeine VPN-Software läuft. Clients unterscheiden sich darin, wann sie aufräumen. Manche entfernen Filter beim Trennen, manche nur bei einem sauberen Beenden, und manche nur, wenn zuerst der Kill-Switch ausgeschaltet wird. Deinstalliere, während die Blockade aktiv ist, oder beende den Prozess, und die Filter bleiben.

Das Linux-Äquivalent ist eine Drop- oder Reject-Regel im Ausgangspfad, manchmal eine Weiterleitungsregel, manchmal eine geänderte Kettenrichtlinie. Diese Regeln überleben den Prozess, der sie hinzugefügt hat, weil sie Kernel-Zustand sind: Beende den Client, bring ihn zum Absturz oder kappe den Strom, und der Kernel verwirft weiterhin Pakete, ohne dass etwas übrig bleibt, um das rückgängig zu machen. Ein Persistenz-Paket fügt eine zweite Ebene der Dauerhaftigkeit hinzu, indem es den aktuellen Regelsatz als Snapshot sichert und beim Start wiederherstellt, sodass der nächste Start mit der bereits installierten Blockade beginnt.

Lies den WFP-Zustand, bevor du etwas löschst

Windows bringt die Werkzeuge mit, die du brauchst. Starte eine erhöhte Eingabeaufforderung und gib den Zustand der Plattform aus; der Dump landet als wfpstate.xml im Arbeitsverzeichnis.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Suche im XML nach dem Namen des alten Anbieters, nach einer Block-Aktion und nach der Schicht. Filter auf Verbindungsumleitung und Transport sind die, die normalen Verkehr brechen; ein Filter auf einer Receive-Accept-Schicht ist meist nicht deine Ursache. Wenn die Base Filtering Engine gar nicht läuft, suche woanders, denn nichts anderes kann diese Filter durchsetzen.

Prüfe auch die gewöhnliche Firewall-Ansicht, denn die meisten Menschen untersuchen nur eine der beiden:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Wenn die integrierten Profile aktiv sind und keine Regel zum fehlschlagenden Verkehr passt, stammt die Blockade von einem Drittanbieter und nicht von der Windows-Firewall. Diese Unterscheidung entscheidet, welches Werkzeug du für die Reparatur verwendest.

Lies Linux-Regeln in der Syntax, mit der du löschen wirst

iptables -S gibt Regeln in derselben Form aus, in der sie hinzugefügt werden, was die Ausgabe direkt für ein Löschen wiederverwendbar macht. iptables -L -v -n fügt Paketzähler hinzu, und diese Zähler sagen dir, ob eine Regel tatsächlich zu deinen fehlgeschlagenen Anfragen passt oder nur in der Kette steht.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Lies die Kettenrichtlinien, nicht nur die Regeln: -P OUTPUT DROP blockiert Verkehr, selbst wenn keine Regel passt. Untersuche IPv6 getrennt, denn ein Client, der beide Familien installiert, kann die IPv6-Blockade stehen lassen, nachdem die IPv4-Regeln weg sind, und das Symptom hängt dann davon ab, welche Familie eine Anwendung bevorzugt. Wo nftables verwendet wird, führe auch nft list ruleset aus; die beiden Werkzeuge existieren über eine Kompatibilitätsschicht nebeneinander, und eine Auflistung zeigt nicht unbedingt jede Regel, die ein Paket verwerfen kann.

Lösche das engste Objekt, das den Fehler erklärt

Unter Windows ist der erste Schritt weiterhin der eigene Entfernungspfad des Anbieters: Führe das Installationsprogramm erneut aus und nutze Reparatur oder Deinstallation, oder starte das Bereinigungswerkzeug, wenn der Anbieter eines veröffentlicht. Übrig gebliebene Dienste und geplante Aufgaben sind häufig, und eine Aufgabe, die den Client bei der Anmeldung startet, installiert seine Filter beim nächsten Start neu. Eine Deinstallation, die beim Lesen des Registrierungsschlüssels des Clients scheitert, bedeutet meist, dass ein Dienst oder eine Aufgabe ihn noch hält, nicht dass die Registrierung beschädigt ist.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Persistente Filter sind das letzte Mittel. Sie liegen unter HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, ein Wert pro Filter mit GUID als Schlüssel. Exportiere zuerst den Schlüssel, notiere die GUIDs, die du entfernst, lösche nur die Werte, die zum abgegangenen Client gehören, und starte dann neu, damit die Engine ihren Zustand neu aufbaut. Lösche nicht den ganzen Schlüssel und deaktiviere nicht die Base Filtering Engine: Windows-Firewall und Defender hängen davon ab, und du würdest einen Ausfall gegen einen schlimmeren tauschen.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Unter Linux nimmst du die Zeile, die iptables -S ausgibt, und ersetzt -A durch -D. Die eine Regel zu löschen, die du identifiziert hast, ist besser als eine Kette zu leeren, weil es deine eigene Richtlinie intakt lässt.

sudo iptables -D OUTPUT -p udp -j REJECT

Wenn der Drop in einer benutzerdefinierten Kette liegt, lösche zuerst den Sprung in diese Kette und entferne die Kette danach mit -X. Eine Kettenrichtlinie auf ACCEPT zu setzen, während Drop-Regeln noch vorhanden sind, hilft nur Paketen, die überhaupt zur Richtlinienentscheidung gelangen. Jede Tabelle zu leeren ist ein letztes Mittel: Es entfernt auch Regeln, die du aus anderen Gründen hinzugefügt hast, und mit aktivem ufw lässt es den Dienst glauben, er besitze Ketten, die es nicht mehr gibt.

Finde den Verursacher, der es zurücksetzt

Suche nach der sofortigen Reparatur nach allem, was den Zustand wiederherstellen würde. Prüfe unter Linux, ob eine Persistenz-Einheit aktiviert ist, ob der Client eine Einstellung zum Wiederherstellen der Firewall bei der Anmeldung hat und ob unter /etc eine gespeicherte Regeldatei existiert. Prüfe unter Windows erneut Starteinträge, Dienste und geplante Aufgaben, starte dann neu und lies den Zustand mit denselben Befehlen wie zuvor.

Wenn die Blockade zurückkommt, war das Löschen nicht die Lösung; der Verursacher war es. Notiere, welcher Client oder Dienst sie installiert, und deaktiviere die Funktion dort, statt sie nach jedem Trennen auf der Firewall-Ebene zu bekämpfen.

Prüfe mit echtem Verkehr, nicht mit einem einzelnen Ping

Teste eine Namensauflösung, eine TCP-Verbindung und eine frische Browsersitzung, starte dann neu und wiederhole dieselben drei Prüfungen. Ein Ping, der funktioniert, während HTTPS scheitert, deutet auf einen Filter auf der Transportschicht hin und nicht auf das Netzwerk, und eine Blockade, die erst nach dem Neustart wieder auftaucht, deutet auf einen Verursacher hin, den du noch nicht gefunden hast.

Behalte die Beweise: den exportierten BFE-Schlüssel oder die iptables -S-Ausgabe, die vor der Änderung erfasst wurde. Bevor du es als behoben bezeichnest, bestätige die Schicht, aus der du das Objekt entfernt hast, den Verursacher, der es neu installieren könnte, den Zustand nach einem sauberen Neustart und dass normales Surfen ohne laufenden VPN-Prozess funktioniert. Die Handbuchseite iptables(8) enthält die genaue Lösch- und Richtliniensyntax, wenn du die Bereinigung skriptest.