VPN teenoor TURN-relay: wat dra ’n WebRTC-oproep werklik?
’n Tonnel verander die pad wat ICE waarneem; dit ken nooit ’n relay toe nie en verskaf ook nie seingeewing nie. Vergelyk wat ’n VPN-uitgang en ’n TURN-bediener elkeen bied.
Bladsye laai oor die VPN, die oproep verbind nooit: twee verskillende foute wat dieselfde adresbalk dra. Die tonnel het die pad verander wat die blaaier gebruik; dit het nie ’n diens vir seingeewing, ’n STUN-bediener of ’n relay geword nie, en dit besluit nie watter kandidaatpaar ICE sal kies nie. Om die taak van elke komponent te skei, is wat ’n vae “WebRTC is geblokkeer” in ’n spesifieke fout omskep.
Vier take, waarvan die tonnel net een raak
Die toepassing ruil sessie-inligting uit deur een of ander reëling vir seingeewing, en dit is die eerste taak. ICE versamel kandidaatadresse en toets pare totdat een werk, wat die tweede is. STUN laat ’n eweknie leer hoe sy verkeer van buite lyk, en TURN ken ’n relay toe vir gevalle waar geen direkte pad bestaan nie. Daardie vier rolle is onderskeie take, en ’n VPN beïnvloed die adresse en filtering wat hulle teëkom, eerder as om enige daarvan te verskaf.
Daarom sê ’n suksesvolle aanmelding niks oor die media-pad nie. Seingeewing ry gewoonlik op dieselfde HTTPS wat die bladsy reeds gebruik, op poort 443, terwyl die media oor UDP na ’n heeltemal ander bestemming kan reis.
Private adressering maak die verwarring erger. ’n Tonneladres is net vir ’n eweknie nuttig wanneer daardie eweknie ’n beoogde pad terug daarheen het; privaat wees is nie bewys van wedersydse bereikbaarheid nie, en blaaiers behandel dit nie so wanneer hulle kandidate verwerp wat nie getoets kan word nie. ’n Kandidaat wat vir jou plaaslik lyk, kan van die ander kant ongetoetsbaar wees. Daardie gaping is die moeite werd om uit te skakel voordat jy aflei dat die tonnel media laat val.
Vergelyk ’n VPN-uitgang met ’n TURN-relay
Albei stuur pakkette oor, en daarom word hulle verwar; die vergelykingstabel hierbo is die moeite werd om kolom vir kolom te lees eerder as as ’n lys kenmerke. ’n Relay-toekenning is ’n voorwerp per sessie wat deur ’n gemagtigde versoek geskep word; ’n tonnel is ’n roete. Die een het geloofsbriewe wat verval, die ander het ’n eweknie-adres wat óf bereikbaar is óf nie.
| 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 |
Poortnommers maak die verskil konkreet. TURN luister by verstek op 3478 vir UDP en TCP en op 5349 vir TLS, en ’n netwerk wat 443 toelaat maar daardie poorte laat val, sal relay-oproepe laat misluk terwyl blaai normaal voortgaan. Om die VPN se poort te verander, konfigureer niks daarvan nie, want die poorte wat saak maak, behoort aan die relay-diens, nie aan die tonnel nie.
Lees die diagnostiek en toets dan die oproep
Blaaiers stel die inligting beskikbaar sonder ’n pakkie-opname. Maak die WebRTC-diagnostiekbladsy vir jou blaaier oop, maak die oproep, en lees die gekose kandidaatpaar eerder as die versamelde lys: watter plaaslike en afgeleë kandidaattipes gekies is, oor watter transport en adresfamilie, en of die pad direk of deur ’n relay is.
Twee lesings is die moeite werd om vooraf te ken. As die gekose paar gasheer-tot-gasheer op private adresse is, bly die media op ’n pad waaroor jy kan redeneer; as dit relay-tot-relay is, spandeer die oproep relay-kapasiteit en hang dit van daardie diens se beskikbaarheid af. ’n Fout wat by “checking” stop sonder ’n gekose paar beteken kandidate is versamel, maar nie een het die verbindingstoetse geslaag nie.
Vergelyk dan dieselfde twee eindpunte op dieselfde oproep terwyl jy net een goedgekeurde voorwaarde verander, en aanvaar die resultaat op tweerigting-media of -data eerder as op ’n verbinde-aanduiding. Kandidaatversameling slaag in baie gevalle wat nooit ’n enkele raam klank dra nie. Herhaal die oproep aan die ander kant van die verandering en bewaar albei diagnostiese opnames, want om twee lopies te vergelyk is meer insiggewend as om enigeen alleen te lees. Dieselfde eindpunte, dieselfde kodek, een veranderlike aangepas.
’n Toepassing wat sy ICE-transportbeleid doelbewus op relay stel, vra net relay-kandidate. Daardie instelling skep nie ’n relay nie en herstel nie ontbrekende geloofsbriewe nie; dit maak die vereiste eksplisiet, wat nuttig is wanneer iemand die VPN blameer vir ’n beleid wat die werf gekies het.
Hou die privaatheidsbewering so eng soos die bewyse
Kandidaatblootstelling hang van blaaier- en toepassingsbeleid af, nie net van tonnelstatus nie, en die W3C se eweknie-verbindingspesifikasie behandel IP-hantering as sy eie saak. ’n Verbinde VPN is dus ’n swak grondslag om te belowe dat ’n oproep net een gekose adres onthul. Twee eweknieë agter dieselfde tonnel kan selfs ’n pad kies wat nooit die gasheer verlaat nie, wat terselfdertyd ’n privaatheidsverbetering en ’n verbindingsbeperking is.
Wat jy presies kan stel, is smaller en nuttiger: watter kandidaatpaar gekies is, watter transport dit gedra het, en of daardie pad binne die tonnel gebly het. Teken daardie drie feite aan vir ’n werkende oproep en vir ’n mislukte een, en die verskil noem gewoonlik die komponent om reg te maak.
Sodra verbinding werk, skei werkverrigting van bereikbaarheid. Verlies, vertraging, toustaan en MTU sit almal stroomaf van ’n korrekte kandidaatpaar, en om ’n wankelrige oproep as ’n verbindingsfout te behandel, stuur jou sonder rede terug na die kandidaatlys.