WebRTC-Leak-Test: Sichtbare IPs und fehlende Ergebnisse
WebRTC-Leak-Test verstehen: Gleiche oder zusätzliche IPs, keine öffentliche Adresse, Zeitüberschreitungen und Browser ohne Unterstützung richtig einordnen.
Sichtbare WebRTC-Adressen prüfen
Was die WebRTC-Prüfung tatsächlich macht
WebRTC unterstützt Browseranrufe und Datenverbindungen. Beim Verbindungsaufbau sammelt ICE mögliche Adressen. Ein STUN-Dienst hilft, eine öffentlich sichtbare Adresse zu finden. Dieser Pfad kann von normalen Webanfragen abweichen und sollte deshalb neben der öffentlichen IP geprüft werden.
IPNixa kontaktiert Cloudflares öffentlichen STUN-Dienst und vergleicht öffentliche Kandidaten mit den IPv4- und IPv6-Beobachtungen dieser Prüfung. Private und mDNS-Hostkandidaten werden nicht als öffentliche Sichtbarkeit gelistet. IPv6-Kandidaten in einem bereits beobachteten /64 gelten als dasselbe Netzwerk. Verglichen werden zusätzliche öffentliche Netze, nicht jede abweichende Textadresse.
Einen WebRTC-Leak-Test durchführen
Die vorgesehene VPN-Konfiguration beim Test des tatsächlich genutzten Browsers aktiv lassen. IPNixa fordert für diesen Test weder Kamera- noch Mikrofonzugriff an.
- VPN-Test öffnen und auf den Abschluss der öffentlichen IPv4- und IPv6-Prüfungen warten.
- Die sichtbaren WebRTC-Adressen ansehen. Die Prüfung läuft mit jedem Verbindungscheck und wartet bis zu drei Sekunden auf die Kandidatenermittlung.
- Bei einer zusätzlichen Adresse die WebRTC-Einstellungen von VPN und Browser prüfen. Eine weitere Adresse allein beweist keinen VPN-Leak.
- Bei „Nicht bestätigt“ nach Prüfung von Browsereinschränkungen und Verbindung erneut versuchen. Bewusst aktivierte Datenschutzfunktionen bei fehlenden Ergebnissen berücksichtigen.
Zuerst Zustand, dann Adresse lesen
Abschluss und Vergleich beantworten unterschiedliche Fragen. Die Kandidatenermittlung kann ohne öffentliche Adresse enden oder nach einem Teil der Liste vorzeitig abbrechen.
| Zustand und Ergebnis | Feststellung | Nächster Schritt |
|---|---|---|
| Verglichen · Ermittelte Adressen stimmen überein | Abgeschlossene Ermittlung fand Adressen in bereits beobachteten öffentlichen Netzen | Als Vergleich verstehen, nicht als Nachweis vollständigen VPN-Schutzes |
| Beobachtet · Zusätzliche Adresse | Eine öffentliche Adresse außerhalb der verglichenen HTTP-Beobachtungen erschien | Adresse und VPN-Routing prüfen; unvollständige Listen können weitere enthalten |
| Nicht bestätigt · Keine öffentliche Adresse festgestellt | Ermittlung endete ohne vergleichbare öffentliche Adresse | Browser-Datenschutzfunktionen oder blockierten STUN-Endpunkt berücksichtigen |
| Nicht bestätigt · Zeitüberschreitung bei der Adressermittlung | Ermittlung endete nicht innerhalb des Testzeitraums | Erneut versuchen; nicht als Ergebnis ohne Leaks deuten |
| Nicht bestätigt · Test konnte nicht abgeschlossen werden | API vorhanden, Einrichtung aber fehlgeschlagen | Browsereinschränkungen und Verbindungsfehler prüfen |
| Nicht unterstützt · WebRTC-API nicht verfügbar | Der Browser stellt die API nicht bereit | Test konnte in diesem Browser nicht ausgeführt werden |
Beispiel einer zusätzlichen Adresse durchgehen
Beispiel: Nach dem Einschalten des VPN bestätigt HTTP 198.51.100.24, WebRTC zeigt zusätzlich 203.0.113.42. Beide sind Dokumentationsadressen. Wurde 203.0.113.42 vor der VPN-Verbindung gespeichert, ist das ein Grund, den WebRTC-Pfad zu prüfen. Ohne gespeicherte Direktverbindung kann das Tool nicht feststellen, ob die zusätzliche Adresse zum Heimanschluss gehört.
Zuerst prüfen, ob die Ermittlung abgeschlossen wurde. Eine zusätzliche Adresse bleibt auch bei Zeitüberschreitung ein hilfreicher Hinweis, die Liste kann aber unvollständig sein. Dann Browserausnahmen und WebRTC-Hinweise des VPN prüfen, denselben Test wiederholen und vergleichen. Für den Support Zustand, Testzeit und Adressmuster nennen. Aus einem zusätzlichen Kandidaten weder Standort noch Identität ableiten. IPNixa macht daraus keinen verborgenen Wohnort und kein Urteil über den VPN-Anbieter.
| WebRTC-Beobachtung | Sammlung | Einordnung |
|---|---|---|
| Nur 198.51.100.24 | Abgeschlossen | Verglichen: stimmt mit der HTTP-Beobachtung überein |
| 198.51.100.24 und 203.0.113.42 | Abgeschlossen | Beobachtet: zusätzliche öffentliche Adresse; mit der gespeicherten Ausgangsverbindung vergleichen |
| Nur 198.51.100.24 | Zeitüberschreitung | Unbestätigt: die teilweise Übereinstimmung bestätigt keine vollständige Adressliste |
| 203.0.113.42 | Zeitüberschreitung | Beobachtet: die zusätzliche Adresse ist auch bei unvollständiger Sammlung relevant |
| Nur 192.168.1.5 oder ein .local-Name | Abgeschlossen | Unbestätigt: dies sind keine öffentlichen Adressen für den Vergleich |
Warum „keine öffentliche Adresse“ kein eindeutiges Ergebnis ist
Ein Browser kann nur lokale Kandidaten zeigen, Adressdetails verbergen oder den STUN-Dienst nicht erreichen. Das kann zu Datenschutzfunktionen passen, sagt aber nicht, was in einem anderen Browser, Anruf oder einer anderen App geschieht.
Für eine sinnvolle Folgeprüfung den Test unter denselben Netzbedingungen wiederholen und den vollständigen IPv4-/IPv6-Vergleich ansehen. DNS-Leaks benötigen einen eigenen Testdienst mit autoritativem DNS. VPN-Anbietereinstufung und Browser-Fingerprinting beantworten ebenfalls andere Fragen.
Häufige Fragen
Ist „keine öffentliche Adresse festgestellt“ ein erfolgreicher Leak-Test?
Das Ergebnis ist nicht eindeutig. Es lag keine öffentliche Adresse zum Vergleich vor. Ursache können Browser-Datenschutzfunktionen, nur lokale Kandidaten oder blockierter STUN-Zugriff sein.
Warum bricht der WebRTC-Test mit einer Zeitüberschreitung ab?
Die Adressermittlung wurde innerhalb des Testzeitraums nicht abgeschlossen. Netzbedingungen, Einschränkungen oder STUN-Erreichbarkeit können das beeinflussen. Eine Zeitüberschreitung wird als „Nicht bestätigt“ angezeigt, selbst wenn einzelne passende Adressen sichtbar waren.
Zeigt ein WebRTC-Test hinter jedem VPN meine ursprüngliche IP?
Nein. Er zeigt öffentliche Adressen, die dieser Browser während der Prüfung offenlegt. Bei korrektem Routing oder Einschränkungen erscheinen möglicherweise nur erwartete Adressen oder gar keine.
Benötigt IPNixa Zugriff auf Kamera oder Mikrofon?
Nein. Die Prüfung ermittelt Verbindungskandidaten über einen Datenkanal. Sie fordert weder Audio noch Video an und zeichnet nichts davon auf.