VPN-Kill-Switch: Welchen Datenverkehr er blockiert und wann
Eine Wiederverbindung stellt den Tunnel wieder her; ein Kill-Switch entscheidet, was geschieht, solange er fehlt. Testen Sie Verlust, manuelles Trennen, App-Beenden und Netzwerkwechsel getrennt.
Zwei Funktionen werden mit demselben Wort beschrieben und leisten Unterschiedliches. Die automatische Wiederverbindung versucht, den Tunnel zurückzubringen, und das kann innerhalb einer Sekunde gelingen, während Anfragen in dieser Lücke scheitern. Ein Kill-Switch entscheidet, was in dieser Lücke mit dem Verkehr geschieht. Einen Client zu lesen, als wären beide eine Einstellung, führt dazu, dass Menschen einem Symbol statt einer Richtlinie vertrauen.
Blockieren und Wiederverbinden sind getrennte Entscheidungen
Ein Client blockiert nur, wenn der Verlust unerwartet ist, verbindet sich dann neu und hebt die Sperre auf. Ein anderer hält eine Sperre auf Systemebene, bis jemand eine Einstellung von Hand ändert, und ein dritter betrachtet ein absichtliches Trennen als Erlaubnis, den gewöhnlichen Zugang wiederherzustellen. Das sind drei verschiedene Verhaltensweisen, und die Herstellerdokumentation sagt, welche Ihr Build umsetzt.
Der Import eines Profils entscheidet diese Frage nicht. Dasselbe Serverprofil lädt in zwei Clients mit entgegengesetztem Sperrverhalten, weil das Profil Einstellungen trägt und kein Versprechen. Deshalb können ein Kontrollkästchen am Desktop und ein Schalter am Telefon mit ähnlichen Bezeichnungen auch unterschiedliche Regeln umsetzen. Lesen Sie die Beschreibung am Bedienelement Ihrer Plattform und testen Sie dann, was es tut.
Dasselbe Profil verhält sich in zwei Clients unterschiedlich
Die Einstellungen der OpenVPN-Connect-App beschreiben einen Tunnelmodus, der gewöhnlichen Verkehr nur zurückhält, solange der Client einen pausierten oder neu verbindenden Zustand meldet, was enger ist als ein allgemeines Versprechen für jedes Ereignis auf jeder Plattform. Lesen Sie die aufgeführten Zustände statt des Produktnamens. Eine für einen Client-Build geschriebene Beschreibung überträgt sich nicht auf den Client eines anderen Herstellers.
Android zeigt dasselbe Wort für zwei Bedienelemente, weil Always-on-VPN und das Blockieren von Verbindungen ohne VPN getrennt dokumentiert sind. Ein Desktop-Client mit ähnlich benanntem Kontrollkästchen kann etwas Engeres oder Weiteres umsetzen als jedes der beiden. Halten Sie eine gemeinsame Bezeichnung in zwei Menüs für einen Zufall, bis beide Beschreibungen gelesen sind. Verwaltete Geräte fügen eine dritte Ebene hinzu, weil ein Geräteprofil eine Einstellung erzwingen kann, die der Nutzer weder sieht noch aufheben kann.
Ähnlich aussehende Plattform-Einstellungen sind nicht gleichwertig
Vergleichen Sie das sichtbare Bedienelement mit der Richtlinie, die tatsächlich gilt. Auf einem verwalteten Gerät kann der sichtbare Schalter ausgegraut oder aktiviert sein, während ein Profil höherer Ebene das Gegenteil erzwingt. Fragen Sie nach der wirksamen statt der lokalen Richtlinie und lassen Sie sich die Antwort schriftlich geben.
Notieren Sie, was jede Ebene behauptet, bevor Sie etwas testen, denn die beiden widersprechen sich häufig, und der Widerspruch geht leicht verloren, sobald die Tests beginnen. Ein Gerät, das im Test korrekt blockiert, blockiert vielleicht aus einem Grund, den niemand dokumentiert hat.
Führen Sie ein Ereignis nach dem anderen aus und notieren Sie den Code
Testen Sie pro Durchlauf ein Ereignis mit einer harmlosen Anfrage, und machen Sie jeden Versuch zu einer neuen Anfrage statt zu einer Seite, die womöglich schon im Cache liegt. Die Befehle unten nehmen den Tunnel herunter, fragen eine Seite an und zeigen, ob die Schnittstelle zurückkam.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0
Die Tabelle ordnet jede Aktion der Beobachtung zu, auf die es ankommt, und dem Beweis, der aufbewahrt werden sollte. Eine Anfrage, die innerhalb des Zeitlimits scheitert, sagt Ihnen, dass die Sperre gegriffen hat; eine Anfrage, die durchgeht, sagt Ihnen, dass der Verkehr einen anderen Weg gefunden hat, was eine ausgenommene Route und keine deaktivierte Sperre sein kann. Wiederholen Sie den ganzen Satz nach einem bedeutenden Software-Update oder einer Änderung der Routing-Richtlinie, weil beides den Zweig ändern kann, ohne dass sich eine sichtbare Einstellung bewegt. Am Ende wollen Sie vorhersehbares Fehlverhalten, kein beruhigendes Symbol.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Ausnahmen, Gästeportale und was eine Sperre nicht leisten kann
Der Zugang zum lokalen Netz ist die übliche Ausnahme, und sie verändert die Reichweite des Versprechens. Ein Client kann einen Drucker im selben Subnetz erreichen, während alles andere blockiert wird, was zu Hause vernünftig und in einem Gästenetz fragwürdig ist. Entscheiden Sie, ob diese Ausnahme gewünscht ist, bevor ein Vorfall sie für Sie entdeckt.
Eine strenge Sperre macht auch die Anmeldung an einem Gästeportal umständlich, denn das Portal ist genau der direkte Verkehr, den die Sperre stoppen soll. Lernen Sie den unterstützten Weg, das Netz zu autorisieren, und stellen Sie die Richtlinie dann bewusst wieder her, statt Bedienelemente abzuschalten, bis eine Seite lädt. Halten Sie die Antwort des Resolvers und die Routentabelle in derselben Notiz fest, wie unten. Was ein Kill-Switch nicht kann, ist den Dienst anonym zu machen, denn das Blockieren von Verkehr außerhalb des Tunnels sagt nichts darüber, was darin geschieht.
resolvectl query example.com
ss -tunp | grep -v tun0