Was in dem Moment passiert, in dem der Tunnel abreißt
Die Verbindung fällt offen aus. Ein VPN legt Routen an, die den Verkehr in eine virtuelle Netzwerkschnittstelle lenken. Stirbt der Tunnelprozess oder läuft er in einen Timeout, verschwinden diese Routen — die Standardroute über WLAN oder Ethernet bleibt aber bestehen. Das System stellt also weiter Pakete zu, jetzt direkt über Ihren Provider. Apps verbinden ihre Sockets binnen Sekunden neu und senden von Ihrer echten IP — ohne dass irgendwo ein Fehlerdialog auftaucht.
Abbrüche sind Alltag. Der Wechsel von WLAN zu Mobilfunk, ein Laptop, der aus dem Schlaf erwacht, ein wackliges Hotelnetz oder ein Neustart des VPN-Servers — all das reißt den Tunnel für einen Moment ab. Was dieser Moment kostet, hängt davon ab, ob Ihr Gerät währenddessen überhaupt etwas senden darf.
Was ein Kill Switch tatsächlich tut
Ein Kill Switch ist ein Satz Firewall-Regeln, keine Magie. Die strenge Variante erlaubt nur zwei Arten ausgehenden Verkehrs: Pakete, die in die Tunnelschnittstelle laufen, und die eigenen verschlüsselten Pakete des VPN-Clients zum Server. Fällt der Tunnel, hat Anwendungsverkehr schlicht kein Ziel mehr, bis er zurückkommt.
Das ändert den Fehlermodus, es verhindert keine Fehler. Mit Kill Switch wird ein Abbruch zu einer pausierten Verbindung, die Sie bemerken; ohne ihn zu Verkehr auf Ihrer echten Adresse, den Sie nicht bemerken. Netze sind unvollkommen, der Tunnel wird wieder reißen — fail-closed macht diese Momente harmlos.
System-Kill-Switch oder Schalter in der App
Der Unterschied zeigt sich, wenn die App selbst stirbt. Ein Kill Switch in der App ist Code im VPN-Client, der den Tunnel beobachtet und den Verkehr blockiert, wenn er abreißt. Er wirkt nur, solange der Client läuft: Stürzt der Client ab oder wird er vom Akku-Optimierer abgeschossen, stirbt sein Schutz mit — genau in dem Moment, in dem der Tunnel verschwindet.
Ein Kill Switch auf Systemebene installiert Regeln in der Firewall des Betriebssystems, die jedes ausgehende Paket prüft — egal, welche Apps gerade laufen. Android hat das eingebaut: „Durchgehend aktives VPN“ plus „Verbindungen ohne VPN blockieren“ lässt das OS selbst jeden Verkehr außerhalb des Tunnels verweigern, sogar bevor die App nach einem Neustart startet. Der grobe Test, um beide zu unterscheiden: die VPN-App beim Surfen zwangsweise beenden — laden die Seiten weiter, wohnt der Schalter in der App.
DNS-Lecks: Anfragen, die den Tunnel auslassen
Ein DNS-Leck heißt: Ihre Namensauflösungen gehen an den Resolver, den Ihr lokales Netz zugewiesen hat — meist den Ihres Providers —, obwohl der Verkehr selbst durch den Tunnel läuft. Websites sehen die VPN-Adresse, aber der Resolver empfängt den Namen jeder Seite, die Sie öffnen — praktisch ein Surfprotokoll. Windows ist der klassische Übeltäter: Mit mehreren aktiven Schnittstellen fragt es unter Umständen alle parallel ab und nimmt die schnellste Antwort.
Die Lösung hat zwei Teile, und ein guter Client macht beide: das System auf den Resolver im Tunnel zeigen lassen und DNS auf jeder anderen Schnittstelle blockieren, damit eine verirrte Anfrage kein Ziel mehr hat. Dann prüfen: Leak-Test laufen lassen und die gelisteten Resolver ansehen — gehört einer davon Ihrem Provider, lecken die Auflösungen.
WebRTC-Lecks: Der Browser verrät Adressen
WebRTC ist die Browsertechnik hinter Videoanrufen, und jede Website kann sie mit ein paar Zeilen JavaScript aufrufen. Um Direktverbindungen aufzubauen, sammelt sie jede Adresse, über die Ihre Maschine erreichbar sein könnte: lokale Adressen und — per Anfrage an einen STUN-Server — Ihre öffentliche. Eine Seite kann diese Kandidaten ohne Ihr Zutun auslesen.
Bei einem Tunnel fürs ganze Gerät läuft die STUN-Anfrage durch den Tunnel und findet die Adresse des VPN. Gefährlich sind die Teillösungen: ein reiner Browser-Proxy oder Split-Tunneling, das den Browser draußen lässt — dort gehen WebRTCs UDP-Pakete direkt raus und verraten Ihre echte IP.
Testen statt spekulieren: Unser kostenloser Check unter /webrtc-leak-test/ zeigt, welche Adressen Ihr Browser gerade preisgibt. Taucht die echte auf, wechseln Sie auf einen Tunnel fürs ganze Gerät oder schalten WebRTC in den Browsereinstellungen ab.
IPv6-Lecks: Der Tunnel deckt nur IPv4 ab
Viele VPN-Konfigurationen transportieren nur IPv4. Liefert Ihr Provider auch IPv6 — die meisten Mobilfunknetze tun das —, behält das System eine funktionierende IPv6-Route außerhalb des Tunnels, und moderne Systeme bevorzugen IPv6, wenn eine Seite beides anbietet. Das Ergebnis ist selektive Bloßstellung: Seiten ohne IPv6 sehen die VPN-Adresse, Seiten mit IPv6 Ihre echte — und ein reiner IPv4-Test meldet, alles sei in Ordnung.
Es gibt zwei saubere Lösungen. Die bessere: ein VPN, das IPv6 richtig behandelt — es neben IPv4 tunnelt oder eine Blockier-Route setzt, sodass IPv6-Pakete verworfen statt direkt gesendet werden. Der grobe Fallback: IPv6 am Gerät oder Router abschalten. So oder so — nachprüfen: Der Leak-Test darf keine IPv6-Adresse zeigen, die nicht dem VPN gehört.
So testen Sie Ihr Setup richtig
Fahren Sie die Checks unter den Bedingungen, die Sie wirklich nutzen — Heim-WLAN, Handy im Mobilfunk, Café-Netz —, denn Lecks hängen vom DNS-Setup und der IPv6-Verfügbarkeit des jeweiligen Netzes ab. Die Routine dauert etwa fünf Minuten:
- Echte IP bei ausgeschaltetem VPN notieren, verbinden und bestätigen, dass sich die sichtbare IPv4- und IPv6-Adresse beide geändert haben — unser /data-leak-checker/ zeigt IP, DNS-Resolver und WebRTC in einem Durchgang
- Resolver-Liste prüfen: Jeder angezeigte DNS-Server sollte dem VPN gehören, keiner Ihrem Provider
- Tunnel absichtlich kappen — WLAN umschalten oder App zwangsweise beenden — und beobachten, ob Seiten laden, bevor er sich neu verbindet
- Nach OS- oder VPN-App-Updates wiederholen, denn beide können Netzwerkeinstellungen stillschweigend zurücksetzen