VPN versus TURN-relay: wat draagt een WebRTC-gesprek werkelijk?
Een tunnel verandert het pad dat ICE ziet; hij wijst nooit een relay toe en levert geen signalering. Vergelijk wat een VPN-uitgang en een TURN-server elk bieden.
De pagina laadt via de VPN, het gesprek komt nooit tot stand: twee verschillende fouten in dezelfde adresbalk. De tunnel veranderde het pad dat de browser gebruikt; hij werd geen signaleringsdienst, STUN-server of relay, en hij bepaalt niet welk kandidatenpaar ICE kiest. Juist het scheiden van de taak van elke component maakt van een vaag „WebRTC is geblokkeerd” een concrete fout.
Vier taken, waarvan de tunnel er maar één raakt
De toepassing wisselt sessie-informatie uit via een of andere signaleringsregeling, en dat is de eerste taak. ICE verzamelt kandidaatadressen en test paren tot er één werkt, wat de tweede is. STUN laat een peer leren hoe zijn verkeer er van buiten uitziet, en TURN wijst een relay toe voor gevallen waarin geen direct pad bestaat. Die vier rollen zijn verschillend, en een VPN beïnvloedt de adressen en het filteren die ze tegenkomen in plaats van een ervan te leveren.
Daarom zegt een geslaagde login niets over het mediapad. Signalering gaat meestal over dezelfde HTTPS die de pagina al gebruikt, op poort 443, terwijl de media via UDP naar een heel andere bestemming kunnen reizen.
Privéadressering maakt de verwarring erger. Een tunneladres is alleen nuttig voor een peer als die peer een bedoeld pad terug heeft; privé zijn is geen bewijs van wederzijdse bereikbaarheid, en browsers behandelen het niet zo wanneer ze kandidaten weggooien die niet kunnen worden gecontroleerd. Een kandidaat die u lokaal lijkt, kan vanaf de andere kant ontestbaar zijn. Die kloof is het waard uit te sluiten voordat u concludeert dat de tunnel media laat vallen.
Vergelijk een VPN-uitgang met een TURN-relay
Beide sturen pakketten door, daarom worden ze verward, en de vergelijkingstabel hierboven is het waard kolom voor kolom te lezen in plaats van als een lijst met functies. Een relaytoewijzing is een object per sessie dat door een geauthenticeerd verzoek wordt gemaakt; een tunnel is een route. De een heeft inloggegevens die verlopen, de ander heeft een peeradres dat ofwel bereikbaar is of niet.
| 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 |
Poortnummers maken het verschil concreet. TURN luistert standaard op 3478 voor UDP en TCP en op 5349 voor TLS, en een netwerk dat 443 toestaat maar die poorten laat vallen, laat relaygesprekken mislukken terwijl browsen normaal doorgaat. De poort van de VPN wijzigen configureert daar niets van, omdat de poorten die ertoe doen bij de relaydienst horen, niet bij de tunnel.
Lees de diagnostiek en test dan het gesprek
Browsers tonen de informatie die u nodig hebt zonder pakketopname. Open de WebRTC-diagnostiekpagina voor uw browser, voer het gesprek en lees het gekozen kandidatenpaar in plaats van de verzamelde lijst: welke lokale en externe kandidatentypen zijn gekozen, via welk transport en welke adresfamilie, en of het pad direct of via een relay loopt.
Twee lezingen zijn vooraf de moeite waard. Als het gekozen paar host-naar-host is op privéadressen, blijft de media op een pad waarover u kunt redeneren; als het relay-naar-relay is, verbruikt het gesprek relaycapaciteit en hangt het af van de beschikbaarheid van die dienst. Een fout die bij „controleren” stopt zonder gekozen paar betekent dat kandidaten zijn verzameld, maar geen enkele de connectiviteitscontroles heeft doorstaan.
Vergelijk daarna dezelfde twee eindpunten in hetzelfde gesprek terwijl u slechts één goedgekeurde voorwaarde wijzigt, en accepteer het resultaat op tweerichtingsmedia of -data in plaats van op een indicator „verbonden”. Het verzamelen van kandidaten slaagt in veel gevallen die nooit één audioblad dragen. Herhaal het gesprek aan de andere kant van de wijziging en bewaar beide diagnostische opnamen, want twee runs vergelijken zegt meer dan een van beide alleen lezen. Dezelfde eindpunten, dezelfde codec, één gewijzigde variabele.
Een toepassing die haar ICE-transportbeleid bewust op relay zet, vraagt alleen om relaykandidaten. Die instelling maakt geen relay en repareert geen ontbrekende inloggegevens; ze maakt de eis expliciet, wat nuttig is wanneer iemand de VPN de schuld geeft van een beleid dat de site heeft gekozen.
Houd de privacybewering zo smal als het bewijs
De blootstelling van kandidaten hangt af van browser- en toepassingsbeleid, niet alleen van tunnelstatus, en de W3C-specificatie voor peerverbinding behandelt IP-afhandeling als een eigen kwestie. Een verbonden VPN is daarom een zwakke basis voor de belofte dat een gesprek slechts één gekozen adres onthult. Twee peers achter dezelfde tunnel kunnen zelfs een pad kiezen dat de host nooit verlaat, wat tegelijk een privacyverbetering en een connectiviteitsbeperking is.
Wat u precies kunt stellen, is smaller en nuttiger: welk kandidatenpaar is gekozen, welk transport het droeg en of dat pad binnen de tunnel bleef. Noteer die drie feiten voor een gesprek dat werkt en voor een dat faalt, en het verschil noemt meestal de component die moet worden gerepareerd.
Zodra de connectiviteit werkt, scheidt u prestaties van bereikbaarheid. Verlies, vertraging, wachtrijen en MTU liggen allemaal stroomafwaarts van een correct kandidatenpaar, en een haperend gesprek als een connectiviteitsfout behandelen stuurt u zonder reden terug naar de kandidatenlijst.