Always-on-VPN oder Kill Switch: Welchen haben Sie wirklich aktiviert?

Always-on und Kill Switch stehen in denselben Einstellungen nur zwei Zeilen auseinander, deshalb lesen viele sie als zwei Namen für eine Funktion. Das sind sie nicht. Always-on ist eine Wiederverbindungsrichtlinie: den Tunnel beim Start öffnen, ihn nach einem Absturz oder Netzwerkwechsel zurückbringen und es weiter versuchen, solange er scheitert. Ein Kill Switch ist eine Verkehrsrichtlinie: er benennt die Pakete, die das Gerät noch verlassen dürfen, während der Tunnel unten ist. Man kann das erste ohne das zweite aktivieren, und auf den meisten Plattformen lässt das Standardergebnis in der Lücke weiterhin Verkehr hinaus.

Prüfung 1: ist die Sperre ein eigener Schalter?

Unter Android 10 und später öffnet ein gespeichertes VPN-Profil hinter dem Zahnrad zwei unabhängige Schalter: Always-on-VPN und Verbindungen ohne VPN blockieren. Nur der zweite ist der Kill Switch. Mit Always-on allein kommt der Tunnel nach einem Abbruch zwar zurück, jede Anwendung mitten in einer Anfrage erreicht bis dahin aber das Netz über WLAN oder Mobilfunk.

Verwaltete Geräte behalten dieselbe Trennung in der Policy-API. setAlwaysOnVpnPackage() nimmt den Paketnamen und ein Flag lockdownEnabled; wer das Paket setzt und das Flag falsch lässt, hat einen dauerhaften Tunnel gebaut, kein geschlossenes Gerät. Die Formulierung in der Konsole macht diesen Unterschied selten sichtbar.

Lesen Sie den Zustand am Gerät statt in der Konsole: adb shell settings get global always_on_vpn_app und adb shell settings get global always_on_vpn_lockdown. Gibt der erste null zurück, ist auf Plattformebene kein Paket erzwungen; gibt der zweite 0 zurück, blockiert die Plattform nichts. Der Android-VPN-Leitfaden beschreibt diese als getrennte Fähigkeiten, nicht als einen Modus.

Prüfung 2: welche Schicht besitzt die Sperre?

Bezeichnungen leben im Client, Sperren meist in der Firewall, deshalb bedeutet dasselbe Wort auf jeder Plattform etwas anderes. Die Zeilen unten sollte man bestätigen, bevor man einer davon traut.

Windows ist das klarste Beispiel für eine Bezeichnung, die nicht blockiert. Always On beschreibt dort die Tunnelbeständigkeit: ein Gerätetunnel für die Maschinenauthentifizierung, ein Benutzertunnel für das angemeldete Konto, konfiguriert über Profil-XML oder Add-VpnConnection. Nichts in diesem Profil hält ein ausgehendes Paket auf, wenn der Tunnel fehlt, und die Ausgangsfilterung ist nicht standardmäßig an, also arbeitet ein Laptop im WLAN weiter, während das VPN unten ist.

WireGuard teilt sich genauso, aber nach Client. WireGuard für Windows trägt eine Option pro Tunnel, Untunnelten Verkehr blockieren, die Filterregeln installiert; die Linux-Werkzeuge haben keinen entsprechenden Schalter. wg-quick fügt eine Route für jeden AllowedIPs-Eintrag plus eine fwmark-Regel hinzu, und wg-quick down entfernt beides, sodass die physische Standardroute wieder übernimmt, ohne dass dazwischen ein Paket fällt.

Auf Apple-Plattformen kommt Always-on als Funktion eines Verwaltungsprofils für überwachte Geräte und wird als On-Demand-Regeln ausgedrückt, nicht als Kontrollkästchen. Die Frage aus dem Payload ist, ob ein gescheiterter Tunnel Verkehr verweigert oder nur eine weitere Verbindung anfordert. Der Menütitel sagt es nicht.

Prüfung 3: messen Sie die Lücke, nicht das Symbol

Vier Übergänge zählen, und sie scheitern unterschiedlich: Start, bevor sich jemand anmeldet, Schlaf und Aufwachen, ein Wechsel von WLAN zu Mobilfunk und ein Client-Absturz, der die Tunnelschnittstelle halb konfiguriert zurücklässt. Eine saubere Wiederverbindung bei einem davon beweist nichts für die anderen drei.

Der billigste Test stoppt den Tunnel absichtlich und versucht dann, hinauszukommen. Bei gestopptem Tunnel bedeutet curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com mit Rückgabe 200, dass die Richtlinie fail-open ist; eine Zeitüberschreitung oder eine abgelehnte Verbindung bedeutet, dass noch etwas blockiert. ip route get 1.1.1.1 nennt die Schnittstelle, die das Paket tragen würde, was meist mehr sagt als das Tray-Symbol, und systemctl status wg-quick@wg0 zeigt, ob die Schnittstelle sauber entfernt wurde.

Führen Sie dieselbe Probe in einem zweiten Fenster aus, während das Netz wechselt, nicht erst danach. Das Intervall zwischen Abbruch und Neuversuch ist der entscheidende Teil, und eine Namensauflösung ist der schnellste Weg zu bemerken, dass Verkehr entkommen ist: antwortet der lokale Resolver, während der Tunnel unten ist, ist die Sperre nicht vollständig.

Prüfung 4: entscheiden Sie die Ausnahmen, bevor Sie abschließen

Zwei Ausnahmen sind strukturell. Der Client muss den VPN-Server selbst erreichen, ein Regelsatz, der alles verwirft, verhindert also auch die Wiederverbindung, die den Schutz wiederherstellen würde. Ein Captive Portal ist durch einen Tunnel, der nicht steht, ebenso wenig erreichbar, ein gesperrtes Gerät im Hotel-WLAN braucht also einen dokumentierten Weg, das Portal zu öffnen, statt einen improvisierten.

Eine minimale Form, Endpunkt erlaubt und alles andere verworfen:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Behandeln Sie diese Endpunktzeile als Variable, nicht als Konstante. Anbieter wechseln Adressen, und eine veraltete Ausnahme ist der übliche Grund, warum ein funktionierender Kill Switch zu einem Gerät wird, das sich nicht mehr verbinden kann. Lokale Drucker, NAS-Freigaben und Entwicklungsdienste gehören in dieselbe geschriebene Liste, sonst werden sie ein Support-Ticket nach dem anderen entdeckt.

Prüfung 5: halten Sie fest, was Sie wirklich bewiesen haben

Führen Sie eine Tabelle mit vier Spalten und füllen Sie sie durch Testen: Zustand, erwartetes Verhalten, beobachtetes Verhalten, Beleg. Die Zeilen sind die Übergänge aus Prüfung 3 plus ein absichtlicher Fehler. Eine Zeile, die Sie nicht mit Kommandoausgabe füllen können, ist eine ungeprüfte Zeile, und ein Gerät, das die Wiederverbindungszeile besteht und die Neustartzeile verfehlt, ist häufig genug, um die zusätzlichen zehn Minuten wert zu sein.

Bevor Sie es als erledigt bezeichnen:

• Bestätigen Sie, dass die Blockiereinstellung von der Wiederverbindungseinstellung getrennt ist, und lesen Sie ihren Wert am Gerät.
• Wissen Sie, welche Schicht die Sperre durchsetzt - Client-Option, Geräterichtlinie oder Firewall - und wo diese Schicht konfiguriert wird.
• Behalten Sie ein Probe-Kommando, das die Sperre beweist, und führen Sie es während eines Übergangs aus, nicht danach.
• Schreiben Sie die Ausnahmeliste auf, Endpunkt inklusive, und notieren Sie, wer sie aktualisiert.
• Auf verwalteter Hardware lassen Sie die erzwungene Richtlinie in Ruhe; die Sperre zu entfernen ändert die Anforderung, statt den Tunnel zu reparieren.