VPN-App abgestürzt: Ist Ihr Kill-Switch noch aktiv?

Beginnen Sie dort, wo ein Nutzer beginnt: Das Client-Fenster ist weg, das Symbol im Infobereich ist verschwunden, und der Browser lädt entweder oder er lädt nicht. Diese Beobachtung allein sagt Ihnen nicht, ob die Sperre überlebt hat. Die Antwort hängt davon ab, welche Komponente die Regeln hält, ob diese Komponente mit dem Fenster gestorben ist und ob die Plattform die Durchsetzung außerhalb der Anwendung behält. Gehen Sie vom Fenster zum Prozess, dann zur Firewall, dann zum tatsächlichen Pfad.

Starten Sie nicht zuerst neu; ein Neustart zerstört meist die Beweise.

Beginnen Sie bei dem, was noch läuft

Öffnen Sie die Prozessliste, bevor Sie irgendetwas anfassen. Ein Desktop-Client teilt sich meist in einen Oberflächenprozess und einen Dienst oder Daemon, und ein Absturz im ersten stoppt den zweiten nicht zwangsläufig. Unter Windows steht der Dienst vielleicht noch in der Liste, unter Linux ist die Unit vielleicht noch aktiv, und unter Android gehört der Tunnel dem System, sobald die Zustimmung erteilt ist. Lesen Sie diese drei Fakten in dieser Reihenfolge.

Lebt der Daemon, lebt wahrscheinlich auch der Tunnel, und das fehlende Fenster ist nur Kosmetik.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Lesen Sie die Sperre beim Durchsetzer ab, nicht in der App

Wenn der Client seinen Kill-Switch durch das Einfügen von Firewall-Regeln umsetzt, gehören diese Regeln dem Betriebssystem und überleben den Prozess, der sie angelegt hat. Ein Absturz lässt Sie dann gesperrt zurück, ohne Oberfläche zum Abschalten, was eher wie ein kaputtes Netz als wie ein Schutz aussieht. Sitzt die Sperre dagegen im eigenen Paketpfad des Clients, entfernt das Töten des Prozesses die Sperre im selben Moment.

Android handhabt das wieder anders: Always-on-VPN mit Lockdown ist eine Plattform-Einstellung, die Sperre bleibt also unabhängig vom App-Prozess bestehen, und das System kann den Dienst neu starten. Schlagen Sie das genaue Verhalten in der Plattformdokumentation nach, statt anzunehmen, es entspreche einem Desktop-Client.

Sauberes Beenden und Absturz unterscheiden

Ein normales Quit führt meist den Beenden-Pfad des Clients aus, der Regeln entfernt und den Tunnel absichtlich schließt. Ein Absturz überspringt diesen Pfad und lässt stehen, was der Durchsetzer bereits installiert hat. Der Unterschied zeigt sich in den Zeitstempeln der Regeln relativ zum Prozessende und darin, ob noch eine verwaiste Tunnel-Schnittstelle ohne Besitzer existiert.

Diese Unterscheidung bestimmt Ihre Wiederherstellung: Ein sauberes Beenden braucht vielleicht eine neue Verbindung, während ein Absturz verlangen kann, dass die übrig gebliebenen Regeln über die unterstützte Reparaturaktion des Clients entfernt werden.

Wiederherstellen, ohne andere Kontrollen zu brechen

Starten Sie den Client über seinen dokumentierten Ablauf neu und prüfen Sie dann beide Hälften der Anforderung: Der Tunnel trägt Verkehr, und die Sperre greift noch, wenn sie soll. Die ganze Firewall zu leeren, um Konnektivität zurückzugewinnen, entfernt auch unzusammenhängende Kontrollen, und dieser Tausch lohnt sich selten.

Bei einem wiederholten Absturz sammeln Sie Client-Version, Plattform-Build und die begrenzten Protokolle, die der Hersteller verlangt. Ein Client-Profil, ein privater Schlüssel oder ein vollständiges Verbindungsprotokoll für ein anderes Konto ist für einen Absturzbericht nicht nötig, und es beizulegen macht aus einem Supportfall ein Datenverarbeitungsproblem.

Ein Absturz ist kein Beweis für ein Leck. Beweis ist ein beobachtetes Paket, das über einen Pfad abgeht, den die Richtlinie verhindern sollte, erfasst in dem Moment, in dem der Client aus war. Testen Sie das gezielt, mit einem harmlosen Ziel, und notieren Sie, welche Durchsetzungsschicht gehalten hat.