Ein VPN-Kill-Switch ist kein Knopf zum Abschalten des VPN, sondern eine Sperre für ungeschützten Verkehr. Das Betriebssystem soll Pakete nur senden, wenn der VPN-Tunnel verfügbar ist oder wenn sie ausdrücklich zu einer erlaubten Ausnahme gehören. Fällt der Tunnel aus, bleibt die normale Internetverbindung blockiert, bis das VPN wieder steht oder Sie die Schutzfunktion bewusst ausschalten.

Ohne diese Sperre arbeitet das Routing genau wie vorgesehen: Verschwindet die virtuelle VPN-Schnittstelle, nutzt das System wieder die normale Standardroute über WLAN, Mobilfunk oder Ethernet. Offene Apps bemerken den Wechsel oft kaum. Eine Website sieht dann bei der nächsten Anfrage Ihre Anschluss-IP, ein Download läuft außerhalb des Tunnels weiter, und DNS kann wieder beim Internetanbieter landen. Die Lücke kann nur Sekunden dauern und trotzdem eine Zuordnung ermöglichen.

Wann ein VPN-Tunnel unbemerkt abbricht

Ein Abbruch ist nicht nur ein vollständiger Internetausfall. Typische Übergänge sind:

  • Sie wechseln vom Heim-WLAN in ein Mobilfunknetz.
  • Das Notebook wacht aus dem Standby auf und stellt Routen in anderer Reihenfolge wieder her.
  • Sie wechseln in der VPN-App den Server oder das Protokoll.
  • Der VPN-Prozess stürzt ab oder wird während eines Updates beendet.
  • Ein Router vergibt eine neue Adresse oder verliert kurz die Verbindung.
  • Das Betriebssystem bevorzugt plötzlich eine verfügbare IPv6-Route, obwohl nur IPv4 getunnelt wird.

Gerade Programme mit dauerhaften Verbindungen reagieren unterschiedlich. Manche stoppen, andere verbinden sich sofort über die neue Route erneut. Ein VPN muss deshalb nicht nur im stabilen Zustand dicht sein, sondern auch in diesen Übergängen.

Wie ein Kill-Switch technisch funktioniert

Die robuste Variante setzt Regeln in der Paketfilterung des Betriebssystems. Sie erlaubt ausgehenden Verkehr über die VPN-Schnittstelle und gerade genug direkten Verkehr, damit der Client seinen VPN-Server erreichen kann. Alles andere wird verworfen. Unter Windows können Anbieter dafür die Windows Filtering Platform verwenden. Microsoft beschreibt sie als mehrschichtige Filterinfrastruktur für IPv4 und IPv6, die Verkehr pro App, Nutzer, Verbindung, Schnittstelle oder Port erlauben und blockieren kann.

Unter Linux übernehmen üblicherweise nftables oder eine vergleichbare Netfilter-Regelung diese Aufgabe. Auf Apple-Systemen stellt das Network-Extension-Framework kontrollierte VPN-Routen bereit. Die Option includeAllNetworks leitet fast den gesamten Verkehr in den Tunnel, wobei Apple notwendige Systemdienste wie DHCP und die Anmeldung an WLAN-Portalen ausnimmt. Diese Ausnahmen zeigen, warum „blockiert alles“ technisch selten wörtlich stimmt.

Eine schwächere Umsetzung ändert nur die Routing-Tabelle oder beendet ausgewählte Apps. Das kann für einen einzelnen Download genügen, schützt aber nicht zwangsläufig neue Verbindungen, DNS, IPv6 oder andere Prozesse. Löscht ein abgestürzter Client seine Route, bevor eine Firewall-Regel greift, ist der Verkehr wieder offen.

Systemweiter und App-basierter Kill-Switch

Ein systemweiter Kill-Switch blockiert grundsätzlich jeden nicht getunnelten Internetzugriff. Das ist die passende Voreinstellung, wenn die Anschluss-IP nicht erscheinen soll. Lokale Geräte wie Drucker oder ein NAS können dabei ebenfalls unerreichbar werden, sofern die App keine bewusst konfigurierte LAN-Ausnahme anbietet.

Ein App-Kill-Switch beendet oder sperrt nur ausgewählte Programme. Er kann praktisch sein, wenn etwa ein Dateiübertragungsprogramm niemals ohne VPN arbeiten soll, während andere Apps die normale Verbindung nutzen dürfen. Der Schutz ist jedoch enger als der Name vermuten lässt. Hilfsprozesse, Browser-Unterprozesse oder DNS-Anfragen können außerhalb der ausgewählten Anwendung liegen.

Android bietet zusätzlich eine systemeigene Kombination aus Always-on VPN und „Verbindungen ohne VPN blockieren“. Laut Android-Dokumentation kann das System das VPN nach dem Start des Geräts aktiv halten und nicht getunnelten Verkehr sperren. Diese Betriebssystemfunktion ist aussagekräftiger als ein Schalter, den eine App nur innerhalb ihres eigenen Prozesses verwaltet.

Kill-Switch, Always-on und permanente Sperre

Anbieter verwenden verschiedene Namen für ähnliche, aber nicht identische Modi:

  • Automatischer Kill-Switch: Die Sperre greift, nachdem Sie eine VPN-Verbindung gestartet haben und diese unerwartet ausfällt.
  • Always-on VPN: Das Betriebssystem versucht, den VPN-Dienst beim Start und nach Unterbrechungen automatisch zu aktivieren.
  • Permanenter Kill-Switch oder Lockdown: Direkter Internetverkehr bleibt auch dann blockiert, wenn Sie die VPN-App schließen oder das Gerät neu starten.

Für sensible Nutzung ist der permanente Modus klarer, kann aber bei einer fehlerhaften App das gesamte Gerät offline halten. Android warnt in seiner Entwicklerdokumentation ausdrücklich vor diesem Ausfallrisiko. Prüfen Sie vor einer Reise, wie sich die Sperre deaktivieren lässt, falls der Anbieter in einem Hotelnetz nicht erreichbar ist.

Was ein Kill-Switch abdecken muss

Ein guter Schutz betrachtet mehr als die sichtbare IPv4-Adresse. IPv6 braucht dieselbe Filterlogik. Bleibt ::/0 über die physische Schnittstelle erreichbar, kann eine Anwendung am IPv4-Tunnel vorbeikommunizieren. Unser IPv6-Leak-Test macht diese Route sichtbar.

Auch DNS muss geschlossen bleiben. Manche Clients erlauben DNS direkt zum Provider, um nach einem Abbruch den Hostnamen des VPN-Servers neu aufzulösen. Die VPNalyzer-Studie dokumentierte solche Lecks bei erzwungenen Unterbrechungen. Ein dichtes System verwendet eine eng begrenzte Ausnahme oder hält die benötigte Serveradresse bereits vor. DNS-Schutz und Kill-Switch prüfen wir deshalb getrennt mit unserem DNS-Leak-Test.

Bei Split-Tunneling sind direkte Verbindungen absichtlich erlaubt. Dann muss die App genau unterscheiden, welche Programme oder Ziele in den Tunnel gehören. Ein Test der sichtbaren IP im Browser sagt nichts über eine andere eingeschlossene App aus. Umgekehrt ist eine direkte IP bei einer bewusst ausgeschlossenen App kein Fehler.

Wie wir den Kill-Switch prüfen

Ein vorhandener Menüpunkt erhält bei uns noch keinen Haken. Wir aktivieren den systemweiten Modus, verbinden uns mit einem eindeutig bestimmten Server und kontrollieren zuerst die VPN-Ausgangs-IP. Danach erzeugen wir einen echten Übergang:

  1. Während eine Verbindung aktiv Daten überträgt, lassen wir WLAN oder Ethernet bestehen und unterbrechen gezielt nur den VPN-Tunnel oder dessen Weg zum VPN-Server.
  2. Wir versuchen parallel, unseren IP-Check und eine neue Website zu erreichen.
  3. Im sicheren Fall fließt außerhalb des Tunnels kein Verkehr. Eine kurz sichtbare Anschluss-IP gilt als Fehler, auch wenn die App sofort wieder verbindet.
  4. Nach Wiederherstellung prüfen wir, ob der Tunnel automatisch zurückkehrt und erst dann Internetzugriff freigibt.
  5. Wir wiederholen die Kontrolle für Serverwechsel, Standby und, soweit das System es erlaubt, IPv4 und IPv6.

Ein vollständiger Test braucht laufende Anfragen während des Abbruchs und darf nicht nur auf die Anzeige der App vertrauen. Die Meldung „Verbindung wird wiederhergestellt“ beweist nicht, dass im Hintergrund keine Pakete die physische Schnittstelle verlassen.

Wir dokumentieren Ergebnisse als bestanden, nicht bestanden oder nicht verfügbar. Gibt es eine Funktion nur auf Windows, erhält die iOS-App dadurch keinen stillschweigenden Erfolg. Plattformen werden getrennt betrachtet, weil ihre Netzwerk-APIs und Einschränkungen verschieden sind.

So testen Sie den Schutz selbst

Öffnen Sie vor dem Test den IP-Check und merken Sie sich VPN-IP sowie Anschluss-IP. Aktivieren Sie den Kill-Switch. Trennen Sie dann nicht einfach das gesamte WLAN, denn ohne Netz kann ohnehin kein Paket entweichen. Aussagekräftiger ist ein Serverwechsel, das Beenden des VPN-Prozesses oder eine kurze Störung, bei der die physische Verbindung bestehen bleibt. Versuchen Sie währenddessen, eine neue Seite zu laden.

Wenn die Seite Ihre Anschluss-IP zeigt, hat die Sperre versagt. Wenn gar kein Internet verfügbar ist und der Zugriff erst nach erneuter VPN-Verbindung zurückkehrt, arbeitet sie grundsätzlich wie erwartet. Wiederholen Sie den Test nach größeren App- oder Betriebssystem-Updates. Filterregeln können durch Änderungen an Netzwerkdiensten beeinflusst werden.

Führen Sie solche Versuche nicht während einer sensiblen Sitzung durch. Ein absichtlich provozierter Fehler kann genau die Information freigeben, die Sie schützen möchten.

Worauf Sie bei einem Anbieter achten sollten

  • Die Funktion sollte systemweit und für IPv4 sowie IPv6 arbeiten.
  • Der Anbieter sollte klar erklären, ob der Schutz nur bei einer vorher aktiven Sitzung oder dauerhaft ab Gerätestart gilt.
  • LAN- und Split-Tunneling-Ausnahmen müssen sichtbar und bewusst wählbar sein.
  • Nach einem Absturz des Clients sollten die Filterregeln nicht einfach verschwinden.
  • Ein automatischer Wiederaufbau darf Verkehr erst nach fertigem Tunnel freigeben.
  • Die Funktion sollte für jede unterstützte Plattform einzeln dokumentiert sein.

Häufige Irrtümer und Grenzen

„Kill-Switch aktiviert bedeutet automatisch geschützt.“ Nein. Die Implementierung kann IPv6, DNS oder bestimmte Übergänge übersehen. Ein realer Abbruchtest ist nötig.

„Ohne Internet kann nichts lecken.“ Richtig, aber das prüft den Kill-Switch nicht. Relevant ist der Moment, in dem die normale Netzverbindung funktioniert und nur der VPN-Tunnel fehlt.

„Der Notausschalter verhindert Datenlecks in Apps.“ Er verhindert ungetunnelten Netzwerkverkehr. Er schützt nicht vor Cookies, Telemetrie innerhalb des Tunnels, kompromittierter Software oder einer ungeeigneten No-Logs-Richtlinie.

Quellen