VPN-Leaks erklärt: DNS-, WebRTC- und IPv6-Lecks (und wie man wirklich auf sie testet)

Ihre VPN-App zeigt Verbunden an. Dieses eine Wort fühlt sich wie eine Garantie an, doch es bedeutet nur, dass Ihr Gerät einen verschlüsselten Tunnel zum VPN-Server aufgebaut hat. Es sagt nichts darüber aus, ob jeder identifizierende Datenverkehr tatsächlich durch diesen Tunnel läuft. Drei häufige Fehlerquellen – DNS-Lecks, WebRTC-Lecks und IPv6-Lecks – können jeweils Ihre echte IP-Adresse oder Ihre Surf-Aktivitäten preisgeben, während die App weiterhin ein beruhigendes grünes Häkchen zeigt.

Dieser Leitfaden leistet drei Dinge, die Seiten nach dem Muster „nur ein Leck, kauf dieses VPN“ nie tun. Erstens erklärt er den tatsächlichen Mechanismus hinter jedem Leck, damit Sie verstehen, warum ein verbundenes VPN Sie trotzdem verraten kann. Zweitens führt er Sie durch einen Selbsttest mit kostenlosen, unabhängigen Tools, denen Sie keinem Anbieter blind vertrauen müssen. Drittens liefert er Ihnen die exakten Lösungen pro Betriebssystem, Browser und Router – und die Re-Test-Disziplin, die bestätigt, dass die Lösung gehalten hat. Kein Markengeschwätz, keine Affiliate-Links, nur die Technik dahinter.

Was ein VPN-Leck wirklich ist

Ein Leck ist jeglicher Datenverkehr, der durch den verschlüsselten Tunnel laufen sollte, stattdessen aber über Ihre normale Internetverbindung nach außen gelangt und Informationen offenlegt, die das VPN eigentlich verbergen sollte. Die drei in diesem Leitfaden behandelten Lecks geben zwei verschiedene Dinge preis. Ein DNS-Leck verrät die von Ihnen aufgerufenen Websites an Ihren Internetanbieter (oder an wen auch immer den Resolver betreibt, den Sie versehentlich nutzen). Ein WebRTC-Leck und ein IPv6-Leck können Ihre echte IP-Adresse – also Ihren tatsächlichen Standort und Ihre Identität im Netz – direkt an die von Ihnen besuchten Websites verraten.

Das Wichtigste vorweg: Dies sind separate Probleme mit separaten Ursachen und separaten Lösungen. Konkurrenten verschweigen das, weil es einer Ein-Klick-Verkaufsstory im Weg steht, doch genau darum geht es. Sie können ein DNS-Leck stopfen und trotzdem Ihre IP über WebRTC verlieren. Sie können WebRTC in Ihrem Browser absichern und trotzdem über IPv6 lecken. Das Schließen eines Lecks sagt nichts über die beiden anderen aus. Deshalb prüft ein echter Leak-Test jedes Mal alle drei.

Wie jedes Leck entsteht (der Mechanismus)

DNS-Lecks: Anfragen, die aus dem Tunnel entkommen

Bevor Ihr Gerät example.com lädt, bittet es einen DNS-Resolver, diesen Namen in eine IP-Adresse zu übersetzen. Ist das VPN korrekt konfiguriert, läuft diese DNS-Anfrage innerhalb des Tunnels zu einem Resolver, den das VPN kontrolliert. Ein DNS-Leck entsteht, wenn die Anfrage stattdessen über die offene Verbindung an den Resolver Ihres Internetanbieters (oder einen von Ihrem Router vorgegebenen Resolver) geht. Auch wenn der Seiteninhalt weiterhin durch den Tunnel fließen mag, verrät die Anfrage selbst jede von Ihnen besuchte Domain an einen Dritten – und verknüpft sie mit Ihrer echten IP.

Die üblichen Schuldigen sind ein Betriebssystem, das die DNS-Einstellungen des VPN ignoriert, ein fest eingetragener Resolver (etwa ein manuell gesetztes 8.8.8.8 oder 1.1.1.1), der den Tunnel umgeht, oder Split-Tunnel-Regeln, die DNS am VPN vorbeileiten. Speziell unter Windows kann eine Funktion namens Smart Multi-Homed Name Resolution DNS-Anfragen gleichzeitig über jede Netzwerkschnittstelle abfeuern und diejenige verwenden, die zuerst antwortet – häufig die Ihres Internetanbieters.

WebRTC-Lecks: Der Browser, der Ihre IP herausgibt

WebRTC (Web Real-Time Communication) ist die Browser-Technologie hinter Videoanrufen, Sprach-Chats und Peer-to-Peer-Dateiübertragungen direkt auf der Seite. Um zwei Gegenstellen direkt zu verbinden, muss WebRTC die eigenen IP-Adressen des Geräts ermitteln. Dazu nutzt es STUN-Server, die dem Browser die öffentliche IP zurückmelden, die sie sehen, und es ermittelt zusätzlich lokale Netzwerkadressen. Eine Webseite kann diese ICE-Kandidaten über eine JavaScript-API auslesen – ohne jede Berechtigungsabfrage und ohne dass Sie irgendwo klicken.

Hier liegt der Haken, der WebRTC selbst mit funktionierendem VPN gefährlich macht: Diese Ermittlung kann außerhalb des Proxy-Pfads stattfinden, den Ihr Browser für normale Seitenaufrufe verwendet. Die Seite kann am Ende die öffentliche IP sehen, die Ihr Betriebssystem für die echte hält – und das kann Ihre wahre Adresse sein statt der des VPN. Ein WebRTC-Leck ist ein Browser-Problem. Es wird weder durch die DNS-Einstellungen Ihres VPN noch durch dessen Kill-Switch behoben – genau deshalb sind Menschen, die ihr DNS-Leck behoben haben, verblüfft, wenn ihre IP weiterhin angezeigt wird.

IPv6-Lecks: Datenverkehr auf einer Straße, die der Tunnel nie gebaut hat

Viele VPN-Tunnel transportieren ausschließlich IPv4-Verkehr. Wenn Ihr Internetanbieter und Ihr Heimnetzwerk zugleich IPv6-Konnektivität bereitstellen – zunehmend der Standard –, dann kann jede Anfrage an ein IPv6-fähiges Ziel über Ihre native IPv6-Verbindung laufen, vollständig außerhalb des reinen IPv4-Tunnels. Die Website sieht Ihre echte IPv6-Adresse. Das VPN hat diesen Verkehr nie berührt und ihn oft nicht einmal bemerkt, weil es nur die IPv4-Seite beobachtet hat.

Deshalb ist ein IPv6-Leck so unauffällig verbreitet: Nichts geht kaputt, nichts sieht falsch aus, und das VPN meldet Erfolg. Die Lösung besteht entweder darin, IPv6 auf dem Gerät oder im Netzwerk zu deaktivieren, oder ein VPN zu verwenden, das IPv6 ausdrücklich tunnelt oder während der Verbindung blockiert. Darauf zu hoffen, dass Ihr Anbieter das stillschweigend regelt, ist keine Strategie – Sie testen darauf.

Den Test durchführen: kostenlose Tools und wie man sie liest

Verwenden Sie unabhängige Tools von Drittanbietern statt der „Ihre IP ist verborgen“-Seite, die Ihnen Ihr VPN-Anbieter zeigt – ein Anbieter hat jeden Anreiz, Erfolg zu melden. Führen Sie jeden Test bei verbundenem VPN durch, im selben Browser und auf demselben Gerät, das Sie tatsächlich nutzen. Als Ausgangswert lohnt es sich, die Tests zunächst einmal mit ausgeschaltetem VPN laufen zu lassen, damit Sie wissen, wie Ihre echte IP und Ihr Anbieter aussehen; schalten Sie dann das VPN ein und bestätigen Sie, dass diese Werte verschwinden.

Schritt 1 – DNS-Leak-Test

Öffnen Sie dnsleaktest.com und führen Sie den Extended Test aus. Er lädt eine Reihe einzigartiger Hostnamen und meldet, welche DNS-Server sie aufgelöst haben. Ein sauberes Ergebnis zeigt Resolver, die zu Ihrem VPN-Anbieter gehören (oder zu einem Datenschutz-Resolver, den das VPN nutzt), und nennt entscheidend nicht den Namen Ihres Internetanbieters oder Ihr Heimatland, wenn Sie sich mit einem Server anderswo verbunden haben. Ein leckendes Ergebnis zeigt den Resolver Ihres Anbieters oder Server an Ihrem echten Standort, die Sie nicht erwartet haben. ipleak.net zeigt dieselben DNS-Informationen neben Ihrer IP an, was zum Gegenprüfen praktisch ist.

Schritt 2 – WebRTC-Leak-Test

Öffnen Sie browserleaks.com/webrtc. Achten Sie auf die Public IP Address, die per WebRTC ermittelt wird. Ein sauberes Ergebnis zeigt entweder keine öffentliche IP oder nur die IP des VPN-Servers. Ein leckendes Ergebnis zeigt im WebRTC-Abschnitt Ihre echte öffentliche IP, obwohl der Seitenkopf (der eine normale HTTP-Anfrage nutzt) die VPN-IP anzeigt – diese Diskrepanz ist die klassische Signatur eines WebRTC-Lecks. Lokale Adressen in den Bereichen 10.x, 172.16–31.x, 192.168.x oder .local-mDNS sind in der Regel harmlos; die echte Gefahr ist das Erscheinen Ihrer tatsächlichen öffentlichen IP.

Schritt 3 – IPv6- und Gesamt-IP-Test

Öffnen Sie ipleak.net. Es zeigt Ihre IPv4-Adresse, eine etwaige IPv6-Adresse und Ihre DNS-Server auf einer Seite. Ein sauberes Ergebnis zeigt nur die IP des VPN (passend zum gewählten Land) und entweder keine IPv6-Adresse oder eine IPv6, die ebenfalls zum VPN gehört. Ein leckendes Ergebnis zeigt eine IPv6-Adresse Ihres Internetanbieters oder ein IPv4/IPv6-Paar, das auf zwei verschiedene Standorte verweist. Wenn Sie eine echte IPv6 neben einer VPN-IPv4 sehen, ist das ein Musterbeispiel für ein IPv6-Leck.

Ein VPN, das Ihre IPv4 verbirgt, aber Ihre IPv6 offenlegt, hat Sie nicht halb geschützt – für jede IPv6-fähige Seite nutzen Sie schlicht überhaupt kein VPN.

Die genauen Lösungen, pro Betriebssystem, Browser und Router

DNS-Lecks beheben

• In der VPN-App: Aktivieren Sie jede Option wie „Nur VPN-DNS verwenden“, „DNS-Leak-Schutz“ oder „Nicht-VPN-DNS blockieren“. Viele Apps haben das standardmäßig aktiv, doch Drittanbieter-Konfigurationen für OpenVPN/WireGuard oft nicht.

• Windows: Deaktivieren Sie Smart Multi-Homed Name Resolution, die DNS über mehrere Schnittstellen streut. Unter Windows Pro können Sie die Gruppenrichtlinie „Intelligente Multi-Homed-Namensauflösung deaktivieren“ auf Aktiviert setzen; andernfalls bevorzugen Sie einen VPN-Client, der DNS setzt und andere Resolver blockiert. Entfernen Sie während des Tests jeden manuell konfigurierten öffentlichen DNS (8.8.8.8, 1.1.1.1) aus Ihren Adaptern.

• macOS / Linux: Stellen Sie sicher, dass in den Netzwerkeinstellungen oder in /etc/resolv.conf kein Resolver fest eingetragen ist, der den Tunnel umgeht; lassen Sie den VPN-Client das DNS verwalten. Unter Linux mit systemd-resolved bestätigen Sie, dass das VPN eine Domain-Route setzt, damit Anfragen an seinen Resolver gehen.

• Router: Wenn Sie das VPN auf dem Router betreiben, stellen Sie das DNS des Routers auf den Resolver des VPN ein und deaktivieren Sie jegliches vom Internetanbieter zugewiesene DNS. Deaktivieren Sie außerdem Router-Funktionen, die DNS abfangen oder umleiten (manche Einstellungen für „Kindersicherung“ oder „DNS-Rebind-Schutz“).

WebRTC-Lecks beheben (nur Browser)

• Firefox: Geben Sie about:config in die Adressleiste ein, akzeptieren Sie die Warnung, suchen Sie nach media.peerconnection.enabled und setzen Sie es auf false. Damit wird WebRTC vollständig deaktiviert. Wenn Sie WebRTC für Anrufe benötigen, lassen Sie es an, verlassen Sie sich aber auf ein VPN bzw. eine Erweiterung, die die ermittelte IP maskiert, und testen Sie erneut.

• Chrome / Edge: Es gibt keinen eingebauten Schalter, um WebRTC vollständig zu deaktivieren. Beachten Sie, dass die alte Option „Prevent WebRTC from leaking local IP addresses“ von uBlock Origin bereits 2021 aus der Desktop-Erweiterung entfernt wurde – und selbst als es sie gab, maskierte sie nur lokale/LAN-Adressen; sie verhinderte nie die Preisgabe der öffentlichen IP, die Sie tatsächlich enttarnt, war also nie die Lösung, für die man sie hielt. Modernes Chromium verschleiert lokale IPs bereits per mDNS (Sie können das Flag „Anonymize local IPs exposed by WebRTC“ unter chrome://flags prüfen). Um die Preisgabe der öffentlichen IP zu steuern, verwenden Sie eine dedizierte WebRTC-Steuerungserweiterung und überprüfen Sie das Ergebnis anschließend mit einem Leak-Test, da Erweiterungen unterschiedlich vollständig blockieren.

• Safari: Die WebRTC-Preisgabe ist standardmäßig stärker begrenzt, testen Sie aber dennoch. Über das Menü „Entwickler“ können Sie sie via experimentelle/WebRTC-Funktionen deaktivieren, wenn Sie sie nicht brauchen.

• Realitätscheck: Das Deaktivieren von WebRTC kann Google Meet, Discord im Browser, Jitsi und ähnliche Tools lahmlegen. Wenn Sie diese benötigen, ist der praktische Weg ein Browser bzw. eine Erweiterung, die nur die VPN-IP herausgibt, statt WebRTC komplett abzuschalten – bestätigt durch erneutes Testen.

IPv6-Lecks beheben

• Beste Option: Verwenden Sie ein VPN, das ausdrücklich IPv6-Leak-Schutz bietet (es blockiert oder tunnelt IPv6 während der Verbindung). Schalten Sie diese Einstellung ein und testen Sie erneut.

• Windows: Deaktivieren Sie IPv6 am aktiven Adapter (Eigenschaften des Netzwerkadapters, Häkchen bei Internetprotokoll Version 6 entfernen) oder nutzen Sie die IPv6-Blockierung des VPN. Aktivieren Sie es wieder, wenn Sie kein VPN mehr nutzen, das damit nicht umgehen kann.

• macOS: Setzen Sie in den Systemeinstellungen die Option IPv6 konfigurieren des Netzwerkdienstes auf Nur Link-lokal (oder über die Kommandozeile auf Aus), falls Ihr VPN es nicht tunneln kann.

• Linux: Deaktivieren Sie IPv6 pro Schnittstelle oder systemweit via sysctl (zum Beispiel net.ipv6.conf.all.disable_ipv6=1), wenn der Tunnel nur IPv4 unterstützt.

• Router: Wenn Sie das VPN am Router betreiben, deaktivieren Sie das IPv6 des Routers bzw. das WAN-IPv6, damit kein Gerät im Netzwerk darüber lecken kann. Das ist die sauberste Lösung für einen ganzen Haushalt.

Warum ein „verbundenes“ VPN trotzdem leckt

Selbst nachdem Sie alle drei Tests einmal bestanden haben, ist der Schutz nicht dauerhaft – es ist ein Zustand, der unbemerkt kippen kann. Dies sind die Momente, in denen ein „verbundenes“ VPN still und leise zu lecken beginnt:

• Netzwerkwechsel: Der Wechsel von WLAN auf Ethernet, das Umschalten von Access Points oder Ihr Telefon, das zwischen WLAN und Mobilfunk hin- und herspringt, kann den Datenverkehr kurzzeitig außerhalb des Tunnels leiten, bevor das VPN seine Regeln neu aufbaut.

• Ruhezustand und Aufwachen: Wacht ein Laptop aus dem Ruhezustand auf, kommt das Netzwerk oft zurück, bevor das VPN sich wieder verbindet. Für ein paar Sekunden nutzt der Verkehr die nackte Verbindung – lang genug, dass Hintergrund-Apps mit Ihrer echten IP nach Hause telefonieren.

• Neuverbindungen und Abbrüche: Jedes Mal, wenn der Tunnel abbricht und neu wählt, gibt es ein Zeitfenster, in dem Verkehr entkommen kann, sofern kein Kill-Switch ihn blockiert.

• Captive Portals: WLAN in Hotels, Flughäfen und Cafés verlangt, dass Sie eine Login-Seite laden, bevor das Internet funktioniert. Diese Seite lädt konstruktionsbedingt außerhalb des VPN, und manche Konfigurationen bleiben undicht, bis Sie sich danach manuell neu verbinden.

• Split Tunneling: Wenn Sie bestimmte Apps – oder DNS – vom VPN ausgenommen haben, sind diese Ausnahmen per Konfiguration Lecks. Prüfen Sie genau, dass DNS nicht stillschweigend auf der „Bypass“-Liste steht.

• IPv6, das zurückkehrt: Ein Betriebssystem-Update oder ein Netzwerk-Reset kann zuvor deaktiviertes IPv6 unbemerkt wieder aktivieren und diesen Pfad ohne Vorwarnung erneut öffnen.

Kill-Switches und Leak-Schutz-Einstellungen – und wie sie still versagen

Ein Kill-Switch ist ein Sicherheitsnetz für das Problem von Abbruch und Neuverbindung: Geht der Tunnel runter, blockiert er sämtlichen Internetverkehr, bis das VPN zurück ist, damit in der Lücke nichts entkommt. Eingebauter Leak-Schutz (DNS-Leak-Schutz, IPv6-Blockierung, Network-Lock-Funktionen) erzwingt, dass DNS und IPv6 immer nur den Tunnel nutzen. Schalten Sie beides ein – sie kümmern sich um die Fehlerfenster, die Sie manuell nicht überwachen können.

Verstehen Sie aber ihre stillen Versagensmuster. Ein Kill-Switch greift nur, wenn die App erkennt, dass der Tunnel unten ist; ist der Tunnel technisch oben, leckt aber DNS oder IPv6 daran vorbei, sieht der Kill-Switch kein Problem und tut nichts. App-basierte Kill-Switches schützen nur den Verkehr der VPN-App selbst, nicht das gesamte System. Manche Kill-Switches greifen im Ruhezustand-/Aufwach-Fenster oder vor dem Login beim Hochfahren nicht. Und ein Kill-Switch im „Firewall-Stil“, der im ausgeschalteten Zustand den Verkehr komplett blockiert, kann mit einem Internetausfall verwechselt werden, was Menschen dazu verleitet, ihn zu deaktivieren. Die Lehre: Ein Kill-Switch verringert das Risiko, er ersetzt das Testen nicht. Der einzige Beweis, dass Ihre Einstellungen funktionieren, ist ein bestandener Test.

Harmloses Ergebnis vs. echtes Datenschutzversagen

Nicht jeder unbekannte Eintrag auf einer Leak-Test-Seite ist eine Katastrophe. Den Unterschied zu kennen bewahrt Sie davor, Gespenstern hinterherzujagen – oder eine echte Preisgabe zu übersehen.

• Harmlos: WebRTC zeigt nur lokale/private Adressen (10.x, 172.16–31.x, 192.168.x) oder einen mDNS-.local-Hostnamen. Diese identifizieren Sie gegenüber einer Website nicht.

• Harmlos: DNS-Resolver, die zu Ihrem VPN-Anbieter oder einem von ihm genutzten Datenschutz-Resolver gehören, selbst wenn sie in einer anderen Stadt als Ihr VPN-Server liegen – Anbieter betreiben ganze Resolver-Flotten.

• Harmlos: überhaupt keine IPv6-Adresse, wenn Sie IPv6 deaktiviert haben. Das ist das Ziel, kein Fehler.

• Echtes Versagen: jeder Test, der Ihre echte öffentliche IP (IPv4 oder IPv6), Ihre echte Stadt/Ihren Internetanbieter oder Ihr Heimatland zeigt, obwohl Sie sich bewusst anderswo verbunden haben.

• Echtes Versagen: DNS-Ergebnisse, die Ihren tatsächlichen Internetanbieter nennen, oder eine IPv4 und eine IPv6, die zu zwei verschiedenen Standorten auflösen.

• Echtes Versagen: Der Seitenkopf zeigt die VPN-IP, während der WebRTC-Abschnitt Ihre echte zeigt – die Diskrepanz ist das Leck.

Faustregel: Eine öffentliche IP oder der Name Ihres Internetanbieters, die dort auftauchen, wo sie nicht sein sollten, sind ein echtes Versagen. Private/lokale Adressen und anbietereigene Resolver sind Rauschen.

Re-Test-Disziplin: die Gewohnheit, die Sie wirklich schützt

Ein Leak-Test ist eine Momentaufnahme, kein Zertifikat. Da der Schutzzustand bei Netzwerkwechseln, Ruhezuständen, Neuverbindungen und Captive Portals kippt, ist der Test nur für die Bedingungen aussagekräftig, unter denen Sie getestet haben. Bauen Sie sich die Gewohnheit auf:

1. Testen Sie nach jeder Korrektur erneut – ändern Sie eine Einstellung, bestätigen Sie dann, dass genau dieses Leck geschlossen ist, bevor Sie weitermachen. Alle drei auf einmal zu beheben und nur einmal zu testen verschleiert, welche Änderung gewirkt hat.

2. Testen Sie nach jedem Netzwerkwechsel erneut – neues WLAN, Umschalten auf Mobilfunk, Ethernet einstecken oder nach einem Captive-Portal-Login.

3. Testen Sie nach dem Aufwachen aus dem Ruhezustand und nach einer VPN-Neuverbindung erneut, denn das sind die risikoreichsten Fenster.

4. Testen Sie nach Betriebssystem- und App-Updates erneut, die IPv6 unbemerkt wieder aktivieren oder das DNS-Verhalten zurücksetzen können.

5. Führen Sie jedes Mal alle drei Tests gemeinsam durch – DNS, WebRTC und IPv6 sind unabhängig, und ein sauberes Ergebnis bei einem sagt nichts über die anderen aus.

Praktisches Fazit

„Verbunden“ ist ein Ausgangspunkt, kein Beweis für Datenschutz. Testen Sie alle drei Lecks mit unabhängigen Tools – dnsleaktest.com für DNS, browserleaks.com/webrtc für WebRTC und ipleak.net für IPv6 und Ihre Gesamt-IP. Behandeln Sie sie als separate Probleme: Erzwingen Sie VPN-DNS auf Betriebssystem- oder Router-Ebene, neutralisieren Sie WebRTC im Browser und blockieren oder tunneln Sie IPv6. Schalten Sie für die Lücken, die Sie nicht überwachen können, Ihren Kill-Switch und den eingebauten Leak-Schutz ein, vertrauen Sie ihnen aber nie blind. Testen Sie dann nach jeder Korrektur und jedem Netzwerkwechsel erneut. Zehn Minuten Testen verraten Ihnen mehr über Ihre tatsächliche Gefährdung als jede Marketingseite eines Anbieters je könnte.

Häufig gestellte Fragen

Was ist ein VPN-Leak-Test und wie führe ich einen durch?

Ein VPN-Leak-Test prüft, ob Datenverkehr aus Ihrem verschlüsselten Tunnel entweicht und Ihre echte IP-Adresse oder DNS-Anfragen preisgibt, während das VPN verbunden ist. Führen Sie einen durch, indem Sie Ihr VPN verbinden und dann unabhängige Tools wie dnsleaktest.com, browserleaks.com/webrtc und ipleak.net besuchen. Zeigt eines davon Ihre echte öffentliche IP, Ihren Internetanbieter oder Ihren Heimatstandort, haben Sie ein Leck.

Wie funktioniert ein DNS-Leak-Test und was gilt als bestanden?

Ein DNS-Leak-Test lädt einzigartige Hostnamen und meldet, welche DNS-Server sie aufgelöst haben. Sie bestehen, wenn die Resolver zu Ihrem VPN-Anbieter gehören und Ihr eigener Internetanbieter nicht aufgeführt ist. Sie fallen durch, wenn der Resolver Ihres Anbieters erscheint oder die Server an Ihrem echten Standort liegen, obwohl Sie sich woanders verbunden haben.

Wie behebe ich ein DNS-Leck?

Aktivieren Sie zunächst „DNS-Leak-Schutz“ oder „Nur VPN-DNS verwenden“ in Ihrer VPN-App. Deaktivieren Sie unter Windows zusätzlich Smart Multi-Homed Name Resolution und entfernen Sie jeden manuell gesetzten öffentlichen DNS wie 8.8.8.8 aus Ihrem Adapter. Auf einem Router, der das VPN betreibt, richten Sie das DNS des Routers auf den VPN-Resolver, deaktivieren Sie das vom Anbieter zugewiesene DNS und testen Sie erneut.

Was ist ein WebRTC-Leck und stoppt mein VPN es?

Ein WebRTC-Leck liegt vor, wenn die Echtzeit-Kommunikationsfunktion Ihres Browsers Ihre echte IP-Adresse ermittelt und einer Webseite preisgibt, selbst wenn das VPN verbunden ist. Die meisten VPNs stoppen es nicht, weil es ein Browser-Verhalten ist, kein Netzwerk-Verhalten. Beheben Sie es in Firefox, indem Sie media.peerconnection.enabled in about:config auf false setzen. Chrome und Edge haben keinen eingebauten Schalter zum Deaktivieren von WebRTC, also nutzen Sie eine dedizierte WebRTC-Steuerungserweiterung und testen Sie erneut – verlassen Sie sich nicht auf die alte Lokal-IP-Option von uBlock Origin, die aus der Desktop-Erweiterung entfernt wurde und ohnehin nie die Preisgabe der öffentlichen IP verhinderte.

Was ist ein IPv6-Leck und wie verhindere ich es bei meinem VPN?

Ein IPv6-Leck entsteht, wenn Ihr reiner IPv4-VPN-Tunnel IPv6-Verkehr ignoriert, sodass dieser über Ihre Anbieterverbindung läuft und Ihre echte IPv6-Adresse preisgibt. Verhindern Sie es, indem Sie den IPv6-Leak-Schutz in Ihrem VPN aktivieren oder IPv6 auf Ihrem Gerät oder Router deaktivieren. Bestätigen Sie nach der Änderung auf ipleak.net, dass keine IPv6-Adresse Ihres Anbieters erscheint.

Verhindert ein Kill-Switch DNS- und WebRTC-Lecks?

Nicht zuverlässig. Ein Kill-Switch blockiert den Verkehr nur, wenn er erkennt, dass der Tunnel abgebrochen ist, und unternimmt daher nichts gegen DNS- oder WebRTC-Lecks, die auftreten, während der Tunnel noch steht. Sie brauchen separaten DNS-Leak-Schutz und browserseitiges WebRTC-Härten, mit dem Kill-Switch als Absicherung für Neuverbindungen und Abbrüche.

Wie oft sollte ich einen VPN-Leak-Test durchführen?

Testen Sie nach jeder Konfigurationsänderung und testen Sie nach jedem Netzwerkwechsel, jedem Ruhezustand-/Aufwach-Zyklus, jeder VPN-Neuverbindung, jedem Captive-Portal-Login und jedem größeren Betriebssystem- oder App-Update erneut. Jeder dieser Momente kann ein Leck unbemerkt wieder öffnen. Führen Sie immer alle drei Tests gemeinsam durch, da DNS, WebRTC und IPv6 unabhängige Probleme sind.