4. Mai 2026 · 8 Min. Lesezeit
VPN-Leak-Test erklärt — WebRTC vs. DNS vs. IP (Was Webseiten sehen können)
Verstehen Sie WebRTC-ICE-srflx-Leaks, warum Browser DNS-Resolver nicht vollständig testen können und wie Sie über HTTPS sichtbare IPs im Jahr 2026 mit STUN-abgeleiteten Kandidaten vergleichen.
Ein VPN-Leak ist frustrierend, weil es die Erwartung zunichte macht, dass der gesamte Datenverkehr magisch unter einer einzigen IP-Adresse an einem anderen Ort austritt. In der Praxis lassen sich Leaks in drei Kategorien unterteilen, über die Analysten ständig sprechen: IP-Sichtbarkeit über HTTP-Transporte, über WebRTC ICE offengelegte UDP-Pfade und DNS-Abfragen, die den Resolver des Tunnels umgehen. Zu wissen, was gewöhnliche Webseiten diagnostizieren können, hilft Ihnen, Ihre Anstrengungen richtig zu verteilen — Browser-JavaScript glänzt bei HTTPS- und ICE-Signalen, stößt aber bei autoritativen DNS-Prüfungen an seine Grenzen.
Ihr Browser zeigt routinemäßig die Adresse an, die Server bei TLS-verschlüsselten Abrufen sehen. Diese Daten — manchmal ergänzt durch CDN-Header — bilden das Rückgrat generischer „Wie ist meine IP?“-Widgets.
Was WebRTC erfasst und warum srflx wichtig ist
Peer-Verbindungen handeln Medien- oder Datenpfade mithilfe von Interactive Connectivity Establishment (ICE) aus. Jeder Kandidat (Candidate) stellt einen potenziellen Pfad dar: lokale Host-/Privatadressen (host), symmetrische NAT-Reflexionsergebnisse aus der Interaktion mit STUN (srflx), Relay-Overlays über TURN (relay) und gelernte, für den Peer sichtbare Pfade (prflx).
Srflx-Zeilen sind bei der Suche nach Leaks wichtig, da ihre Erstellung UDP-Sonden an eine kooperative STUN-Infrastruktur sendet. Die reflexive IP-Werte sollten mit dem öffentlichen Endpunkt übereinstimmen, den Ihr Upstream-NAT (oder Tunnel) für ausgehendes UDP bereitstellt — dieser muss nicht zwingend mit der über TCP sichtbaren HTTPS-Adresse identisch sein, insbesondere wenn Router die Protokolle unterschiedlich behandeln —, aber große Abweichungen sollten untersucht werden.
Moderne Browser legen sukzessive typisierte Kandidaten-Umschläge offen; SDP-Strings bleiben die Kompatibilitätslösung (Markierung typ srflx plus eingebettete IPv4). IPv6-haltige SDP-Fragmente können ohne tiefergehendes Parsing schwieriger zu identifizieren sein; kombinieren Sie automatische Vergleiche mit den Leak-Test-Suites der VPN-Anbieter, wenn IPv6-Unklarheiten eine Rolle spielen.
Praktische Vergleichsheuristik
Führen Sie ein kurzes ICE-Gathering parallel zum HTTPS-Referenzwert durch:
| Signal | Erwartung für Bestehen | Einschränkung bei der Interpretation |
|---|---|---|
| HTTPS IPv4 | Entspricht der VPN-Austrittsregion bei getunneltem Verkehr | Captive Portals können die Darstellung manipulieren |
| Srflx IPv4 | Spiegelt die HTTPS-IPv4 für Pfade im gleichen Protokoll-Stack wider | Ein separater IPv6-Abfluss kann einfache Übereinstimmungen ungültig machen |
| DNS | Eindeutige Resolver-Zuordnung | Erfordert eine Infrastruktur außerhalb von HTTP-Abruf-Sandboxes |
DNS-Leaks — die Infrastrukturlücke
Historisch gesehen bedeuteten DNS-Leaks, dass „der Resolver meines ISPs weiterhin autoritative Server nach Tunnel-Hostnamen abgefragt hat“. Der Nachweis der Resolver-Identität erfordert eindeutige Labels, die an Messdomänen delegiert sind — etwas, das passive Webseiten nicht magisch ohne die Kooperation von DNS-Betreibern erfinden können.
Verantwortungsvolle Ratschläge bleiben wichtig: Bestehen Sie auf VPN-Funktionen wie DNS-Sperre / exklusiver Resolver, sorgen Sie für eine Firewall-Bereinigung ausgehender 53/tcp/udp-Verbindungen, überprüfen Sie DHCP-Optionen, analysieren Sie systemd-resolved-Snapshots (Linux) und vermeiden Sie Split-Tunneling-Ausnahmen, die Slack oder Browser-Updates versehentlich im Klartext übertragen.
Browser-Tools können dennoch das Verständnis für kontrollierte DNS-over-HTTPS-Abfragen vermitteln, sodass Sie resolver-sichtbare Antworten bewusst vergleichen können — zum Beispiel mithilfe unserer ergänzenden Seite Was ist mein DNS, nachdem Sie DoH bewusst konfiguriert haben. Dieser instruktive Ablauf ist unabhängig von einer vollständigen Leak-Zertifizierung.
Warum Kill-Switches JavaScript-Sonden ergänzen
Betriebssystemseitige Kill-Switches unterbinden den Datenverkehr außerhalb des VPNs, wenn der Tunnel abbricht — und schließen so Zeitfenster, in denen DNS-Abfragen oder verirrte UDP-Pakete entweichen können. Skripte können die Routing-Tabellen des Hosts nicht ändern; die Kombination automatisierter UI-Prüfungen mit den nativen Testtools des Anbieters bleibt Best Practice bei der Bedrohungsanalyse — nicht nur die Bequemlichkeit für Endverbraucher.
Code-Snippet: minimales ICE-Gerüst (zu Bildungszwecken)
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }],
});
pc.createDataChannel("probe");
pc.onicecandidate = (evt) => {
const cand = evt.candidate;
if (!cand) return;
console.log(cand.type, cand.candidate ?? cand.address);
};
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
Produktionscode enthält begrenzte Timer, SDP-Fallbacks, wenn address fehlt, Concurrency-Guards, präzise Datenschutzhinweise und eine kalibrierte Wortwahl („mögliches Signal“ statt eines binären Bestehen/Nichtbestehen).
Wenn ein grünes Häkchen trügerisch ist
Symmetrisches NAT führt manchmal dazu, dass innerhalb weniger Sekunden kein srflx ausgegeben wird, obwohl Ihr VPN einwandfrei funktioniert — das Fehlen von ICE-Daten ist nicht aussagekräftig und kein Beweis für Sicherheit. Unternehmen können HTTPS über Proxys leiten, während sie UDP unberührt lassen, was Vergleiche verzerrt, es sei denn, man berücksichtigt die Netzwerkrichtlinien. IPv6-Pfade können von IPv4 abweichen; wenn Ihr VPN-Client nur eines der beiden Protokolle unterstützt, müssen Sie beide explizit überprüfen.
Split-Tunneling-Ausnahmen (Spiele, Videokonferenzen, IPs von Unternehmens-SaaS) leiten den Verkehr absichtlich am Tunnel vorbei — dies als „Fehler“ zu bezeichnen, verkennt die Absicht. Nutzer sollten die Browser-Ergebnisse mit dem VPN-Dashboard, den Firewall-Protokollen oder Paketaufzeichnungen korrelieren, wenn viel auf dem Spiel steht (Journalismus, rechtliche Angelegenheiten, regulierter Remote-Zugriff).
Fingerprinting-Skripte verknüpfen IP-Hinweise mit nicht damit zusammenhängenden Signalen — WebGL, Schriftarten, Audio —, sodass eine alleinige Absicherung von WebRTC das Tracking-Risiko nicht beseitigt. Kombinieren Sie Leak-Prüfungen mit Anleitungen zur Browser-Härtung und Gewohnheiten aus der „HTTPS Everywhere“-Ära (die heute weitgehend Standard sind).
Öffnen Sie Was ist mein VPN / Habe ich ein Leak? für einen sofortigen HTTPS-vs.-WebRTC-Vergleich auf dieser Domain, durchsuchen Sie Was ist meine IP / Was ist mein ISP / Wie hoch ist meine Latenz / Internet-Geschwindigkeitstest für den Transportkontext und nutzen Sie Was ist mein DNS, wenn Sie Resolver-Abfragen selbst testen möchten — im Wissen, dass der Nachweis der DNS-Identität für einen autoritativen Beweis weiterhin VPN-eigene Tools erfordert.