VPN oder TURN-Relay: Was trägt einen WebRTC-Anruf wirklich?
Ein Tunnel verändert den Pfad, den ICE sieht; er weist niemals ein Relay zu und liefert keine Signalisierung. Vergleichen Sie, was ein VPN-Ausgang und ein TURN-Server jeweils leisten.
Die Seite lädt über das VPN, der Anruf kommt nie zustande: zwei verschiedene Fehler mit derselben Adressleiste. Der Tunnel hat den Pfad geändert, den der Browser nutzt; er ist kein Signalisierungsdienst, kein STUN-Server und kein Relay geworden und entscheidet nicht, welches Kandidatenpaar ICE wählt. Erst die Trennung der Aufgaben der einzelnen Komponenten macht aus einem vagen „WebRTC ist blockiert“ einen konkreten Fehler.
Vier Aufgaben, von denen der Tunnel nur eine berührt
Die Anwendung tauscht Sitzungsinformationen über irgendeine Signalisierungsvereinbarung aus, und das ist die erste Aufgabe. ICE sammelt Kandidatenadressen und prüft Paare, bis eines funktioniert, was die zweite ist. STUN lässt einen Peer erfahren, wie sein Verkehr von außen aussieht, und TURN weist ein Relay für Fälle zu, in denen kein direkter Pfad existiert. Diese vier Rollen sind verschieden, und ein VPN beeinflusst die Adressen und die Filterung, auf die sie treffen, statt eine von ihnen bereitzustellen.
Deshalb sagt eine erfolgreiche Anmeldung nichts über den Medienpfad aus. Die Signalisierung läuft meist über dasselbe HTTPS, das die Seite bereits nutzt, auf Port 443, während die Medien über UDP zu einem völlig anderen Ziel reisen können.
Private Adressierung verschlimmert die Verwirrung. Eine Tunneladresse ist für einen Peer nur dann nützlich, wenn dieser Peer einen beabsichtigten Pfad zurück dorthin hat; privat zu sein ist kein Beleg für gegenseitige Erreichbarkeit, und Browser behandeln es nicht so, wenn sie Kandidaten verwerfen, die nicht geprüft werden können. Ein Kandidat, der Ihnen lokal erscheint, kann von der anderen Seite aus unprüfbar sein. Diese Lücke sollte man ausschließen, bevor man schließt, der Tunnel verwerfe Medien.
Vergleichen Sie einen VPN-Ausgang mit einem TURN-Relay
Beide leiten Pakete weiter, weshalb sie verwechselt werden, und die Vergleichstabelle oben sollte spaltenweise gelesen werden, nicht als Funktionsliste. Eine Relay-Zuweisung ist ein Objekt pro Sitzung, das durch eine authentifizierte Anfrage entsteht; ein Tunnel ist eine Route. Das eine hat Anmeldedaten, die ablaufen, das andere hat eine Peer-Adresse, die entweder erreichbar ist oder nicht.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
Portnummern machen den Unterschied konkret. TURN lauscht standardmäßig auf 3478 für UDP und TCP sowie auf 5349 für TLS, und ein Netz, das 443 erlaubt, diese Ports aber verwirft, lässt relayte Anrufe scheitern, während das Surfen normal weiterläuft. Den Port des VPN zu ändern konfiguriert nichts davon, weil die entscheidenden Ports zum Relay-Dienst gehören, nicht zum Tunnel.
Lesen Sie die Diagnose, dann testen Sie den Anruf
Browser legen die nötigen Informationen offen, ohne einen Paketmitschnitt. Öffnen Sie die WebRTC-Diagnoseseite Ihres Browsers, führen Sie den Anruf durch und lesen Sie das ausgewählte Kandidatenpaar statt der gesammelten Liste: welche lokalen und entfernten Kandidatentypen gewählt wurden, über welchen Transport und welche Adressfamilie, und ob der Pfad direkt oder über ein Relay verläuft.
Zwei Lesarten sollte man vorher kennen. Ist das gewählte Paar Host-zu-Host auf privaten Adressen, bleibt das Medium auf einem Pfad, über den man nachdenken kann; ist es Relay-zu-Relay, verbraucht der Anruf Relay-Kapazität und hängt von der Verfügbarkeit dieses Dienstes ab. Ein Fehler, der bei „Prüfen“ ohne gewähltes Paar stehen bleibt, bedeutet, dass Kandidaten gesammelt wurden, aber keiner die Konnektivitätsprüfungen bestanden hat.
Vergleichen Sie dann dieselben zwei Endpunkte im selben Anruf, indem Sie nur eine genehmigte Bedingung ändern, und akzeptieren Sie das Ergebnis anhand von zweiseitigen Medien oder Daten, nicht anhand einer Anzeige „verbunden“. Die Kandidatensammlung gelingt in vielen Fällen, die nie einen einzigen Audiorahmen übertragen. Wiederholen Sie den Anruf auf der anderen Seite der Änderung und bewahren Sie beide Diagnoseaufzeichnungen auf, denn zwei Läufe zu vergleichen sagt mehr, als einen davon allein zu lesen. Gleiche Endpunkte, gleicher Codec, eine geänderte Variable.
Eine Anwendung, die ihre ICE-Transportrichtlinie bewusst auf relay setzt, fragt nur Relay-Kandidaten an. Diese Einstellung erzeugt kein Relay und repariert keine fehlenden Anmeldedaten; sie macht die Anforderung ausdrücklich, was nützlich ist, wenn jemand das VPN für eine Richtlinie verantwortlich macht, die die Seite gewählt hat.
Halten Sie die Datenschutzaussage so eng wie die Belege
Die Offenlegung von Kandidaten hängt von der Browser- und Anwendungsrichtlinie ab, nicht allein vom Tunnelstatus, und die W3C-Spezifikation für Peer-Verbindungen behandelt den Umgang mit IP als eigene Angelegenheit. Ein verbundenes VPN ist daher eine schwache Grundlage für das Versprechen, ein Anruf offenbare nur eine gewählte Adresse. Zwei Peers hinter demselben Tunnel können sogar einen Pfad wählen, der den Host nie verlässt, was zugleich ein Datenschutzgewinn und eine Konnektivitätsbeschränkung ist.
Was Sie präzise sagen können, ist enger und nützlicher: welches Kandidatenpaar gewählt wurde, welcher Transport es trug und ob dieser Pfad im Tunnel blieb. Notieren Sie diese drei Fakten für einen funktionierenden und einen scheiternden Anruf, und die Differenz benennt meist die Komponente, die zu reparieren ist.
Wenn die Konnektivität steht, trennen Sie Leistung von Erreichbarkeit. Verlust, Verzögerung, Warteschlangen und MTU liegen alle stromabwärts eines korrekten Kandidatenpaars, und einen ruckelnden Anruf als Konnektivitätsfehler zu behandeln schickt Sie ohne Grund zurück zur Kandidatenliste.