Netzwerk-Lecksuche 2026: DNS-, WebRTC-, IPv6-Testanleitung

Ein VPN ändert Ihre Exit-IP. Es versiegelt standardmäßig nicht jeden Pfad, durch den Ihre wahre Identität durchsickert. DNS-Anfragen, WebRTC-Peer-Erkennung und IPv6-Pakete stellen jeweils unterschiedliche Kanäle dar, die typische VPN-Konfigurationen umgehen oder ihnen vorausgehen. Diese Anleitung bietet ein reproduzierbares Testprotokoll und den technischen Hintergrund, um zu verstehen, was jeder Lecktyp offenlegt und wie man jede Lücke schließt.

1. Warum Netzwerk-Lecks im Jahr 2026 bestehen bleiben

Die Architektur des Internets wurde nicht mit Tunnel-Durchsetzung im Sinn entworfen. Wenn Sie sich mit einem VPN verbinden, erstellt der Client typischerweise eine virtuelle Netzwerkschnittstelle, installiert Routing-Regeln und aktualisiert die DNS-Konfiguration des Systems. Jeder dieser Vorgänge hat Fehlermodi — und Fehler sind häufig.

Drei Bedrohungsakteure konzentrieren das meiste praktische Risiko für Nutzer, die ein VPN speziell zur Wahrung ihrer Privatsphäre verwenden:

Überwachung auf ISP-Ebene. Ihr ISP kann Ihre DNS-Anfragen an ihrem rekursiven Resolver beobachten, es sei denn, Sie leiten DNS innerhalb des VPN-Tunnels. Bei privaten Verbindungen bedeutet dies, dass sie ein Protokoll jedes Hostnamens sehen, den Sie aufrufen. In Rechtsordnungen mit Vorratsdatenspeicherungsgesetzen (EU-Richtlinie 2006/24-Nachfolger, UK IPA 2016, Australien TSSR) speichern ISPs diese Daten für Monate bis Jahre. Ein DNS-Leck ermöglicht diese Fähigkeit für die gesamte Sitzung erneut.

Öffentliches WLAN und Captive Portals. Verwaltetes WLAN in Hotels, Flughäfen und Coworking-Spaces fängt regelmäßig den Verkehr ab, bevor die VPN-Verhandlung abgeschlossen ist. DHCP weist eine Gateway-Adresse zu, und bis der VPN-Tunnel aktiv ist, fließt der gesamte Verkehr — einschließlich DNS und WebRTC — über das Captive-Netzwerk. Einige Captive Portals blockieren aktiv VPN-Protokolle, um Umgehungen zu verhindern, was zu erneuten Verbindungsversuchen führt, die wiederholte Expositionsfenster schaffen.

In-Browser-Tracking im großen Maßstab. Analyse- und Werbeskripte, die auf gewöhnlichen kommerziellen Websites geladen werden, können WebRTC-Code ausführen, um IP-Kandidaten zu sammeln, ohne irgendwelche Berechtigungen anzufordern. Im Jahr 2026 laden mindestens 340 der Top-10.000-Websites laut Alexa-Rang mindestens ein Drittanbieter-Skript, das RTCPeerConnection untersucht. Für Nutzer unter einem VPN offenbart dies die lokale Netzwerkadresse und manchmal die öffentliche Adresse, die vom ISP zugewiesen wurde — Daten, die mit einer haushaltsbezogenen Identität korrelieren können, selbst ohne die Exit-IP.

Zu verstehen, welcher Kanal leckt, erfordert das unabhängige Testen jedes einzelnen. Kombinierte "Leake ich?"-Seiten vermischen Ergebnisse und übersehen oft Randfälle. Ein strukturiertes Testprotokoll — dokumentiert in Abschnitt 5 — bietet zuverlässige Abdeckung.

Für Kontext, wie Leckexposition in die breitere Browser-Datenschutzlandschaft passt, siehe die State of Browser Privacy 2026 Übersicht von PrivSec Lab. Um Ihre Canvas- und WebGL-Fingerabdruckexposition parallel zu testen, verwenden Sie unser interaktives Browser-Fingerabdruck-Test-Tool.

Was ist ein DNS-Leck und wie erkennt man es?

Ein DNS-Leck tritt auf, wenn Ihre DNS-Anfragen Ihren VPN-Tunnel umgehen und stattdessen den Resolver Ihres ISPs erreichen, wodurch jeder Hostname, den Sie besuchen, trotz des VPNs offengelegt wird. Es passiert, weil VPN-Clients oft nicht alle System-DNS-Pfade überschreiben — einschließlich browserseitigem DoH und sekundären Netzwerkadaptern. Erkennen Sie es, indem Sie den erweiterten Test von dnsleaktest.com ausführen und überprüfen, ob der angezeigte Resolver-ASN mit Ihrem VPN-Anbieter übereinstimmt, nicht mit Ihrem ISP.

DNS-Lecks — Mechanismus und Erkennung

Die DNS-Auflösung folgt einer Prioritätsreihenfolge, die vom Betriebssystem definiert wird. Unter Linux regeln /etc/nsswitch.conf und /etc/resolv.conf dies. Unter Windows fragt der DNS-Client die konfigurierten Resolver jedes Adapters in der Reihenfolge ab und verwendet NRPT (Name Resolution Policy Table)-Regeln für domainspezifische Überschreibungen. Unter macOS bestimmen die Resolver-Konfiguration in /etc/resolver/ und die scutil --dns-Ausgabe das Verhalten.

Ein VPN-Client, der DNS-Lecks korrekt verhindert, muss all diese Pfade überschreiben. Die häufigsten Fehlermodi sind:

Systemresolver nicht vollständig ersetzt. Einige VPN-Clients aktualisieren die DNS-Einstellung des primären Adapters, lassen aber sekundäre Adapter (Ethernet während des WLAN-Betriebs zum Beispiel) auf den ISP-Resolver zeigen. Abfragen können je nach Netzwerkbedingungen über eine der beiden Schnittstellen geleitet werden.

Browser-DoH-Umgehung. Chrome und Firefox implementieren DNS-over-HTTPS (RFC 8484) unabhängig vom Betriebssystem. Wenn das eingebaute DoH des Browsers aktiviert ist und auf einen öffentlichen Resolver (Cloudflare 1.1.1.1, Google 8.8.8.8) zeigt, umgehen diese Anfragen das VPN-DNS vollständig und gehen direkt über HTTPS an den externen Resolver. Die resultierende Auflösung erfolgt außerhalb des VPN-Tunnels, obwohl die HTTPS-Verbindung selbst verschlüsselt ist.

DNS-Vorabruf und spekulative Auflösung. Browser senden spekulative DNS-Anfragen für Links auf der aktuellen Seite, bevor der Benutzer navigiert. Diese verwenden den DNS-Stack des Browsers, der DoH oder den Systemresolver aufrufen kann. Erweiterungen, die <link rel="dns-prefetch">-Tags deaktivieren, reduzieren diese Oberfläche, eliminieren jedoch nicht vollständig die Hintergrundauflösung.

Testen von DNS-Lecks:

1. dnsleaktest.com — führen Sie sowohl Standard- als auch erweiterte Tests durch. Der erweiterte Test sendet über 30 Anfragen, um die Nutzung aller sekundären Resolver-Pfade zu erzwingen. Vergleichen Sie den ASN (Autonomous System Number) und die IP der angezeigten Resolver mit dem, was Ihr VPN-Anbieter dokumentiert.
2. ipleak.net — zeigt gleichzeitig IP, DNS-Resolver und WebRTC-Kandidaten auf einer Seite. Nützlich für einen schnellen kanalübergreifenden Schnappschuss, aber weniger granular als ein dedizierter DNS-Test.
3. Cloudflare 1.1.1.1/help — zeigt, welchen Resolver der aktuelle DNS-Stack Ihres Browsers verwendet, einschließlich ob DoH aktiv ist und auf Cloudflares Endpunkt zeigt. Nützlich zur Überprüfung der browserseitigen DNS-Konfiguration unabhängig vom Betriebssystem.

Protokollunterscheidung ist wichtig: einfache UDP/53-Anfragen sind unverschlüsselt und an jedem Netzwerkknoten abfangbar. DNS-over-TLS (RFC 7858) verschlüsselt Anfragen an den Resolver, aber der Resolver sieht immer noch alle Anfragen im Klartext. DNS-over-HTTPS (RFC 8484) umschließt Anfragen in HTTPS, wodurch sie wie regulärer Webverkehr aussehen und Abfangversuche an Zwischenknoten widerstehen. Weder DoT noch DoH verhindern, dass der Resolver selbst Anfragen protokolliert.

Für einen tiefen technischen Vergleich von DoH-Implementierungen über Browser und Betriebssysteme hinweg, siehe unsere DNS-over-HTTPS Implementierungen 2026 Analyse.

3. WebRTC-Lecks — STUN, ICE und JavaScript-Exposition

WebRTC (Web Real-Time Communication) ist eine Browser-API, die Peer-to-Peer-Audio-, Video- und Datenkanäle ermöglicht. Der Verbindungsaufbauprozess verwendet ICE (Interactive Connectivity Establishment), das wiederum das im RFC 5389 definierte STUN-Protokoll verwendet.

Wie STUN IP-Adressen offenlegt:

Wenn ein Browser eine RTCPeerConnection erstellt, beginnt er mit dem Sammeln von ICE-Kandidaten — einer Liste von Netzwerkadressen, über die er Peer-Verbindungen empfangen kann. Der Sammelprozess umfasst:

1. Host-Kandidaten: lokale Schnittstellen-IP-Adressen (LAN-IPs, Loopback), die direkt aus dem OS-Netzwerk-Stack gesammelt werden.
2. Server-reflexive Kandidaten: die öffentliche IP, wie sie von einem STUN-Server gesehen wird. Der Browser sendet eine UDP-Bindungsanfrage an einen STUN-Server; der Server antwortet mit der Quell-IP und dem Port des Clients (das Mapped Address-Attribut in der STUN-Antwort). Dies ist die externe IP — die, die Ihr Router-NAT dem Internet aussetzt.
3. Relay-Kandidaten: TURN-Server-Adressen, die verwendet werden, wenn direkte Konnektivität fehlschlägt.

Das kritische Problem ist, dass diese Sammlung synchron erfolgt, wenn RTCPeerConnection instanziiert wird, bevor irgendeine Benutzerinteraktion oder Berechtigungserteilung erfolgt. Ein Skript kann ausführen:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

Dies gibt alle gesammelten Kandidaten in der Konsole aus — oder an einen entfernten Server, wenn der Callback sie über fetch sendet. Keine Kameraberechtigung. Keine Mikrofonberechtigung. Keine Benutzerwarnung.

Browser-Minderungen:

• Firefox: media.peerconnection.enabled in about:config auf false gesetzt, deaktiviert WebRTC vollständig. Dies verhindert alle Lecks, bricht aber auch jede WebRTC-basierte Anwendung. Ein gezielterer Ansatz: media.peerconnection.ice.default_address_only auf true gesetzt, beschränkt die ICE-Sammlung auf die Standardschnittstelle und verhindert die Exposition lokaler LAN-IPs, während WebRTC funktionsfähig bleibt.
• Chrome/Chromium: Das Legacy-Flag chrome://flags/#enable-webrtc-hide-local-ips-with-mdns ersetzt lokale IPs durch mDNS-Hostnamen (z.B. a1b2c3d4.local) in ICE-Kandidaten, wodurch JavaScript daran gehindert wird, die tatsächliche LAN-Adresse zu lesen. Dies ist jetzt das Standardverhalten in Chrome 75+. Server-reflexive Kandidaten (öffentliche IP) werden jedoch weiterhin offengelegt, wenn ein STUN-Server konfiguriert ist.
• Brave: Braves Fingerabdruckschutz auf "Standard"-Niveau blockiert WebRTC-Lecks über Websites hinweg. Auf "Streng"-Niveau wird WebRTC für Drittanbieter-Frames vollständig deaktiviert, was Analytik- und Werbenetzwerk-STUN-Proben verhindert, während erstklassiges WebRTC (z.B. Videokonferenzen auf meet.example.com) im Hauptframe erlaubt bleibt.
• uBlock Origin: Die Einstellung "Verhindern, dass WebRTC lokale IP-Adressen leakt" im Dashboard von uBlock Origin (unter dem Reiter Datenschutz) fängt die Konstruktion von RTCPeerConnection ab und überschreibt die ICE-Konfiguration, um die Nutzung von STUN-Servern durch Drittanbieter-Skripte zu verhindern.

Testen von WebRTC-Lecks:

browserleaks.com/webrtc führt eine vollständige ICE-Sammlung durch und zeigt alle gesammelten Kandidaten an, einschließlich lokaler Adressen, server-reflexiver Adressen und der öffentlichen IP, die von ihrem STUN-Server gesehen wird. Vergleichen Sie die angezeigte öffentliche IP mit Ihrer VPN-Exit-IP. Eine Diskrepanz — insbesondere wenn die geleakte IP im ASN Ihres ISPs liegt — bestätigt ein WebRTC-Leck.

Für Informationen darüber, wie WebRTC und Fingerprinting-Vektoren interagieren, siehe unsere Privacy Browsers 2026 vergleichende Analyse.

4. IPv6-Lecks — Dual-Stack-Fehler und VPN-Blindstellen

Die IPv6-Adoption erreichte laut APNIC-Statistiken bis Ende 2025 etwa 45% des globalen Internetverkehrs. Die meisten privaten ISPs in Nordamerika, Westeuropa und großen asiatischen Märkten stellen jetzt standardmäßig Dual-Stack-Verbindungen bereit — was bedeutet, dass Ihr Router und Ihre Geräte sowohl IPv4- als auch IPv6-Globale-Adressen erhalten.

Wie IPv6-Lecks passieren:

Ein VPN erstellt eine Tunnel-Schnittstelle. Historisch gesehen haben die meisten Consumer-VPN-Implementierungen einen IPv4-Tunnel (tun0 oder ähnlich) erstellt, ohne einen IPv6-Tunnel bereitzustellen. Wenn Sie sich mit einem Dual-Stack-Server verbinden, wählt das Betriebssystem zwischen IPv4- und IPv6-Routen. Wenn IPv6 nativ erreichbar ist (über das native IPv6-Präfix Ihres ISPs) und es keine VPN-Route für IPv6 gibt, sendet das Betriebssystem IPv6-Pakete direkt über die native Schnittstelle — und umgeht das VPN vollständig.

Das Ergebnis: Ihr IPv6-Verkehr offenbart Ihre vom ISP zugewiesene globale IPv6-Adresse, die sowohl einzigartig als auch persistent ist (ISPs weisen typischerweise stabile Präfixe an Privatkunden zu). Diese Adresse ist mit Ihrem Konto, Ihrem Haushalt und Ihren Abrechnungsinformationen auf ISP-Ebene verknüpft.

Konfigurationen, die IPv6-Lecks erzeugen:

• VPN-Clients, die nur IPv4-Tunnel erstellen und IPv6 nicht blockieren oder routen
• Split-Tunnel-VPN-Konfigurationen, die nur bestimmte IPv4-Subnetze durch den Tunnel leiten
• VPN-Protokolle (insbesondere ältere IKEv2-Konfigurationen), die ohne IPv6-Policy-Routing-Regeln bereitgestellt werden
• Mobile Geräte, die IPv6-Adressen über SLAAC nach der VPN-Verbindung und vor der Aktualisierung der Routing durch den VPN-Client erwerben

Testen von IPv6-Lecks:

1. ipv6-test.com — zeigt Ihre aktuelle IPv6-Adresse und das Präfix, wenn erreichbar. Wenn die angezeigte Adresse im Präfix Ihres ISPs liegt (nicht im Präfix Ihres VPN-Anbieters), haben Sie ein IPv6-Leck.
2. test-ipv6.com — führt eine Reihe von Tests durch, einschließlich IPv6-Erreichbarkeit, DNS-via-IPv6 und Fallback-Verhalten. Der "IPv6 ohne DNS"-Test ist besonders nützlich, um Transportlecks von Resolver-Lecks zu isolieren.
3. ipleak.net — zeigt die IPv6-Adresse neben IPv4 und DNS an, was den Vergleich aller drei in einer Ansicht ermöglicht.

Minderungen:

• Verwenden Sie einen VPN-Client, der entweder IPv6 innerhalb des Tunnels routet oder IPv6 auf allen Schnittstellen deaktiviert, während der Tunnel aktiv ist (letzteres ist die häufigere Implementierung)
• Unter Linux können Sie IPv6 explizit mit sysctl -w net.ipv6.conf.all.disable_ipv6=1 deaktivieren, bevor Sie sich verbinden; besser, dies in den Up/Down-Skripten des VPN-Clients zu konfigurieren
• Unter Windows, Netzwerkadapter → Eigenschaften → "Internetprotokoll Version 6" pro Adapter deaktivieren, oder die VPN-Adapterbindung so konfigurieren, dass beide Stacks behandelt werden
• Überprüfen Sie, ob die IPv6-Handhabung in der Wissensdatenbank Ihres VPN-Anbieters dokumentiert ist; das Fehlen von Dokumentation ist selbst ein Signal

Wie führt man einen vollständigen VPN-Lecktest durch?

Ein zuverlässiger VPN-Lecktest erfordert fünf Schritte:

1. Basislinie — dokumentieren Sie die DNS-Resolver und öffentlichen IPs Ihres ISPs, bevor Sie sich mit dem VPN verbinden
2. Post-Connection-Test — führen Sie dnsleaktest.com (erweitert), browserleaks.com/webrtc und ipv6-test.com nach der Verbindung und dem Warten von 30 Sekunden aus
3. Kill-Switch-Test — trennen Sie das VPN abrupt, während ein kontinuierlicher DNS-Test läuft; Anfragen müssen stoppen, nicht auf den ISP zurückfallen
4. Sandboxed-Browser-Test — wiederholen Sie den Test in einem sauberen Browser-Profil ohne Erweiterungen, um das rohe Browser-Verhalten zu enthüllen
5. Browser-DoH-Test — aktivieren Sie browserseitiges DoH mit einem öffentlichen Resolver; wenn der angezeigte DNS-Resolver sich von dem Ihres VPNs ändert, umgeht browserseitiges DoH Ihren Tunnel

Reproduzierbares Testprotokoll

Ein einmaliger Test bei der VPN-Einrichtung ist unzureichend. Der Netzwerkzustand ändert sich bei Schlafen/Wachen, DHCP-Erneuerung, Captive-Portal-Authentifizierung und OS-Updates. Das folgende Protokoll erstellt eine Basislinie und deckt Zustandsübergänge ab.

Einrichtung: Definieren Sie Ihre Basislinie

Vor jeder VPN-Verbindung dokumentieren Sie:

• Die DNS-Resolver-IP(s) Ihres ISPs von nslookup -type=ns google.com oder dig @8.8.8.8 google.com
• Ihre öffentliche IPv4 von einem einfachen HTTP-Endpunkt (curl http://ipinfo.io/ip)
• Ihre öffentliche IPv6, falls vorhanden (curl -6 http://ipv6.icanhazip.com)
• Den DNS-Resolver Ihres Browsers von Cloudflare 1.1.1.1/help

Schritt 1: Pre-VPN-Schnappschuss

Mit getrenntem VPN führen Sie alle vier Test-Tools aus und zeichnen auf:

• Die auf dnsleaktest.com (erweiterter Test) angezeigten DNS-Resolver
• WebRTC-Kandidaten auf browserleaks.com/webrtc
• IPv4- und IPv6-Adressen auf ipv6-test.com
• Browser-DNS auf 1.1.1.1/help

Schritt 2: Post-VPN-Verbindungstest

Verbinden Sie das VPN. Warten Sie 30 Sekunden, bis sich die Routing-Tabellen stabilisieren. Wiederholen Sie alle vier Tests. Erwartete Ergebnisse, wenn das VPN korrekt konfiguriert ist:

• DNS-Resolver sollten im ASN des VPN-Anbieters oder einem vertrauenswürdigen Resolver (Cloudflare, Mullvads eigener Resolver) sein
• WebRTC server-reflexive Kandidaten sollten nur die VPN-Exit-IP anzeigen
• IPv6 sollte entweder die IPv6-Exit des VPNs anzeigen oder "keine IPv6-Konnektivität" anzeigen (beides ist akzeptabel, wenn das VPN kein IPv6 bereitstellt)
• Browser-DNS sollte den vom VPN konfigurierten Resolver verwenden

Schritt 3: Kill-Switch-Test

Mit aktivem VPN und einem geöffneten Browser-Tab, der kontinuierliche DNS-Anfragen ausführt (dnsleaktest.com erweiterter Test in Wiederholung), trennen Sie den VPN-Client abrupt — nicht über die sanfte Trennen-Schaltfläche, sondern indem Sie den VPN-Adapter deaktivieren oder ihn auf Firewall-Ebene blockieren. Innerhalb von 5 Sekunden: DNS-Anfragen sollten stoppen, nicht auf den ISP-Resolver zurückfallen. Wenn ein Fallback auftritt, erzwingt der Kill-Switch nicht.

Schritt 4: Sandboxed-Browser-Test

Wiederholen Sie den Test in einem Browser-Profil ohne Erweiterungen und mit Standardeinstellungen. Erweiterungen wie uBlock Origin maskieren WebRTC- und DNS-Verhalten, das im Basisbrowser vorhanden sein kann. Das Testen des rohen Browsers zeigt, was ein Benutzer ohne schützende Erweiterungen bei derselben VPN-Einrichtung ausgesetzt ist.

Schritt 5: Browser-isolierter DoH-Test

Aktivieren Sie das eingebaute DoH des Browsers (in Firefox: Einstellungen → Datenschutz & Sicherheit → DNS über HTTPS, auf Maximaler Schutz mit einem öffentlichen Resolver setzen). Führen Sie dnsleaktest.com erneut aus. Wenn der angezeigte Resolver sich von dem Ihres VPNs zu Cloudflare oder einem anderen öffentlichen Resolver ändert, umgeht browserseitiges DoH Ihr VPN-DNS.

6. Werkzeugvergleich

Die folgende Tabelle deckt Werkzeuge ab, die im Jahr 2026 häufig zur Netzwerk-Lecksuche verwendet werden. "Erkannt" bedeutet, dass das Werkzeug aktiv auf diesen Lecktyp testet. "Übersehen" bedeutet, dass das Werkzeug nicht testet oder unvollständige Abdeckung bietet.

Kein einzelnes Werkzeug ersetzt das vollständige Protokoll. Führen Sie alle fünf für ein vollständiges Bild aus.

7. Entscheidungsmatrix nach Benutzerprofil

Für eine kuratierte Bewertung von VPN-Clients nach Zuverlässigkeit des Kill-Switches und IPv6-Handhabung, siehe die Best VPN for Tech-Aware Users 2026 Analyse.

Protokoll validiert gegen 12 VPN-Clients auf Linux (Debian 12, Ubuntu 24.04), macOS 15.4 und Windows 11 24H2. Tests durchgeführt im Juni 2026. Werkzeugabdeckung manuell überprüft; Werkzeugverhalten kann sich ohne Vorankündigung ändern — überprüfen Sie zum Testzeitpunkt erneut.

Verwandte Lektüre

• State of Browser Privacy 2026
• DNS-over-HTTPS Implementierungen 2026
• Privacy Browsers 2026
• Best VPN for Tech-Aware Users 2026
• Browser-Fingerabdruck-Test — messen Sie Ihre Canvas- & WebGL-Exposition
• HTTP-Sicherheitsheader-Checker — überprüfen Sie die Antwortheader Ihres Servers