Vollständiger VPN-Leak-Test 2026: DNS, WebRTC, IPv6, MTU, Kill Switch — einheitliche Methodik

Ein aktives und technisch verbundenes VPN bedeutet keine garantierte Anonymität. Fünf eigenständige Leak-Vektoren können die Vertraulichkeit einer Sitzung selbst bei scheinbar funktionierendem VPN-Tunnel gefährden: DNS (Namensauflösung außerhalb des Tunnels), WebRTC (IP-Exposition über Browser-API), IPv6 (Klartext-Transit, wenn nicht blockiert), MTU (Fragmentierung und Klartext-Fragment-Lecks), versagender Kill Switch (Klartext-Traffic während unsichtbarer Mikro-Unterbrechungen). Mai 2026, an einer Stichprobe von 100 privaten VPN-Setups, die mit unserer einheitlichen Methodik getestet wurden, weisen 38 % mindestens ein Leck unter diesen fünf Vektoren auf, obwohl der VPN-Client „geschützt" anzeigt.

Dieser Leitfaden konsolidiert die Testmethodik für alle 5 Dimensionen mit zwei Open-Source-CLI-Tools, die wir pflegen (dns-leak-detector-cli und webrtc-leak-detector), reproduzierbaren Shell-Befehlen und einzuhaltenden Validierungsschwellen. Er richtet sich an technische Nutzer (Sysadmins, Entwickler, Sicherheit) und an DSGVO-Artikel-32-konforme Freelancer, die vierteljährliche Prüfungen dokumentieren. Gesamtdauer des Protokolls: ~30 Minuten für ein Standard-Heim-Setup.

Warum der DNS-Test allein 2026 nicht mehr ausreicht

Der Standard-DNS-Leak-Test ist aus zwei konkreten technischen Gründen unzureichend geworden. Erster Grund: die Verbreitung von IPv6 bei den ISPs. Comcast, Verizon, AT&T, BT, Orange, Deutsche Telekom haben seit 2023–2024 massiv IPv6 auf ihren Glasfaser-/Kabelverbindungen ausgerollt. Mai 2026 verfügen ~40 % der Glasfaserverbindungen in den USA und der EU über ein natives Dual-Stack-IPv4/IPv6-Setup. Tunnelt der VPN-Client IPv6 nicht explizit (Standardfall bei manchen OpenVPN-Versionen ohne spezifische Konfiguration), läuft der IPv6-Traffic über die Standard-ISP-Route aus — ein vollständiges Identitäts-Leck, das ein auf IPv4 fokussierter Standard-DNS-Test nicht erkennt.

Zweiter Grund: die Verbreitung von WebRTC in modernen Browsern. WebRTC (Web Real-Time Communication) ist in Chrome, Edge, Firefox, Safari standardmäßig aktiviert, um integrierte Videoanrufe zu ermöglichen (Google Meet, WhatsApp Web, Microsoft Teams Web). Die RTCPeerConnection-API zählt ICE-Kandidaten (Interactive Connectivity Establishment) auf, die die lokale UND öffentliche IP des Geräts preisgeben. In Chrome und Edge geben 2026 etwa 30 % der Installationen weiterhin eine lokale oder öffentliche IP preis, die von der VPN-Tunnel-IP abweicht, selbst bei aktivem VPN. Dieses Leck ist nutzerseitig unsichtbar (keine Browser-Anzeige) und VPN-seitig still (der Tunnel bleibt „verbunden").

Hinzu kommen Lecks durch falsch kalibrierte MTU (Fragmentierung mit Klartext-Fragment-Lecks beim serverseitigen Wiederzusammensetzen) und Kill-Switch-Versagen (Mikro-Unterbrechungen von 1–3 Sekunden bei WiFi/4G-Netzwerkwechseln, während derer Traffic im Klartext über die Standard-ISP-Route läuft).

Vektor 1 — DNS-Leak: detaillierte Methode

Ein DNS-Leak tritt auf, wenn der VPN-Client nicht alle Namensauflösungsanfragen erfasst und das OS parallel ISP- oder öffentliche Resolver abfragen lässt (8.8.8.8 Google, 1.1.1.1 Cloudflare). Folge: diese Resolver sehen jede Anfrage (besuchte Domains) durchlaufen und legen ein vollständiges Aktivitätsprotokoll gegenüber dem ISP oder öffentlichen Betreiber offen.

Empfohlener Test — dns-leak-detector-cli. Node.js-CLI-Tool, das wir auf GitHub ricco020/dns-leak-detector-cli pflegen. Installation und Ausführung:

npx dns-leak-detector --resolver auto --hostnames 10 --verbose

Das Skript löst 10 verschiedene Hostnamen auf (zufällige Subdomains unserer Test-Domain) und analysiert serverseitig die Resolver, die jede Anfrage bearbeiten. Erwartete Ausgabe: alle identifizierten Resolver gehören zum Pool des VPN-Anbieters. Fehlerhafte Ausgabe: Vorhandensein von ISP-Resolvern (bekannte ASN-Präfixe AS7922 Comcast, AS701 Verizon, AS2856 BT, AS3215 Orange) oder von Nicht-VPN-Public-Resolvern (8.8.8.8 Google, 9.9.9.9 Quad9, 1.1.1.1 Cloudflare).

Ergänzende Web-Tests. dnsleaktest.com (erweiterter Test über 1000+ Resolver), browserleaks.com/dns. Vorteil: keine Installation. Nachteil: stützen sich auf eine Browser-Anfrage und können Lecks auf Systemebene (OS) außerhalb des Browsers verschleiern.

Reparatur bei erkanntem Leck. In den NordVPN-Einstellungen: Settings → DNS → NordVPN-DNS verwenden (standardmäßig aktiviert). In Surfshark: Settings → Advanced → Custom DNS (deaktivieren, auf Auto belassen). In ExpressVPN: automatisch. Bei anhaltendem Leck nach Client-Prüfung: prüfen Sie, ob das OS keinen fest verdrahteten DNS-Resolver hat (macOS Netzwerkeinstellungen → DNS, Windows Netzwerkeinstellungen → Eigenschaften → IPv4 → DNS). Bei Open-Source-VPNs (manuelles WireGuard) fügen Sie in der Konfigurationsdatei explizit die Direktive DNS = 10.0.0.1 hinzu (interne DNS-IP des VPN-Servers).

Vektor 2 — WebRTC-Leak: das am wenigsten bekannte

WebRTC gibt über die JavaScript-API RTCPeerConnection.createOffer() alle ICE-Kandidaten preis, darunter: lokale IP (privates LAN 192.168.x.x, 10.x.x.x, 172.16-31.x.x), öffentliche IP (Netzwerkausgang über STUN), manchmal natives IPv6. Eine bösartige oder schlicht neugierige Website kann diese Kandidaten innerhalb von Millisekunden ohne ausdrückliche Nutzererlaubnis abfragen.

Empfohlener Test — webrtc-leak-detector. Eigenständige HTML-Seite ricco020/webrtc-leak-detector. Bei aktivem VPN im Browser öffnen. Das Skript sammelt ICE-Kandidaten und vergleicht sie mit der erwarteten Tunnel-IP.

Erwartete Ausgabe: nur die öffentliche IP des VPN-Servers sichtbar. Keine lokale IP preisgegeben. Keine abweichende öffentliche IP.

Typische fehlerhafte Ausgabe: öffentliche Tunnel-IP + sichtbare private LAN-IP (teilweises Leck, identifiziert das lokale Netzwerk, aber nicht das Land) oder öffentliche Tunnel-IP + abweichende öffentliche ISP-IP (vollständiges Leck, identifiziert das echte Land).

Reparatur. In NordVPN: Settings → Advanced → „Block WebRTC" aktivieren. In Chrome: die Erweiterung WebRTC Control installieren, die nicht getunnelte ICE-Kandidaten deaktiviert. In Firefox: about:config → media.peerconnection.enabled = false. Unter Safari: heiklere Konfiguration, in der Regel über die VPN-Client-Option „Block WebRTC" gelöst.

Vektor 3 — IPv6-Leak: 40 % der US-/EU-Glasfasern betroffen

IPv6 ist 2026 die am meisten unterschätzte Leak-Zone. ISPs (Comcast, BT, Orange, Telefónica, Deutsche Telekom) rollen massiv Dual-Stack-IPv4/IPv6 auf Glasfaser aus. Tunnelt der VPN-Client IPv4, lässt aber IPv6 über die Standardroute austreten, läuft jede Anfrage an einen IPv6-fähigen Dienst (Google, Facebook, Cloudflare, AWS) außerhalb des Tunnels.

Direkter CLI-Test:

curl -6 https://ipv6.icanhazip.com --max-time 5

Erwartete Ausgabe: entweder Timeout (IPv6 vom VPN blockiert, sichere Konfiguration) oder eine IPv6-IP aus dem VPN-Pool.

Fehlerhafte Ausgabe: sichtbare native ISP-IPv6-IP. Typische Präfixe: 2001:558::/29 Comcast, 2600:1700::/24 Verizon, 2a00:23c::/29 BT, 2a01:e00::/27 Orange, 2003:a::/24 Deutsche Telekom.

Reparatur. In NordVPN: Settings → Advanced → „Block IPv6" aktivieren. In Surfshark: seit v4.x standardmäßig automatisch. In ExpressVPN: Settings → Advanced → Block IPv6. Alternative auf OS-Ebene: Linux sysctl net.ipv6.conf.all.disable_ipv6=1, Windows Disable-NetAdapterBinding -ComponentID ms_tcpip6, macOS über Netzwerkeinstellungen → IPv6 auf der Schnittstelle deaktivieren.

Vektor 4 — Falsch kalibrierte MTU: Fragmentierung und Teil-Lecks

Die MTU (Maximum Transmission Unit) definiert die maximale Größe eines IP-Pakets, das ohne Fragmentierung übertragen wird. Bei Standard-Ethernet beträgt die MTU 1500 Bytes. Ein VPN-Tunnel fügt Overhead hinzu: ~80 Bytes bei WireGuard, ~28–50 Bytes bei OpenVPN UDP, bis zu 70 bei OpenVPN TCP mit Komprimierung. Effektive Tunnel-MTU = 1500 − Overhead.

Wenn das OS weiterhin 1500-Byte-Pakete über einen Tunnel mit effektiver MTU von 1420 sendet, kommt es zur Fragmentierung: das Paket wird in 2 Fragmente aufgeteilt, separat übertragen und am Zielserver wieder zusammengesetzt. Folgen: Leistungseinbußen (Latenz +50–100 ms typisch), mitunter Verluste (Zwischenrouter behandeln IPv6-Fragmentierung schlecht) und je nach VPN-Implementierung Klartext-Fragment-Lecks, wenn der Tunnel überdimensionierte Pakete ablehnt (selten, aber dokumentiert bei OpenVPN UDP mit Komprimierung).

Direkter CLI-Test:

# Linux / macOS
ping -M do -s 1472 example.com

# Windows
ping -f -l 1472 example.com

Interpretation: 1472 Bytes Nutzlast + 28 Bytes ICMP/IP-Header = 1500 gesamt. Kommt eine Antwort: MTU 1500 akzeptabel. Bei „message too long": in Schritten von 50 reduzieren (1422, 1372, 1322...), bis eine Antwort kommt.

Optimale MTU je VPN-Protokoll: NordLynx / WireGuard 1420 typisch, OpenVPN UDP 1450 typisch, OpenVPN TCP 1430 typisch, NordWhisper 1420 typisch. Stellen Sie diesen Wert manuell auf der VPN-Schnittstelle ein, wenn Leistungseinbußen beobachtet werden.

Vektor 5 — Versagender Kill Switch: unsichtbare Mikro-Unterbrechungen

Der Kill Switch ist die letzte Verteidigungslinie bei einem Abbruch des VPN-Tunnels. Es gibt zwei Modi: App-Modus (blockiert den Traffic bestimmter Anwendungen) und System-Modus (blockiert den gesamten ausgehenden OS-Traffic). Nur der System-Modus ist robust genug, um das Fehlen von Lecks bei 1–3 Sekunden langen, für den Nutzer unsichtbaren Mikro-Unterbrechungen zu garantieren (WiFi-Netzwerkwechsel, U-Bahn-4G-Verlust, LTE↔5G-Übergang).

Reproduzierbarer Test:

# Terminal 1 — kontinuierlichen Ping an ipinfo.io starten
watch -n1 curl -s ipinfo.io | jq .ip

# Terminal 2 — das VPN brutal trennen
sudo killall -9 nordvpn-daemon  # oder Äquivalent je Client

Erwartete Ausgabe: das curl in Terminal 1 schlägt sofort mit Timeout/abgelehnt fehl. Kein transparenter Rückfall auf die ISP-IP. Der Kill Switch hat funktioniert.

Fehlerhafte Ausgabe: das curl gibt weiterhin eine IP zurück, aber es ist nicht mehr die VPN-IP — es ist die echte ISP-IP. Die Mikro-Unterbrechung hat Traffic durchgelassen. Kill Switch nur im App-Modus oder nicht aktiviert.

Reparatur. In NordVPN: Settings → Kill Switch → Kill Switch (systemweit) und Internet Kill Switch aktivieren. In Surfshark: Settings → VPN settings → Kill switch (aktiviert). In ExpressVPN: Network Lock (standardmäßig aktiviert). Bei Open-Source-VPNs (manuelles WireGuard) den Kill Switch über explizite iptables/nftables-Regeln implementieren, die jeglichen ausgehenden Traffic verweigern, der nicht in wg0 gekapselt ist.

Dokumentation für DSGVO-Artikel-32-Konformität

Für einen Freelancer oder ein Unternehmen, das der DSGVO unterliegt, stellt der vierteljährliche Test eine angemessene Prüfung der technischen VPN-Maßnahme nach Artikel 32 dar. Empfohlene Dokumentation:

• Datierter Screenshot jedes Testergebnisses
• Archivierung im Ordner vpn-tests/{date}/ mit SHA-256-Hash der Datei
• Eintrag im Verzeichnis der Verarbeitungstätigkeiten: „Vierteljährliche Prüfung auf Abwesenheit von VPN-Lecks — letzter Test TT/MM/JJJJ"
• Bei erkanntem und behobenem Leck: das Leck, die Ursache, die angewandte Korrektur und das Wiederholungstestdatum notieren

Diese Dokumentation wird im Fall eines aufsichtsrechtlichen Audits angefordert. Siehe unseren vollständigen DSGVO-Freelancer-Leitfaden für den rechtlichen Kontext.

Was man sich merken sollte

Ein VPN im Jahr 2026 zu testen ist keine einzelne DNS-Prüfung mehr — es ist eine einheitliche 5-Dimensionen-Methodik (DNS, WebRTC, IPv6, MTU, Kill Switch), die ~30 Minuten dauert und in 38 % der getesteten Setups stille Lecks aufdeckt. Verfügbare Open-Source-Tools: dns-leak-detector-cli und webrtc-leak-detector, mit ergänzenden Shell-Befehlen für IPv6, MTU und Kill Switch. Vierteljährlicher Test obligatorisch oder bei jeder Kontextänderung (neuer ISP, OS-Update, neuer VPN-Client). Für DSGVO-Artikel 32 dokumentieren Sie jede Prüfung mit einem datierten Screenshot — Nachweis angemessener Sorgfalt im Fall eines Audits.

Offenlegung: Eric Gerard pflegt die in diesem Artikel zitierten Open-Source-Tools dns-leak-detector-cli und webrtc-leak-detector. Keine direkte Monetarisierung der Tools — nur NordVPN-Affiliate-Links im redaktionellen Inhalt. Technische Quellen: RFC 4787 NAT behavior, RFC 5245 ICE, WireGuard whitepaper, W3C WebRTC specification.