Wenn Sie eine IP-Abfrageseite öffnen und die Adresse bereits dem erwarteten Ausgang entspricht, liegt der Schluss nahe, dass alle Einstellungen wirksam sind. Tatsächlich zeigt dies nur, dass diese eine Webanfrage diese Adresse verwendet hat. Domainauflösung, WebRTC-Kommunikation und IPv6-Anfragen müssen nicht unbedingt denselben Pfad nehmen.
Ob ein IP- oder DNS-Leck vorliegt, entscheidet sich nicht daran, „wie viele Adressen auf der Seite erscheinen“, sondern ob Informationen oder Verkehr den beabsichtigten Schutzpfad verlassen. Interne Adressen, öffentliche DNS-Server oder vom Ausgang abweichende Ortsnamen sind für sich genommen noch kein Lecknachweis.
Dieser Artikel eignet sich zur Prüfung der eigenen Geräte, Browser und Netzwerkeinstellungen. Die Testergebnisse spiegeln nur die aktuell beobachtbare Umgebung wider und sind keine Datenschutzgarantie für alle Anwendungen auf dem Gerät.
Bestimmen Sie zuerst, welcher Verkehr geschützt werden soll
Beantworten Sie vor dem Test eine einfache Frage: Haben Sie einen Browser-Proxy, einen System-Proxy oder ein VPN konfiguriert, das den Netzwerkverkehr übernimmt?
Ihre Abdeckungsbereiche können unterschiedlich sein. Browsererweiterungen behandeln nicht zwangsläufig andere Anwendungen; ein System-Proxy bedeutet auch nicht, dass jedes Protokoll die Proxy-Einstellungen befolgt. Ob ein VPN IPv6, DNS und geteilten Verkehr abdeckt, hängt ebenfalls von der konkreten Implementierung und Konfiguration ab.
Wenn Sie eine Anwendung bewusst direkt verbinden lassen, ist es nicht unbedingt ein Fehler, wenn sie den bisherigen Ausgang nutzt. Erwarten Sie jedoch, dass „der gesamte ausgehende Verkehr den festgelegten Ausgang verwendet“, ist dasselbe Phänomen weiter zu untersuchen.
Es empfiehlt sich, eine Ausgangsbasis zu speichern: die öffentliche IPv4, IPv6 sowie die in der DNS-Prüfung sichtbaren Resolver ohne die Zielkonfiguration. Die Ausgangsbasis dient dem Vorher-Nachher-Vergleich und muss nicht veröffentlicht werden; besonders in Unternehmensnetzen sollten interne Adressen und Konfigurations-Screenshots nicht unbedacht preisgegeben werden.
WebRTC: Erst Kandidatenadressen unterscheiden, dann Ausgangsexposition beurteilen
WebRTC ermöglicht Browsern Echtzeit-Audio-, Video- und Datenkommunikation. Zum Verbindungsaufbau sammelt es mögliche Netzwerkpfade, die sogenannten ICE-Kandidaten.
Die MDN-Erläuterung der Kandidatentypen unterscheidet unter anderem host, srflx, prflx und relay. Für normale Nutzer ist vor allem wichtig, lokale Schnittstelleninformationen, durch Adressumsetzung beobachtete Informationen und Relais-Server-Adressen auseinanderzuhalten. Ob Kandidaten einer Webseite offengelegt werden, hängt auch von der WebRTC-Datenschutzrichtlinie des Browsers ab.
Im Test angezeigtes Ergebnis | Sinnvollere Deutung |
|---|---|
192.168.x.x, 10.x.x.x und ähnliche private IPv4-Adressen | Kann auf lokale Netzwerkinformationen hinweisen, lässt aber allein keinen Rückschluss auf ein Leck des öffentlichen Ausgangs zu |
.local-Namen | Möglicherweise Datenschutzbehandlung lokaler Kandidaten durch den Browser, nicht gleichbedeutend mit der echten öffentlichen IP |
Öffentliche Adresse, die dem erwarteten Ausgang entspricht | Passt zur Erwartung dieses Tests, bedeutet aber nicht, dass der gesamte Verkehr verifiziert wurde |
Bestätigte öffentliche Adresse des bisherigen Netzes | Wenn sie geschützt sein sollte, ein wichtiges Expositionssignal, das genauer zu prüfen ist |
TURN-Relais-Adresse | Zeigt an, dass der betreffende Kandidat über ein Relais läuft, ist aber kein direkter Beleg für die ursprüngliche öffentliche Adresse des Nutzers |
Dass WebRTC Adressen des bisherigen Netzes offenlegt, ist nicht rein hypothetisch. RFC 8828 behandelt die Offenlegung von IP-Informationen bei geteiltem VPN, mehreren Netzwerkschnittstellen und Anwendungs-Proxys. Die tatsächliche Wirkung hängt jedoch von Browser-Implementierung, Berechtigungen und Netzwerkrichtlinien ab; Testergebnisse alter Browser lassen sich nicht einfach auf alle Geräte übertragen.
Bei der WebRTC-Leak-Test gilt: Wenn Sie eine unerwartete öffentliche Adresse sehen, vergleichen Sie zuerst mit dem Ausgangswert und prüfen Sie dann, zu welchem Netz sie gehört. Schließen Sie nicht allein daraus, dass „eine zweite Adresse angezeigt wird“, und betrachten Sie „keine Kandidaten gesammelt“ nicht automatisch als absolute Sicherheit – blockierte Kommunikation oder ein unvollständiger Test können ebenfalls zu leeren Ergebnissen führen.
DNS: Was bedeutet es, wenn man den Resolver des Netzbetreibers sieht?
Bevor ein Browser eine Domain aufruft, benötigt er in der Regel zuerst die zugehörige Adresse. Bei DNS-Lecks geht es darum, ob dieser Schritt gemäß der vorgesehenen Auflösungsstrategie ausgeführt wird und ob eine Partei, die die Anfrageinformationen nicht erhalten sollte, möglicherweise Zugriff darauf hat.
Typische DNS-Lecktests lassen den Browser eine Reihe von Testdomains anfordern und beobachten dann die Herkunft der Anfragen auf der autoritativen DNS-Seite. Die Seite zeigt in der Regel den Ausgangspunkt in der rekursiven Auflösungskette, nicht eine direkte Auslesung der DNS-Konfiguration Ihres Geräts.
Das bedeutet: Nachdem eine DNS-Adresse erkannt wurde, kann man nicht sofort folgern, dass „der lokale DNS-Server genau dieser ist“. Rekursive Weiterleitung, öffentliche Auflösungsdienste und Anycast-Bereitstellungen können das Ergebnis komplexer machen als die Systemeinstellungen.
Schauen Sie insbesondere nicht nur auf den Ländernamen: Die Datenbankverortung des DNS-Ausgangs unterscheidet sich vom Web-Ausgang und reicht allein nicht aus, um ein Leck nachzuweisen. Prüfen Sie zusätzlich den Betreiber des Resolvers, die Routing-Methode des Dienstes und ob dies Ihrem Konfigurationsziel entspricht.
Wenn Sie ausschließlich den vom VPN vorgegebenen Auflösungspfad nutzen möchten, der Test aber dauerhaft den Auflösungsausgang des ursprünglichen Netzbetreibers beobachtet, ist das ein Signal, das untersucht werden muss. Wenn Sie aktiv einen öffentlichen DNS-Dienst konfiguriert haben, ist dessen Erkennung an sich nicht unbedingt eine Anomalie.
Sie können die DNS-Leak-Test für Vorher-Nachher-Vergleiche nutzen. Wenn mehrere Resolver auftauchen, prüfen Sie zuerst, ob zwischen „Sicheres DNS“ des Browsers, Betriebssystem-DNS, VPN-DNS und Split-Tunneling-Einstellungen Überlagerungen oder parallele Nutzung bestehen.
Bedeutet aktiviertes DoH, dass keine Lecks mehr auftreten?
DoH löst das Problem der Transportverschlüsselung von DNS-Abfragen, aber nicht automatisch alle Routing- und Vertrauensfragen. Die Ausführungen von Cloudflare beschreiben, wie DNS-Abfragen in HTTPS gekapselt werden, doch „verschlüsselter Transport“ bedeutet nicht, dass „die Abfrage sicher über Ihr festgelegtes VPN läuft“.
Der Auflösungsdienst verarbeitet Ihre Abfragen weiterhin. Manche Bereitstellungen können zudem EDNS Client Subnet verwenden und bei rekursiven Abfragen Präfixinformationen des Client-Netzwerks übertragen; dieser Mechanismus und seine Auswirkungen auf die Privatsphäre sind in RFC 7871 beschrieben. Wenn ein gewöhnlicher DNS-Test dieses Ergebnis nicht ausdrücklich ausweist, sollten Sie nicht annehmen, dass ECS bereits geprüft wurde.
IPv6: Ein korrekter IPv4-Ausgang bedeutet nicht, dass auch die andere Adressfamilie korrekt ist
Viele Netze bieten gleichzeitig IPv4 und IPv6 an. Wenn ein Proxy oder VPN nur IPv4 verarbeitet, das Gerät aber weiterhin direkt über das ursprüngliche Netz IPv6 nutzen kann, können IPv6-fähige Zieldienste einen anderen Ausgangspfad beobachten.
Allerdings ist es normal, dass sich IPv4- und IPv6-Adressen unterscheiden. Sie gehören zu verschiedenen Adresssystemen, und man kann nicht anhand der Ähnlichkeit der Adresszeichenfolgen beurteilen, ob der Schutz wirksam ist.
Verglichen werden sollten: die Netzzugehörigkeit beider Protokolle, ob das tatsächliche Routing den Erwartungen entspricht und ob IPv6 weiterhin auf das ursprüngliche Netz zeigt. Auch die Änderung temporärer IPv6-Adressen zeigt nicht automatisch ein Leck an.
Prüfen Sie in der Browserumgebung prüfen die verfügbaren IPv4- und IPv6-Informationen getrennt. Wenn der IPv6-Test nicht abgeschlossen wurde, kann er nur als unbestätigt markiert werden; das ist nicht gleichbedeutend mit „bestätigt nicht verfügbares IPv6“.
Eine wiederholbare Prüfreihenfolge
1. Vorher-Nachher-Vergleich auf demselben Gerät und im selben Browser
Notieren Sie die Ausgangsinformationen ohne die Zielkonfiguration und führen Sie den Test nach Aktivierung der Konfiguration erneut durch. Vermeiden Sie es, während des Tests gleichzeitig WLAN, Browser-Proxy und DNS zu wechseln, sonst lässt sich schwer feststellen, welcher Schritt die Änderung verursacht hat.
2. Web, WebRTC, DNS und IPv6 getrennt prüfen
Halten Sie die vier Ergebnisgruppen getrennt fest: den im Web beobachteten öffentlichen Ausgang, die WebRTC-Kandidaten, die Herkunft der DNS-Abfragen sowie IPv6-Erreichbarkeit und -Ausgang. Ersetzen Sie die anderen Punkte nicht durch den grünen Status eines einzelnen Ergebnisses.
3. Einstellungen entlang abnormaler Pfade lokalisieren
Wenn WebRTC die öffentliche Adresse des ursprünglichen Netzes preisgibt, prüfen Sie die Proxy-Abdeckung, die WebRTC-Richtlinie und ob das VPN Split-Tunneling verwendet. Wenn DNS nicht den Erwartungen entspricht, prüfen Sie die Auflösungseinstellungen von Browser und System sowie das DNS-Verhalten nach VPN-Trennung. Wenn IPv6 weiterhin über das ursprüngliche Netz läuft, prüfen Sie die IPv6-Unterstützung des VPN und die zugehörigen Routen.
Ändern Sie jeweils nur eine relevante Option und testen Sie erneut. Wenn Sie längerfristige Betriebsprobleme behandeln müssen, sind Zeitangaben, Konfigurationsstatus und Ergebniszusammenfassungen in der Regel hilfreicher für die Eingrenzung als nur ein Screenshot mit „roter Warnung“.
4. Verhalten nach erneuter Verbindung prüfen
Netzwerkwechsel, Aufwachen des Geräts aus dem Ruhezustand und erneute VPN-Verbindungen können den Pfad verändern. Führen Sie die Prüfung nach diesen normalen Nutzungsszenarien erneut durch, wenn möglich. Ein einmalig bestandener Test beweist nur, dass das beobachtete Verhalten zu diesem Zeitpunkt den Erwartungen entsprach, und ersetzt keine spätere Stabilitätsprüfung.
Nicht sofort alle Funktionen deaktivieren
WebRTC direkt zu deaktivieren, kann Anrufe und Konferenzen im Browser beeinträchtigen; IPv6 direkt zu deaktivieren, kann Konfigurationsprobleme verschleiern. Ob Sie dies tun, sollte von Ihrem tatsächlichen Bedarf und dem akzeptablen Funktionsverlust abhängen und nicht nur davon, dass die Testseite weniger Zeilen anzeigt.
Sinnvoller ist es, zuerst den Schutzbereich zu klären und dann die entsprechenden Routing-, Auflösungs- oder Browsereinstellungen zu korrigieren. Unternehmensgeräte sollten außerdem den Richtlinien der Administratoren folgen und bestehende Netzwerk- und Sicherheitskonfigurationen nicht eigenmächtig umgehen.
Kann ein Inkognito-Fenster diese Lecks verhindern?
Der Inkognito-Modus ist kein Netztunnel. Er ändert hauptsächlich die lokale Verarbeitung von Browserverlauf, Cookies und anderen Sitzungsdaten und übernimmt nicht automatisch DNS, WebRTC oder IPv6-Routing.
Bedeutet die Nichterkennbarkeit der ursprünglichen IP-Adresse vollständige Anonymität?
Nein. Der IP-Pfad ist nur ein Teil der Privatsphäre. Kontoanmeldung, Cookies, Browser-Fingerprinting und aktiv übermittelte Informationen können es einem Dienst ermöglichen, einen Besuch zu identifizieren oder zuzuordnen.
Nach Abschluss dieser Prüfungen sollte die vernünftige Schlussfolgerung lauten: „Unter den aktuellen Konfigurations- und Testbedingungen entspricht der beobachtete Netzwerkpfad den Erwartungen.“ Dies ist genauer und für die weitere Nutzung hilfreicher als ein pauschales „Null Leaks, vollständig anonym“ ohne Anwendungsbereich.
Split-Tunneling-Szenario: Wie sind vier unterschiedliche Ergebnisse auf demselben Gerät zu interpretieren?
Angenommen, Sie haben Routing nach Domains konfiguriert oder betreiben gleichzeitig VPN und direkten lokalen Ausgang. Bei einer Messung zeigt der HTTP-Ausgang die Adresse des Proxy-Knotens A, die DNS-Prüfung die Adresse des rekursiven Servers B, in den WebRTC-Kandidaten erscheinen die öffentliche Adresse C des ursprünglichen Netzwerks und eine TURN-Adresse D, und IPv6 läuft weiterhin über die Leitung des Netzbetreibers. Solche Ergebnisse werden leicht als „vierfaches Leck“ fehlinterpretiert. Tatsächlich können es einfach unterschiedliche Pfade sein. Entscheidend ist nicht die Anzahl der IP-Adressen, sondern ob diese Pfade Ihren Erwartungen entsprechen.
Wenn in diesem Beispiel nur der HTTP-Verkehr der Webseite über den Proxy laufen soll, könnte Ausgang A der Konfiguration entsprechen; ob DNS direkt verbindet, muss separat bestätigt werden. Wenn in den für die Webseite lesbaren WebRTC-Kandidaten die öffentliche Adresse C des ursprünglichen Netzwerks erscheint, zeigt dies bereits, dass die Seite bei diesem Test C erfahren kann – es ist nicht erforderlich, dass die Medienverbindung die Adresse tatsächlich nutzt, um sie als exponiert zu betrachten. Ob es sich um ein unerwünschtes Leck handelt, hängt davon ab, ob Sie verlangen, diese Adresse vor der Seite zu verbergen.
Insbesondere mDNS-Kandidaten müssen genau unterschieden werden. Browser verwenden häufig zufällig generierte .local-Namen für lokale Netzwerkschnittstellen, um die direkte Offenlegung echter LAN-Informationen zu vermeiden. Ein Eintrag wie „2f8c…local“ in einer WebRTC-Prüfseite ist als Datenschutzbehandlung lokaler Kandidaten zu verstehen, nicht als Ihre öffentliche IP oder Ihr Hostname. Ihn als Leck-Beweis zu werten, ist ein häufiger Fehlschluss. Nur wenn zugleich die öffentliche Adresse des ursprünglichen Netzwerks vorhanden ist und die Anwendung eigentlich durch den Tunnel geschützt sein sollte, handelt es sich um ein ernst zu nehmendes Expositionssignal.
Erfassen Sie die IPv6-Ergebnisse getrennt. Wenn IPv4 über Proxy A läuft, IPv6 aber weiterhin direkt über den Netzbetreiber, kann eine Website mit Dual-Stack-Unterstützung parallel oder bevorzugt die IPv6-Adresse Ihres Anschlusses sehen. Das muss kein Konfigurationsfehler sein: Viele Clients, die den Datenverkehr anhand von CIDR-Präfixen aufteilen oder nur IPv4 über einen Proxy leiten, übernehmen standardmäßig nicht das IPv6-Routing. Bevor Sie von einem „IPv6-Leck“ sprechen, prüfen Sie, ob der VPN- oder Proxy-Dienst IPv6 abdeckt und ob die lokale IPv6-Standardroute in den Tunnel führt.
Unterschiede bei rekursiven DNS-Servern lassen sich mit Hilfe von ASN- und RDAP-Informationen besser beurteilen. Gehört die Adresse von B zu einem von Ihnen aktiv gewählten öffentlichen Auflösungsdienst, ist es normal, dass sie vom HTTP-Ausgang abweicht; gehört sie zum ursprünglichen Netzbetreiber und Sie wollten den Auflösungsverkehr durch den Tunnel führen, liegt eine zu untersuchende Anomalie vor. Anycast-Dienste können in verschiedenen Regionen unterschiedliche Knoten anzeigen, daher darf nicht allein aus geografischen Abweichungen auf direkte DNS-Verbindung geschlossen werden. Achten Sie auf Betreibername, ASN-Zuordnung und darauf, ob auf der autoritativen Seite für die Testdomain unerwartete Abfragequellen beobachtet werden.
Beim gleichzeitigen Bestehen mehrerer Ausgänge ist der erste Schritt nicht das Abschalten von Funktionen, sondern das schriftliche Festhalten Ihrer Erwartungen. Welche Anwendungen sollen über den Proxy laufen, welche direkt? Wer soll DNS verarbeiten? Soll IPv6 durch den Tunnel abgedeckt oder direkt erlaubt sein? Dürfen bei VPN-Verbindung lokale WebRTC-Kandidaten gesammelt werden? Nach einer Messung vergleichen Sie mit dieser Basis. Weicht ein Punkt ab, passen Sie die entsprechenden Einstellungen schrittweise an. Ändern Sie jeweils nur eine Variable – zum Beispiel zuerst DNS – und wiederholen Sie die Messung, um festzustellen, welche Regel die Abweichung verursacht.
Wiederholte Messungen und Wiederherstellung nach Verbindungsabbrüchen: Ergebnisse belastbar machen
Eine bestandene Einzelmessung zeigt nur, dass die Umgebung zu diesem Zeitpunkt den Erwartungen entsprach. VPN-Neuverbindung, Systemaufwachen oder geänderte Browserberechtigungen können den Pfad verändern. Wiederholen Sie Messungen nach normalen Nutzungsszenarien: Trennen und verbinden Sie das VPN erneut, testen Sie nach Ruhezustand und Aufwachen sowie nach Wechsel zwischen WLAN und Mobilfunk, und prüfen Sie jeweils HTTP-Ausgang, DNS-Quelle, WebRTC-Kandidaten und IPv6-Status. Die Stabilität dieser vier Ergebnisse ist aussagekräftiger als ein einmaliger „Alles grün“-Befund.
Lassen Sie bei jeder Messung nur eine Variable variieren. Wenn Sie heute nur WebRTC-Einstellungen ändern, halten Sie DNS- und VPN-Konfiguration unverändert; ändern Sie morgen nur IPv6, messen Sie alle vier Punkte erneut. Werden gleichzeitig „Sicheres DNS“ im Browser, Proxy-Split-Tunneling und der System-IPv6-Schalter angepasst, lässt sich bei schwankendem Verhalten kaum zurückverfolgen, welche Änderung die Ursache war. Zeitstempel, Konfigurationsstatus und Ergebniszusammenfassung sind für die langfristige Wartung nützlicher als ein Screenshot mit roter Warnung.
Browserberechtigungen beeinflussen die WebRTC-Kandidaten direkt. Ohne Mikrofon- oder Kameraberechtigung sammelt der Browser möglicherweise keine lokalen Schnittstellenkandidaten; nach Autorisierung von Audio/Video kann sich der Erfassungsumfang erweitern. Testen Sie WebRTC daher vor und nach der Berechtigungserteilung, um Änderungen der Kandidatenliste zu beobachten. Schließen Sie nicht aus dem Fehlen von Kandidaten ohne Berechtigung, dass kein WebRTC-Expositionsweg besteht – das verwechselt „nicht gemessen“ mit „geschützt“. Ebenso ändert ein Inkognito-Fenster das Netzwerk-Routing nicht und ist keine Leck-Schutzmaßnahme.
IPv6 sollte bedarfsgerecht behandelt werden: Wenn vollständiger Dual-Stack-Schutz erforderlich ist, wählen und konfigurieren Sie einen IPv6-fähigen Tunnel und prüfen Sie tatsächliches Routing und Firewall; unterstützt das Produkt nur IPv4, klären Sie, welche Blockier- oder Bypass-Strategie es für IPv6 hat. Eine einzelne Standardroute garantiert nicht, dass alle Anwendungen und der Zustand nach Verbindungsabbruch geschützt sind. Das globale Deaktivieren von IPv6 kann die Kompatibilität beeinträchtigen; verstehen Sie zuerst die Fähigkeiten des Clients, halten Sie eine wiederherstellbare Konfiguration bereit und prüfen Sie dann getrennt Normalbetrieb, Neuverbindung und Abbruchzustand.
Die Abnahme der Wiederherstellung nach Verbindungsabbruch sollte eine „Kill-Switch“-Strategie umfassen. Behauptet ein VPN, nach einem Abbruch jeglichen ausgehenden Verkehr zu blockieren, testen Sie, ob bei Netzwerkunterbrechung auch DNS-Abfragen fehlschlagen, statt auf den ursprünglichen Resolver zurückzufallen. Manche Implementierungen trennen nur IPv4-TCP, erlauben aber IPv6 oder DNS weiterhin über die ursprüngliche Leitung; solcher „Teilschutz“ hinterlässt Beobachtungsfenster. Bestätigen Sie dies, indem Sie gezielt Abbruchereignisse auslösen und das Verhalten von HTTP-, DNS- und IPv6-Anfragen beobachten.
„Kein Treffer“ in den Messergebnissen bedeutet nicht „sicher“. Wenn IPv6 wegen fehlender Netzwerkunterstützung als nicht verbindbar angezeigt wird, kann dies nur als „unbestätigt“ markiert werden, nicht als „bestätigt kein IPv6-Leck“. Ein Pfad gilt erst dann als in dieser Prüfung bestanden, wenn der Test durchgeführt wurde und das Ergebnis den Erwartungen entspricht. Jede Messung sollte die Testbedingungen angeben – etwa Browserversion, Proxy-Modus, VPN-Protokoll und Netzwerkumgebung –, um spätere Reproduzierbarkeit zu ermöglichen.
In komplexeren Umgebungen, etwa wenn CGNAT die Zuordnung zwischen öffentlichem Ausgang und interner Adresse verändern kann, hilft die Öffentliche IP und CGNAT erkennen: Router-WAN prüfen, die NAT-Ebene zu verstehen; und manche Sicherheitsprüfwerkzeuge melden normale Phänomene fälschlich als VPN- oder Proxy-Merkmale – hier gibt die IP als VPN oder Proxy erkannt: Fehlalarme überprüfen weitere Hinweise zur Interpretation der Werkzeugausgabe. Zusammen reduzieren diese Ressourcen Fehlbeurteilungen durch Adresstyp oder Erkennungslogik.
Abschließend fassen Sie die Prüfergebnisse zu einem Abnahmeprotokoll zusammen: Ist der erwartete Pfad eindeutig? Verhält sich jede Verkehrsart in den drei Zuständen Normalbetrieb, Wiederverbindung und Trennung wie erwartet? Sind Abweichungen konkreten Einstellungen zugeordnet? Die daraus abgeleitete Aussage – „Unter den aktuellen Bedingungen und im getesteten Umfang entspricht der beobachtete Netzwerkpfad den Erwartungen“ – ist wertvoller als jedes einmalige grüne Häkchen.
