So testest du einen VPN-Kill-Switch ohne echte Konten

Du brauchst kein echtes Konto, um herauszufinden, ob ein Kill-Switch hält; genau das setzt ein Test aufs Spiel. Die Prüfung schafft ein kurzes Fenster, in dem Datenverkehr den Tunnel verlassen kann oder nicht, also sollte die Nutzlast etwas sein, das du verlieren kannst. Ich mache das jetzt mit einer Köderseite und einem Ersatz-Browserprofil, und es liefert eine klarere Antwort als die Browser-plus-Webmail-Routine, die ich früher benutzt habe. Das Folgende geht in derselben Reihenfolge vor, die der Client zeigt: die Einstellung, das Ziel, der Übergang, dann die Belege.

Der Test beantwortet eine enge Frage: Kann diese Anwendung während dieses Übergangs das Netzwerk außerhalb des Tunnels erreichen? Er sagt nichts darüber, ob der Rest der Richtlinie sinnvoll ist. Halte den Umfang so klein, und das Ergebnis ist es wert, aufgeschrieben zu werden.

Finde den Schalter und seinen Umfang im Client

Öffne den Client und finde die Sperreinstellung, bevor du irgendeinen Netzwerkzustand änderst. Anbieter nennen sie unterschiedlich: Kill-Switch, Sperrmodus, Netzwerksperre, Verkehr außerhalb des Tunnels blockieren. Das Etikett sagt weniger als die Optionen darin. Entscheidend ist, ob die Sperre immer gilt oder nur, wenn die App entscheidet, dass ein Tunnel gerade ausgefallen ist, und ob sie jede Anwendung oder eine ausgewählte Liste abdeckt.

Liste dann die Übergänge auf, die dein Client tatsächlich ausführen kann. Ein nutzerinitiierter Abbau, das Beenden der App und der Kontaktverlust zum Server sind in den meisten Clients drei verschiedene Codepfade, und sie teilen sich keine gemeinsame Sperrrichtlinie. Manche geben die Sperre frei, wenn die App beendet wird. Andere lassen Filterregeln installiert, bis etwas sie entfernt. Lies die Einstellungsreferenz des Anbieters für den Build, den du verwendest, statt zu vermuten, und notiere dann, welchen der drei du testest.

Notiere auch das Profil: Protokoll, Adressfamilien und ob Split-Tunneling aktiviert ist. Eine Aussage über das ganze Gerät ist sinnlos, wenn das Profil bewusst ein paar Anwendungen ausnimmt, und ein Ausschluss, den du konfiguriert hast, ist kein Leck. OpenVPN Connects Einstellungsreferenz ist die Art Seite, die benennt, welcher Schalter welches Verhalten ändert, auch wenn die Beschriftungen je nach Client abweichen.

Wähle ein Köderziel, das auch ohne den Tunnel funktioniert

Der Köder braucht zwei Eigenschaften, und wenn eine davon fehlt, wird das Ergebnis unlesbar. Er muss direkt erreichbar sein, wenn der Tunnel steht und die Sperre aus ist, sonst kann „er hat aufgehört zu antworten“ einfach heißen, dass der Host weg ist. Und er darf weder Anmeldung noch Cookie noch Zahlung verlangen, damit ein Leck dich eine Logzeile statt einer Sitzung kostet.

Eine statische Seite auf einem Host, den du kontrollierst, ist die saubere Wahl. Eine Ersatz-VM mit einem einfachen HTTP-Server ist fast genauso gut, und eine öffentliche Konnektivitätsprüfseite funktioniert, wenn du akzeptierst, dass ihre Verfügbarkeit außerhalb deiner Kontrolle liegt. Notiere die Adresse, den Port, die Adressfamilie und ob die Anfrage eine Namensauflösung braucht, denn jedes davon wird zu einer Variablen, die du später vielleicht isolieren musst.

Lege die Grundlinie fest, bevor du den Schalter berührst. Bei laufendem Tunnel muss der Köder durch den Tunnel antworten, was beweist, dass die Richtlinienroute funktioniert. Bei stehendem Tunnel und ausgeschalteter Sperre muss er direkt antworten, was beweist, dass das Ziel lebt. Erst dann sagt dir ein Fehler im gesperrten Zustand etwas.

Führe die Übergänge in fester Reihenfolge aus

Nimm die Übergänge einzeln und gönne jedem ein paar Sekunden zum Einschwingen, weil Clients in dieser Lücke oft Regeln abbauen und neu aufbauen. Dieselbe kurze Prüfung jedes Mal auszuführen hält die Beobachtungen vergleichbar:

curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"

Die Zeile zum Beenden der App verdient einen eigenen Lauf, auch wenn du den Client im Normalbetrieb nie schließt. Wird die Sperre beim Beenden freigegeben, liefert dir ein Absturz oder ein erzwungenes Update dieselbe Exposition, und das ist eine Tatsache über das Deployment, nicht über deine Geduld. Unter Windows sind die entsprechenden Prüfungen Resolve-DnsName decoy.example und curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.

Trenne eine Sperre von einem defekten Resolver

Eine Seite, die nicht lädt, hat mehrere Ursachen, und nur eine davon ist der funktionierende Schalter. Löst der Name nicht auf, hast du gelernt, dass DNS blockiert oder defekt ist, nicht dass der Datenpfad blockiert ist. Prüfe auch eine wörtliche Adresse, damit die Antwort gar nicht von der Auflösung abhängt.

curls Exitcodes halten diese Fälle auseinander: 6 ist ein Fehler bei der Namensauflösung, 7 bedeutet, die Verbindung wurde abgelehnt, 28 ist ein Timeout. Eine gesperrte Route zeigt sich meist als Timeout oder Ablehnung gegenüber einer wörtlichen Adresse. Eine reine DNS-Sperre hinterlässt 6 und verbirgt alles andere. Eine zwischengespeicherte Seite oder ein vorgeschaltetes Anmeldeportal täuscht das Auge, deshalb ist der Exitcode und nicht der Bildschirm der Beleg.

Wiederhole die Prüfung über IPv6 mit einer wörtlichen Adresse. Eine Sperre, die IPv4 abdeckt und IPv6 ignoriert, ist häufig genug, um eine eigene Zeile in deinen Notizen zu verdienen, und ein Client, der IPv6 außerhalb des Tunnels deaktiviert, sollte auf beiden Familien sauber scheitern.

Notiere den Umfang, den das Ergebnis abdeckt

Wenn der Tunnel zurück ist, bestätige die Wiederherstellung: Der Köder antwortet durch den Tunnel, der Resolver liefert Antworten, und die Richtlinie steht dort, wo du sie gelassen hast. Dann mache die Experimente rückgängig. Eine temporäre Firewall-Regel, eine Debug-Route oder ein Testprofil, die liegen bleiben, verwirren den nächsten Lauf und können die App überleben.

Ein Durchlauf deckt einen Client-Build, ein Profil, einen Übergang und eine Adressfamilie ab. Schreibe diese vier zusammen mit dem Ergebnis auf:

• Client-Build und Plattform, und ob die Einstellung pro Profil oder global gilt.
• Profil, Protokoll und etwaige Split-Tunnel-Ausschlüsse.
• Getesteter Übergang und wie du ihn ausgelöst hast.
• Adressfamilien und DNS, mit curls Exitcodes für den gesperrten und den ungesperrten Zustand.

Wenn eine Zeile leer bleibt, ist der Test nicht fertig. Roaming bedeutet, die Zeile zum Netzwerkwechsel zu wiederholen. Ein unbeaufsichtigter Neustart bedeutet zu prüfen, ob die Regeln zurückkommen, was eine Frage der Wiederherstellungsreihenfolge ist und nicht des Schalters. Wiederhole die Sequenz nach einem Client-Update, weil sich die Schalter selten ändern, das Verhalten dahinter aber schon. Behalte den Köder: nichts zu rotieren, und die nächste Prüfung dauert fünf Minuten.