Was ist ein WebRTC-Leak?
WebRTC ist die im Browser integrierte Echtzeitkommunikation, genutzt für Videokonferenzen, Sprachanrufe, P2P-Dateiübertragung und ähnliche Szenarien. Um eine Peer-to-Peer-Verbindung aufzubauen, ermittelt der Browser über einen STUN-Server seine öffentlich sichtbare Adresse. Diese Abfrage läuft meist über UDP, und gewöhnliche HTTP- / SOCKS-Proxys leiten UDP nicht unbedingt um.
Umgeht die STUN-Anfrage den Proxy und geht direkt aus dem lokalen Netzwerk hinaus, kann ein Skript auf der Webseite Ihre echte öffentliche IP ermitteln. Dafür ist in der Regel keine Kamera- oder Mikrofonberechtigung nötig, und es erscheint keine zusätzliche Bestätigungsabfrage. Deshalb wird damit häufig geprüft, ob ein Proxy die Echtzeitkommunikation tatsächlich abdeckt.
Wie dieses Tool Leaks erkennt
Die Seite sendet WebRTC-Anfragen an mehrere STUN-Server, sammelt die zurückgegebenen öffentlichen Adressen und vergleicht sie mit der HTTP-Ausgangs-IP. Stimmt die zurückgegebene Adresse mit dem aktuellen Ausgang überein, wird der UDP-Pfad wahrscheinlich vom Proxy abgewickelt; kommt eine Adresse Ihres lokalen Netzbetreibers zurück, sollten Sie das genauer prüfen.
- Prüfen, ob UDP über den Proxy-Ausgang läuft
- Erkennen, ob IPv4 und IPv6 jeweils unabhängig voneinander leaken
- Beobachten, ob unterschiedliche STUN-Ziele verschiedene Routing-Regeln treffen
Die Rolle von STUN und UDP
UDP ist ein verbindungsloses Transportprotokoll, das häufig für Sprache, Video, Spiele und Echtzeitkommunikation genutzt wird. STUN hat eine einfache Aufgabe: Sie senden ein UDP-Paket an den Server, und der Server teilt Ihnen die Quell-IP mit, die er gesehen hat. WebRTC stützt sich auf dieses Ergebnis, um eine Verbindung auszuhandeln; die von STUN gesehene Adresse ist daher der entscheidende Beleg für die Beurteilung eines Leaks.
So deuten Sie die Ergebnisse
Kein Leak erkanntDie von WebRTC zurückgegebene öffentliche IP stimmt mit Ihrem aktuellen Proxy-Ausgang überein (bei IPv6: dasselbe /64). Kommt gar keine öffentliche IP zurück, hat der Test lediglich keine Antwort erhalten; das ist kein Beleg für Sicherheit.
Verdacht auf LeakWebRTC hat eine andere öffentliche IP zurückgegeben, und deren Standort, Netzbetreiber oder ASN deutet auf Ihr echtes lokales Netzwerk hin.
Normales Split-TunnelingMehrere STUN-Server melden jeweils einen anderen Proxy-Ausgang, doch jeder dieser Ausgänge entspricht Ihrem konfigurierten Routing bzw. Ihren Regeln.
Was tun, wenn ein Leak gefunden wurde?
- Stellen Sie Ihren Proxy-Client auf den TUN-Modus um, damit auch das UDP von WebRTC über den Proxy-Ausgang läuft.
- Chrome / Edge: Unternehmensrichtlinie <code>WebRtcIPHandling</code> = <code>disable_non_proxied_udp</code> setzen; Firefox: <code>media.peerconnection.ice.proxy_only_if_behind_proxy</code> unter <code>about:config</code> aktivieren. Entfernen Sie WebRTC nicht vollständig, denn ein Browser ohne WebRTC ist selbst identifizierbar.
- Brave: Richtlinie für die WebRTC-IP-Verarbeitung auf „Disable non-proxied UDP“ setzen.
- Wenn Sie Konferenzen oder Sprachanrufe benötigen, korrigieren Sie zuerst die UDP-/STUN-Routing-Regeln in Ihrem Proxy-Client.
Mehrere Ausgangs-IPs bedeuten nicht unbedingt einen Leak
Wenn Sie Split-Tunneling konfiguriert haben, können verschiedene STUN-Server über unterschiedliche Knoten laufen – etwa der STUN-Server von Google über einen US-Ausgang und der von Cloudflare über einen Ausgang in Hongkong. Das ist nicht zwangsläufig gefährlich; entscheidend ist, ob es zu Ihrem Regelwerk passt. Wirklich aufpassen müssen Sie, wenn alle WebRTC-Adressen auf Ihren physischen Standort oder Ihren lokalen ISP verweisen.
DNS-Leaks sind ebenso wichtig
Ein WebRTC-Leak legt „Ihre echte IP“ offen, ein DNS-Leak dagegen, „welche Domains Sie abgefragt haben“. Laufen DNS-Anfragen nicht über den Proxy, können Ihr lokaler Netzbetreiber oder der Upstream-Resolver weiterhin sehen, welche Websites Sie besuchen.
Die DNS-Leak-Erkennung auf dieser Seite beruht auf einer echten Messung: CleanIP.io betreibt je einen autoritativen NS in Utah, USA (ns1) und Los Angeles, USA (ns2), die die Zone dp.cleanip.io bedienen. Bei jedem Test werden 8 unabhängige Subdomains <uuid>.dp.cleanip.io aufgelöst. Diese Anfragen laufen über den Stub-Resolver Ihres Systems -> ISP / VPN / öffentlichen rekursiven Resolver und landen schließlich bei unserem autoritativen NS. Dieser zeichnet die IP des anfragenden Resolvers und (falls vorhanden) das EDNS Client Subnet auf und gibt beides zum Vergleich an Sie zurück.
Achten Sie auf zwei Signale: ① ECS-Subnetz – hat der rekursive Resolver Ihr Client-Subnetz weitergegeben (häufig bei Google 8.8.8.8), ist dieses Subnetz ein eindeutiger Beleg Ihrer Client-Identität; ② Land des Resolvers – grenzüberschreitendes Anycast bei öffentlichen rekursiven Resolvern (1.1.1.1 / 8.8.8.8) ist normal; entscheidend ist, ob der Standort des Resolvers bei vermeintlich aktivem VPN mit dem Land Ihres HTTP-Ausgangs übereinstimmt.
Warum Proxy-Modus und TUN-Modus unterschiedliche Ergebnisse liefern
HTTP- / SOCKS-Proxys verarbeiten meist nur TCP, daher kann das für STUN nötige UDP womöglich nicht gesendet werden, und die Seite zeigt eventuell „kein Leak“. Das heißt nicht, dass UDP sicher über den Proxy läuft – UDP hat den STUN-Server lediglich nie erreicht. Der TUN-Modus fängt TCP und UDP am virtuellen Netzwerkadapter ab und bildet daher den echten UDP-Ausgangspfad besser ab.
ModusSTUN-UDPBedeutung des Ergebnisses
HTTP- / SOCKS-ProxySenden schlägt evtl. fehl„Kein Leak“ kann auch nur heißen, dass UDP blockiert wurde
TUN / virtueller AdapterKann tatsächlich sendenBesser geeignet, um UDP-Ausgang und Routing-Regeln zu prüfen
Wir empfehlen, im tatsächlich genutzten Netzwerkmodus erneut zu testen: Nutzen Sie normalerweise TUN, testen Sie mit TUN; verlassen Sie sich auf einen Browser-Proxy, prüfen Sie zusätzlich, dass blockiertes UDP nicht fälschlich als sicher bewertet wird. Achten Sie bei der Beurteilung eines WebRTC-Leaks auf ASN, Standort und darauf, ob die zurückgegebene IP Ihren Erwartungen an das Split-Tunneling entspricht.