Was eine WebRTC-Kandidatenliste über Ihr VPN verrät
Ein Host-, server-reflexiver oder Relay-Kandidat sagt, woher eine Adresse stammt. Nur das ausgewählte ICE-Paar sagt, welchen Pfad die Medien tatsächlich genutzt haben.
Wenn eine WebRTC-Testseite 172.20.4.15 ausgibt, hat sie erfahren, dass in diesem Netz eine lokale Schnittstelle existiert. Das ist eine echte Offenlegung und nicht derselbe Befund wie „die Medien verließen den VPN-Ausgang“. Kandidatenerkennung und Paketrouting sind getrennte Mechanismen, und die meisten Leak-Berichte verschmelzen beide zu einem Urteil. Welchen der beiden Fälle Sie sehen, entscheidet über die Abhilfe.
Das Sammeln läuft, bevor etwas gesendet wird
Der Browser zählt lokale Schnittstellen auf, sendet eine Bindungsanfrage an einen STUN-Server und bittet einen TURN-Server um eine Zuweisung, dann schreibt er die Ergebnisse als Kandidatenzeilen in die Sitzungsbeschreibung. All das endet ohne Anruf, ohne Medien und ohne Gegenstelle. Eine Kandidatenliste ist daher eine Aufzeichnung der Erkennung, nicht des Transports.
Moderne Browser können die wörtliche Adresse eines Host-Kandidaten durch einen mDNS-Namen .local ersetzen, sodass die Seite die private IP nicht lesen kann. Das lokale Netz sieht die Multicast-Abfragen, die diesen Namen auflösen, weiterhin, die Adresse wird also vor der Anwendung verborgen statt aus dem Netz entfernt.
Auch die Reihenfolge zählt: ein neuer Seitenaufruf sammelt einen neuen Satz, mit einer anderen TURN-Zuweisung und möglicherweise einer anderen reflexiven Zuordnung. Zwei Läufe, die sich widersprechen, sind nicht zwangsläufig zwei verschiedene Konfigurationen.
Drei Kandidatentypen, drei Arten von Belegen
Jede Zeile stammt aus einer anderen Beobachtung. Jeder Typ beantwortet eine andere Frage, und die Tabelle trennt sie danach, was sie belegen können und was nicht.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
Ein Relay-Kandidat wird regelmäßig für die Internetadresse des Nutzers gehalten. Er gehört zum TURN-Server, und seine Anwesenheit zeigt, dass ein Relay verfügbar war, nicht dass der Browser ihn gewählt hat. Dieselbe Verwechslung läuft bei Host-Kandidaten in die andere Richtung, wo ein mDNS-Name die Adresse vor der Seite verbirgt, während das Netz die Abfragen weiterhin trägt. Lesen Sie den Typ, bevor Sie den Wert lesen.
Das ausgewählte Paar beantwortet die Routingfrage
ICE paart jeden lokalen Kandidaten mit jedem entfernten, führt über jedes Paar Verbindungsprüfungen aus und nominiert einen Gewinner. Dieses nominierte Paar, sichtbar in der Diagnose des Browsers selbst, trägt die Medien. Alles andere in der Liste ist eine Möglichkeit, die verloren hat.
Der Gewinner sagt Ihnen die Form des Pfades. Relay zu Relay geht über den TURN-Server, ein Host-Paar bleibt im lokalen Netz, und ein server-reflexives Paar geht direkt durch NAT. Das ist die Tatsache, die eine VPN-Prüfung braucht, und sie ist eine andere als die Adressliste. Zwei Anrufe mit identischen Kandidatenlisten können verschiedene Paare nehmen.
Nicht ausgewählte Kandidaten wurden trotzdem gesammelt, und Sammeln ist Netzwerkverkehr, der die Maschine verlässt. Ein Anruf, der am Ende das Relay nutzte, bedeutet nicht, dass beim Aufbau der Liste nichts offengelegt wurde.
Kontrollen entsprechen Zielen, nicht einer Leak-Bewertung
Die WebRTC-Spezifikation zur IP-Behandlung beschreibt mehrere Richtlinien: nur die Schnittstelle nutzen, die die Standardroute trägt; alle Schnittstellen nutzen; und nicht über einen Proxy laufendes UDP abschalten, sodass der Verkehr über ein Relay oder einen Proxy gehen muss. Jede tauscht Konnektivität und Latenz gegen eine andere Art der Exposition. Welche ein Browser umsetzt und unter welchem Namen, unterscheidet sich nach Plattform und Version.
Wählen Sie die Richtlinie nach dem Ziel. Lokale Adressen vor einer Seite zu verbergen ist ein Ziel; direkten Peer-to-Peer-Verkehr zu verhindern ist ein anderes; jedes Paket im Tunnel zu halten ist ein drittes. Beim ersten geht es vor allem darum, was die Anwendung erfährt, beim zweiten darum, welcher Pfad erlaubt ist, und das dritte muss auch an der Plattform- oder VPN-Grenze durchgesetzt werden.
Welche Kontrolle Sie auch wählen, prüfen Sie beide Hälften: Führen Sie den Sammeltest aus und notieren Sie die Kandidatentypen, und untersuchen Sie dann das ausgewählte Paar während einer echten Sitzung. Eine saubere Adressliste mit direktem Medienpfad ist immer noch ein Pfad, den Sie nicht beabsichtigt hatten.