Fail-open oder fail-closed: Was ein VPN-Kill-Switch entscheidet
Beide Begriffe beschreiben, was passiert, wenn der Tunnel fehlt, nicht wie stark die Verschlüsselung ist. Der gewählte Umfang entscheidet, ob wirklich Verkehr austritt.
Der Mythos besagt, fail-closed sei die sichere Einstellung und fail-open die nachlässige. Beide beschreiben, was mit dem Verkehr geschieht, sobald der Tunnel fehlt, und keiner ändert, wie gut dieser Tunnel verschlüsselt. Eine fail-closed-Richtlinie mit langer Ausnahmeliste kann mehr austreten lassen als eine fail-open-Richtlinie auf einem Gerät, das das Büronetz nie verlässt. Wählen Sie das Ergebnis, das Sie der Person erklären können, der der Verkehr gehört.
Das Etikett beschreibt ein Ergebnis, keine Stärke
Das Vokabular stammt aus Steuerungssystemen: fail-open erlaubt den Betrieb, wenn eine Komponente ausfällt, fail-closed verweigert ihn. Auf ein VPN angewandt ist die ausfallende Komponente der Tunnel, und die Frage ist, ob der Verkehr über einen anderen Pfad weiterlaufen darf. Die Wahl der Chiffre, die Schlüssellänge und das Protokoll sind getrennte Entscheidungen.
Die Verwirrung hält sich, weil ein Kill-Switch nach einer Sicherheitsfunktion klingt und Anbieter ihn als solche vermarkten. Mechanisch ist er eine Routing- und Firewall-Regel, die Verkehr blockiert, den der Tunnel tragen sollte, umgesetzt im Client, im Betriebssystem oder auf dem Gateway. Welche Schicht sie durchsetzt, definiert auch ihre Abdeckung, und eine Regel in einer Schicht deckt keine andere ab. Eine Gateway-Regel kann ein Notebook nicht schützen, das bereits in ein anderes Netz gewechselt ist.
Wie jedes Ergebnis aussieht
Dieselbe Richtlinie kann sich je nach Ausfall sehr unterschiedlich verhalten, vergleichen Sie also die Ereignisse statt der Etiketten.
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
Die letzte Zeile erwischt diejenigen, die annehmen, ein Kill-Switch sei ein einzelner Schalter. Eine Regel für die IPv4-Routingtabelle lässt die IPv6-Standardroute unberührt, und die Anwendung kann sie munter nutzen.
Der Umfang entscheidet über das Leck
Fragen Sie, was die Richtlinie abdeckt, bevor Sie fragen, welcher Modus es ist. Eine Regel pro Anwendung schützt eine App und sonst nichts, eine geräteweite Regel schützt alles außer den Ausnahmen, und eine Gateway-Regel schützt nur Verkehr, der dieses Gateway erreicht. DNS braucht eine eigene Entscheidung, denn eine Abfrage an einen lokalen Resolver kann Namen offenlegen, selbst wenn die Nutzlast blockiert ist.
Ausnahmen für das lokale Netz gibt es für Drucker, Casting und Captive Portals, und jede ist ein Loch in der Sperre. Dokumentieren Sie sie neben der Richtlinie, denn wer die Konfiguration erbt, liest fail-closed sonst als absolut.
Neuverbinden und Blockieren sind ebenfalls getrennte Steuerungen. Ein Client kann sich automatisch neu verbinden, ohne je zu blockieren, oder blockieren, ohne sich neu zu verbinden, und die Kombination bestimmt, was ein Nutzer während einer Störung erlebt.
Beweisen Sie es im Übergang
Der Test des Dauerzustands beweist nichts. Trennen Sie den Tunnel absichtlich und probieren Sie die Anwendung aus, die geschützt sein soll, und prüfen Sie dann, ob sie das Netz erreicht hat. Vergleichen Sie die Anzeige des Clients mit dem Ergebnis, denn eine Anzeige, die weiterhin verbunden meldet, ist genau der Fall, für den die Richtlinie existiert. Gelingt es der geschützten Anwendung, ist der Name des Modus egal; Sie haben ein Leck.
Wiederholen Sie das aus einem Kaltstart vor der Anmeldung, beim Wechsel von Wi-Fi zu Mobilfunk und mit der geschützten App im Hintergrund. Wird die Sperre vom Client-Prozess durchgesetzt, testen Sie auch, was passiert, wenn dieser Prozess getötet statt sauber beendet wird.
Prüfen Sie zuletzt den Aufräumpfad. Wird ein Client deinstalliert, während seine Regeln aktiv sind, nutzen Sie das dokumentierte Entfernungsverfahren des Anbieters statt die Firewall des Betriebssystems abzuschalten, die unabhängigen Schutz entfernt, ohne zu beantworten, wem die übrig gebliebene Regel gehört.