Diese Seite vergleicht zwei Signale, die übereinstimmen sollten, wenn ein VPN tut, was Sie erwarten: die IPv4-Adresse, die mein HTTPS-Handler auf /api/ip sieht, und die öffentlichen server-reflexiven (srflx) Endpunkte, die Ihr Browser während eines kurzen WebRTC-ICE-Gatherings gegen Googles öffentlichen STUN-Pool (standardmäßig stun.l.google.com:19302) erfährt. Ich habe die doppelte Überprüfung hinzugefügt, nachdem ein Freund mit einem bekannten Verbraucher-VPN auf jeder „Wie ist meine IP“-Website London sah, aber in einem Videoanruf immer noch sein Heim-ASN preisgab, weil UDP zu STUN außerhalb des Tunnels austrat, während TCP zu Websites innerhalb blieb. Unten erkläre ich, wie das passiert, wie ein sauberes Ergebnis aussieht und warum kein Browser-Tab ein natives DNS-Leak-Harness vollständig ersetzen kann.
Was dieses Tool überprüft (und was es nicht beweisen kann)
Die Zeile HTTP-Baseline spiegelt die Client-Adresse wider, die Cloudflare an meinen Ursprung weiterleitet (über CF-Connecting-IP oder ein Äquivalent). Das ist die Adresse, die Abrechnungssysteme, Betrugsbewertungen und die meisten Websites bei normalen Seitenaufrufen über TLS beobachten. Die Liste WebRTC srflx sammelt IPv4-Adressen, die aus ICE-Kandidaten vom Typ srflx geparst wurden. Das bedeutet, dass der STUN-Server Ihr UDP-Paket von diesem öffentlichen Endpunkt empfangen hat. Wenn beide Pfade denselben VPN-Ausgang nutzen, sollten die Adressen innerhalb jeder IP-Versionsfamilie übereinstimmen.
Dies ist eine Heuristik, keine Zertifizierung. Malware, Split-Tunneling-Regeln, die nur bestimmte ausführbare Dateien auflisten, Captive-Portale oder reine IPv6-Leaks außerhalb des Tunnels können zu verwirrenden Grenzfällen führen, die die Benutzeroberfläche als uneindeutig anstelle von bestanden oder fehlgeschlagen kennzeichnet. Betrachten Sie die Ausgabe als Hausaufgabe: Wenn etwas nicht übereinstimmt, reproduzieren Sie dies mit dem nativen Tester Ihres VPN-Anbieters und einer Paketaufzeichnung, bevor Sie einen Fehlerbericht für das VPN einreichen.
Wie sich WebRTC-Leaks von normalen Seitenaufrufen unterscheiden
Die WebRTC-Verhandlung verwendet den in RFC 8445 definierten Interactive Connectivity Establishment (ICE)-Algorithmus. Ein Teil von ICE beinhaltet das Senden von in RFC 5389 definierten STUN-Bindungsanfragen, damit Endpunkte reflexive Adressen durch NAT lernen. Browser senden aus Datenschutzgründen auch mDNS-Hostnamen in lokalen Netzwerken; wenn diese aktiv sind, sehen Sie möglicherweise undurchsichtige .local-Namen, bis srflx-Kandidaten eintreffen. Wenn Ihr VPN den TCP-Webverkehr durch den Tunnel leitet, aber UDP aufgrund einer fehlenden Firewall-Regel auf den ISP zurückfallen lässt, kann srflx die ISP-Adresse offenlegen, während HTTPS immer noch das VPN anzeigt. Das ist das klassische WebRTC-Leak-Muster, vor dem Datenschutzhandbücher warnen.
Moderne Browser verschärfen weiterhin die Standardeinstellungen (stumme Schnittstellen, Erfordernis von Benutzergesten für den Kamerazugriff, Einschränkung von Host-Kandidaten), aber ICE selbst benötigt immer noch reflexive Daten, um zu funktionieren. Die Lösung ist selten, „WebRTC global zu deaktivieren“; sie besteht darin, UDP über dieselbe Schnittstelle wie TCP zu leiten oder einen VPN-Client zu verwenden, der einen Kernel-Treiber installiert, der alle IP-Protokolle erfasst.
DNS-Leaks: Warum der Browser nicht alles sehen kann
Ein DNS-Leak bedeutet, dass Abfragen für Domänennamen über einen Resolver aufgelöst werden, den Ihr VPN nicht vorgesehen hat, in der Regel Ihr ISP, während der getunnelte Verkehr weiterhin über die VPN-IP austritt. Die vollständige Erkennung verwendet oft eindeutige Subdomains, damit ein autoritativer Server protokollieren kann, welcher Resolver die Frage gestellt hat. Normales Same-Origin-JavaScript kann nicht jeden OS-Socket oder jede geteilte Konfiguration von systemd-resolved auflisten. Aus diesem Grund verweist diese Website Sie auf Wie ist mein DNS für gezielte DoH-Abfragen und auf native Leak-Tester für endgültige Antworten.
IPv6 erhöht den Einsatz: Wenn Ihr VPN nur IPv4 tunnelt, Ihr Betriebssystem jedoch für einige Ziele IPv6 bevorzugt, können AAAA-Abfragen und nachfolgende TCP-Verbindungen den Tunnel vollständig umgehen. Die Behebung besteht normalerweise darin, „IPv6 innerhalb des VPN zu aktivieren“ oder „IPv6 auf dem Client zu blockieren, bis der Anbieter Dual-Stack-Ausgänge bereitstellt“, und nicht in blindem Umschalten im Browser.
Wie ein sauberes Ergebnis aussieht
Erwarten Sie, dass die HTTPS-IP und jede srflx-IPv4-Adresse mit dem angekündigten Ausgangsbereich des VPN-Anbieters übereinstimmen. Erwarten Sie, dass DNS-Antworten (wenn Sie diese bewusst testen) von den Resolver-Hostnamen des Anbieters stammen und nicht von Ihrem ISP. Erwarten Sie, dass WebRTC innerhalb des Timeouts für das Gathering entweder kein srflx anzeigt (striktes NAT) oder ein srflx anzeigt, das immer noch dem VPN entspricht. Abweichungen verdienen Screenshots für den Support: Fügen Sie Zeitstempel, ausgewählte Stadt und die Information hinzu, ob Split-Tunneling für „Arbeits-Apps“ aktiviert ist.
Fehlerbehebungen, die einen Neustart überstehen
Beginnen Sie mit dem VPN-Client: Aktivieren Sie den Kill-Switch, deaktivieren Sie das Split-Tunneling für den Browser, mit dem Sie testen, und schalten Sie die DNS-Sperre des Anbieters ein, falls angeboten. Unter Firefox prüfen fortgeschrittene Benutzer about:config-Schlüssel wie media.peerconnection.ice.default_address_only und zugehörige Einstellungen, bevorzugen jedoch die Anweisungen des Herstellers, da sich die genauen Schlüssel zwischen den Versionen ändern. Verifizieren Sie unter Windows, dass die Metrik des virtuellen VPN-Adapters niedriger ist als die des WLAN-Adapters, damit sich die Standardrouten tatsächlich verschieben.
Beispiel-Firefox-Diagnose (schreibgeschützt; ändern Sie nur Werte, die Sie verstehen):
about:webrtc
about:networking#dnsDie erste Seite fasst aktive Sitzungen zusammen; die zweite listet die für den Browser sichtbaren DNS-Cache-Einträge auf, was beim Debuggen von Captive-Portalen oder veralteten SRV-Einträgen hilft.
Versprechen auf der Verpackung im Vergleich zu dem, was Sie überprüfen können
„Keine Protokolle“ ist von außen nicht überprüfbar; es ist ein rechtliches und betriebliches Versprechen. Die Gerichtsbarkeit ist wichtig, da Vorladungen dem Unternehmenssitz folgen. RAM-only-Server reduzieren forensische Rückstände, ändern aber nichts an der Routing-Mathematik. Was Sie zu Hause überprüfen können, ist die Korrektheit des Pfads (diese Seite), die Wahl des Resolvers (DNS-Tool), ob IPv6 abgedeckt ist und ob der Kill-Switch den Datenverkehr blockiert, wenn Sie den VPN-Prozess abrupt beenden. Nehmen Sie diese Prüfungen in Ihre Reise-Checkliste auf, genau wie Sie Rauchmelder testen.
Leak-Typen im Vergleich
| Leak-Typ | Was offengelegt wird | Häufige Ursache | Praktische Lösung |
|---|---|---|---|
| WebRTC / ICE srflx | Öffentliche IPv4/IPv6 außerhalb des VPN | UDP nicht in den Tunnel geroutet; deaktivierter Firewall-Helper | VPN-Kernel-Treiber; Split-Tunneling deaktivieren; Hersteller-Update |
| DNS | Hostnamen für ISP-Resolver sichtbar | Betriebssystem bevorzugt weiterhin DHCP-DNS; VPN-DNS nicht gepusht | DNS-Sperre; DoT/DoH nur auf VPN-Schnittstelle festlegen |
| IPv6 | Nativer IPv6-Pfad umgeht reinen IPv4-Tunnel | Tunnel fehlt v6; Betriebssystem bevorzugt AAAA | Dual-Stack-Ausgang aktivieren; oder v6 im Betriebssystem blockieren, bis das Problem behoben ist |
| Verkehrskorrelation | Timing- und Volumen-Metadaten | Globaler passiver Angreifer auf beiden Seiten des VPN | Tor oder Mix-Netzwerke mit höherer Latenz; Einbußen bei der Benutzerfreundlichkeit akzeptieren |
| Kill-Switch-Fehler | Klartext-Ausbrüche während der Wiederverbindung | Client-Absturz; Wettlauf zwischen Ruhezustand und Aufwachen; benutzerdefinierte Routen | Blockierungsregeln auf Betriebssystemebene aktivieren; mit ping während der Wiederverbindung testen |
Häufig gestellte Fragen
Was ist ein WebRTC-Leak?
Es handelt sich um jeden Fall, in dem WebRTC ICE eine öffentliche IP oder einen UDP-Pfad offenlegt, der nicht mit der Adresse übereinstimmt, die Ihr getunnelter HTTPS-Verkehr verwendet. Srflx-Kandidaten stammen direkt von STUN. Wenn STUN also Ihren ISP sieht, während die Website Ihr VPN sieht, führt Ihr Browser ein Split-Routing auf Protokollebene durch.
Woher weiß ich, ob mein VPN tatsächlich funktioniert?
Führen Sie drei unabhängige Prüfungen durch: HTTPS-IP (diese Website), srflx-Vergleich (diese Seite) und einen resolverspezifischen DNS-Test (unser DNS-Tool oder das Panel Ihres Anbieters). Wenn alle drei mit dem VPN-Anbieter übereinstimmen, haben Sie starke Beweise dafür, dass sich die Standardroute verschoben hat. Wenn eine davon nicht übereinstimmt, erfassen Sie Protokolle, bevor Sie davon ausgehen, dass das VPN „defekt“ ist.
Warum leckt mein VPN DNS?
Weil Betriebssysteme Namen auflösen, bevor oder während der Tunnel aufgebaut wird, und einige VPNs nur Routen für IPv4-Subnetze kopieren. Über DHCP bereitgestellte DNS-Server verbleiben in systemd-resolved, NetworkManager oder den Windows-Schnittstellenmetriken, es sei denn, das VPN pusht Ersatzserver und erhöht die Schnittstellenpriorität.
Sollte ich IPv6 für mein VPN deaktivieren?
Betrachten Sie die Deaktivierung von IPv6 als vorübergehenden Diagnoseschritt, nicht als Dauerlösung. Die richtige Behebung ist ein VPN, das beide Familien tunnelt, oder eine Betriebssystemkonfiguration, die AAAA blockiert, bis Dual-Stack-Ausgänge vorhanden sind. IPv6 global deaktiviert zu lassen, kann moderne Websites beeinträchtigen und das Debuggen erschweren.
Lecken kostenlose VPNs mehr als kostenpflichtige?
Der Preis ist nicht die Variable; es ist die Technik. Einige kostenlose Angebote sind modifizierte kostenpflichtige Stacks mit aggressiven Standardeinstellungen; andere verdienen Geld, indem sie DNS-Daten protokollieren und verkaufen, was schlimmer ist als ein sichtbares Routing-Leak. Lesen Sie das Bedrohungsmodell: Ein kostenloses Browser-VPN, das nur den Tab-Verkehr tunnelt, verhält sich niemals wie ein systemweiter Tunnel, egal wie glänzend die Benutzeroberfläche ist.
Verwandte Tools
Die grundlegende Identität ohne WebRTC finden Sie auf Wie ist meine IP. ASN- und Organisations-Labels finden Sie in Wer ist mein ISP. Das Resolver-Verhalten finden Sie auf Wie ist mein DNS. Um das RTT zu diesem Edge nach dem Serverwechsel zu ermitteln, führen Sie Wie ist meine Latenz aus.
Oben zitierte Quellen
- RFC 5389: Session Traversal Utilities for NAT (STUN)
- RFC 8445: Interactive Connectivity Establishment (ICE)
- W3C WebRTC: Browser-API-Oberfläche
- RFC 4787: Verhaltensanforderungen für Netzwerkadressübersetzung