Überlebt ein Kill-Switch von VPN einen Neustart? So prüfen Sie es

Ein Neustart ist die verbreitetste Art, einen Kill-Switch zu testen, und er ist der Test, der am häufigsten lügt. Das Kontrollkästchen im Client ist eine Voreinstellung; entscheidend ist, ob etwas eine Sperre zwischen dem Moment erzwingt, in dem der Netzwerk-Stack hochkommt, und dem Moment, in dem der Tunnel tatsächlich aufgebaut ist. Unter Windows ist dieses Etwas meist ein Filter in der Windows Filtering Platform, unter Linux ein von einer Unit geladenes Regelset, unter macOS ein pf-Anker, unter Android die eigenen Flags des Systems für Always-on und Lockdown. Diese Anordnungen verhalten sich über einen Neustart hinweg sehr unterschiedlich, und nur die auf Plattformebene sind vorhanden, bevor sich irgendjemand anmelden kann.

Ein Neustart stellt drei getrennte Fragen

Teilen Sie die Frage. Erstens: Existiert die Richtlinie auf der Platte in einer Form, die beim Booten etwas liest? Zweitens: Läuft dieser Leser, bevor irgendein Verkehr das Gerät verlassen kann? Drittens: Deckt die Richtlinie den Verkehr ab, der Sie interessiert, also jeden Prozess, beide Adressfamilien und DNS. Ein Ja auf die erste und ein Nein auf die zweite erzeugen genau den Fehler, den Leute als Kill-Switch melden, der einen Neustart nicht übersteht: Der Verkehr entweicht beim Start für ein paar Sekunden, und niemand merkt es, bis jemand nachsieht.

Halten Sie die Ebenen auseinander. Ein gespeichertes Firewall-Regelset, ein Dienst, der beim Booten startet, und eine Client-Voreinstellung sind drei verschiedene Objekte mit drei verschiedenen Lebensdauern. Die Voreinstellung übersteht Neustarts, weil sie ein Wert in einer Konfigurationsdatei ist. Die Regeln sind das Einzige, was Pakete blockiert, und sie verschwinden mit dem Kernel, der sie hielt.

Finden Sie das Objekt, das die Sperre wiederherstellt

Unter Linux leben netfilter-Regeln im Kernel. Nichts schreibt sie beim Booten zurück, sofern Sie es nicht eingerichtet haben: iptables-save plus netfilter-persistent, nftables.service lädt /etc/nftables.conf, oder eine systemd-Unit, die Ihr eigenes Skript ausführt. Prüfen Sie, was aktiviert ist, statt was Sie glauben konfiguriert zu haben.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Ein leeres Regelset wenige Sekunden nach dem Booten ist die Antwort auf die Frage im Titel. Fragen Sie unter Windows den Client-Dienst, wie er startet, und geben Sie dann den Filterzustand der Plattform aus, während der Tunnel unten ist.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Der zweite Befehl schreibt wfpstate.xml in das aktuelle Verzeichnis. Suchen Sie Filter mit einer Blockieraktion, die bereits existieren, bevor der Client sich verbindet. Die Base Filtering Engine startet früh beim Booten und stellt Filter wieder her, die mit dem persistenten Flag hinzugefügt wurden; deshalb blockieren manche Kill-Switches Verkehr, bevor irgendein Client-Fenster existiert, und andere nicht. Unter macOS sudo pfctl -s info meldet, ob pf aktiviert ist, sudo pfctl -s rules zeigt, was geladen ist, und VPN-Clients hängen ihre Regeln meist an einen Anker statt an das Hauptregelset. Eine Regel, die utun3 nennt, kann nach dem nächsten Booten auf eine andere Schnittstelle zeigen, weil diese Nummer zur Laufzeit vergeben wird.

Beobachten Sie die Lücke zwischen Netzwerk-up und Tunnel-up

Das gefährliche Intervall ist nicht der ganze Neustart, sondern die Lücke. Die Schnittstelle erhält zu einem Zeitpunkt ein Lease und eine Standardroute, der VPN-Dienst startet zu einem anderen, und der Tunnel authentifiziert sich noch später, manchmal erst, nachdem sich ein Benutzer angemeldet und ein Anmeldeinformations-Agent gelaufen ist. Wird die Sperre zuletzt angewendet, verlässt alles in der Lücke das Gerät im Klartext.

Lesen Sie auf systemd-Hosts die Reihenfolge, statt sie zu raten. Führen Sie systemctl cat auf den VPN- und Firewall-Units aus und achten Sie auf After= oder Before= gegenüber network-pre.target und network-online.target. Eine Firewall-Unit, die nach network-online.target geordnet ist, verliert gegen die Schnittstelle; eine, die von network-pre.target gefordert und davor geordnet ist, gewinnt. Unter Windows sind die entsprechenden Fragen der Starttyp des Dienstes und seine Abhängigkeiten, denn ein auf Manual gesetzter Dienst kann keinen Boot-Prozess blockieren. Schließt Ihre Anforderung Verkehr vor der Anmeldung ein, erfüllt das nur eine Anordnung auf Geräteebene: Ein Always On VPN-Gerätetunnel authentifiziert sich mit einem Maschinenzertifikat und verbindet, bevor sich der Benutzer anmeldet, und Microsoft dokumentiert die Konfiguration des Gerätetunnels getrennt vom Benutzertunnel. Android geht den anderen Weg und erzwingt Always-on-VPN und blockiert Verbindungen ohne sie vom System statt von einem App-Prozess.

Testen Sie, und vergleichen Sie dann zwei Zeitlinien

Starten Sie neu mit einem Ziel, das nichts kostet, wenn es leckt, und erfassen Sie den Zustand während der Lücke statt danach. Die sauberste Methode ist eine Boot-Sonde: eine oneshot-Unit oder eine geplante Aufgabe, die so früh startet, wie die Plattform es erlaubt, die Standardroute und den Firewall-Zustand aufzeichnet, eine Anfrage mit kurzem Timeout versucht und eine Zeile an eine lokale Datei anhängt. Vergleichen Sie diesen Datensatz mit der Startzeit des VPN-Dienstes aus journalctl -b -u oder dem Systemprotokoll.

Führen Sie dann den üblichen Test aus: Tunnel oben, Verbindung trennen, beobachten, ob direkter Verkehr blockiert wird, wiederherstellen. Den zweiten zu bestehen und den ersten zu verfehlen ist das normale Ergebnis, und es bedeutet, dass die Durchsetzung clientseitig ist und beim Verbinden des Clients greift, nicht beim Booten. Auf dem letzten Rechner, den ich geprüft habe, kam die Sperre von einem Dispatcher-Skript von NetworkManager: vorhanden und korrekt und nutzlos für die Sekunden, bevor die Schnittstelle hochkam. Schreiben Sie beide Ergebnisse auf, denn einen Neustart zu überstehen bedeutet erst etwas, wenn Sie sagen, welche Ebene überlebt hat und ab welchem Moment.

Schließen Sie die Lücke, ohne sich den Rückweg abzuschneiden

Fehlt die Sperre beim Booten, verlagern Sie die Durchsetzung eine Ebene nach unten, statt eine zweite Client-Regel hinzuzufügen. Speichern Sie das Regelset und laden Sie es aus einer Unit, die geordnet ist, bevor das Netz nutzbar ist, und stellen Sie sicher, dass diese Unit keine DNS-Abfrage und kein Netzwerk-Mount braucht, das sie schützen soll. Der Umfang zählt so viel wie das Timing: Regeln, die auf eine Benutzer-ID oder eine cgroup passen, lassen jeden Systemdienst außerhalb der Sperre, und ein Regelset, das nur IPv4 behandelt, lässt IPv6 und DNS erreichbar.

Lassen Sie sich einen Rückweg. Ein Rechner, der beim Booten alles blockiert und sich dann nicht authentifizieren kann, hat überhaupt kein Netz, und die Lösung ist nicht, die Sperre zu löschen, sondern die Anmeldeinformation oder die Reihenfolge zu reparieren. Halten Sie ein dokumentiertes Verfahren für die lokale Konsole bereit und eine enge, bewusste Ausnahme für das, was der Tunnel wirklich braucht, etwa die Serveradresse und den Resolver, der vor dem Tunnel genutzt wird.

Bevor Sie der Einrichtung trauen, bestätigen Sie vier Dinge der Reihe nach. Die Richtlinie ist dort gespeichert, wo das Booten liest. Dieser Leser läuft, bevor die Schnittstelle nutzbar ist. Die Sperre deckt beide Adressfamilien und DNS ab. Das VPN kann sich noch authentifizieren, während die Sperre aktiv ist. Wenn alle vier gelten, ändert ein Neustart nichts.