VPN eller TURN-relé: kva ber eigentleg ein WebRTC-samtale?
Ein tunnel endrar vegen ICE ser; han tildeler aldri eit relé og leverer ikkje signalering. Samanlikn kva ein VPN-utgang og ein TURN-server kvar tilbyr.
Sida lastar over VPN-en, men samtalen blir aldri kopla til: to ulike feil i same adresselinje. Tunnelen endra vegen nettlesaren brukar; han vart ikkje ein signaleringsteneste, ein STUN-server eller eit relé, og han avgjer ikkje kva kandidatpar ICE vel. Det er nettopp skiljet mellom oppgåvene kvar komponent løyser som gjer eit vagt «WebRTC er blokkert» til ein konkret feil.
Fire oppgåver, der tunnelen berre rører éi
Applikasjonen byter sesjonsinformasjon gjennom ei eller anna ordning for signalering, og det er den første oppgåva. ICE samlar kandidatadresser og testar par til eitt verkar, som er den andre. STUN lèt ein motpart lære korleis trafikken ser ut utanfrå, og TURN tildeler eit relé for tilfelle der det ikkje finst nokon direkte veg. Desse fire rollene er ulike, og ein VPN påverkar adressene og filtreringa dei møter i staden for å levere noka av dei.
Difor seier ei vellukka innlogging ingenting om medievegen. Signalering går vanlegvis over den same HTTPS-en som sida alt brukar, på port 443, medan mediet kan reise over UDP til ein heilt annan destinasjon.
Privat adressering gjer forvirringa verre. Ei tunneladresse er berre nyttig for ein motpart når motparten har ein tiltenkt veg tilbake til henne; å vere privat er ikkje prov for gjensidig nåbarheit, og nettlesarar handsamar det ikkje slik når dei forkastar kandidatar som ikkje kan kontrollerast. Ein kandidat som ser lokal ut for deg, kan vere utestbar frå den andre sida. Det gapet er verdt å utelukke før du konkluderer med at tunnelen slepp mediet.
Samanlikn ein VPN-utgang med eit TURN-relé
Begge videresender pakkar, og difor blir dei blanda saman, og samanlikningstabellen over er verdt å lese kolonne for kolonne i staden for som ei liste over funksjonar. Ei relétildeling er eit objekt per sesjon laga av ein autentisert førespurnad; ein tunnel er ei rute. Den eine har påloggingsinformasjon som går ut, den andre har ei motpartsadresse som anten er nåbar eller ikkje.
| 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 |
Portnummer gjer skilnaden konkret. TURN lyttar som standard på 3478 for UDP og TCP og på 5349 for TLS, og eit nettverk som tillèt 443 men forkastar desse portane, vil feile på reléa samtalar medan nettsurfing held fram normalt. Å endre porten til VPN-en konfigurerer ingenting av dette, fordi portane som tel høyrer til relétenesta, ikkje tunnelen.
Les diagnostikken, og test deretter samtalen
Nettlesarar viser informasjonen du treng utan pakkefangst. Opne WebRTC-diagnostikksida for nettlesaren din, gjer samtalen, og les det valde kandidatparet i staden for den innsamla lista: kva lokale og eksterne kandidattypar som vart valde, over kva transport og adressefamilie, og om vegen er direkte eller reléa.
To lesemåtar er verdt å kjenne på førehand. Om det valde paret er vert-til-vert på private adresser, blir mediet på ein veg du kan resonnere om; om det er relé-til-relé, brukar samtalen relékapasitet og avheng av tilgjengelegheita til den tenesta. Ein feil som stoppar ved «sjekkar» utan eit valt par betyr at kandidatar vart samla inn, men ingen sto tilkoplingssjekkane.
Samanlikn deretter dei same to endepunkta i same samtale medan du berre endrar éin godkjend føresetnad, og godta resultatet på toveg medie eller data i staden for på ein indikator for tilkopla. Kandidatinnsamling lukkast i mange tilfelle som aldri ber ein einaste lydramme. Gjer samtalen om att på den andre sida av endringa og ta vare på båe dei diagnostiske opptaka, fordi å samanlikne to køyringar seier meir enn å lese éi av dei åleine. Same endepunkt, same kodek, éin endra variabel.
Ein applikasjon som med vilje set ICE-transportpolitikken sin til relay, ber berre om relékandidatar. Den innstillinga lagar ikkje eit relé og reparerer ikkje manglande påloggingsinformasjon; ho gjer kravet eksplisitt, noko som er nyttig når nokon gir VPN-en skulda for ein politikk nettstaden valde.
Hald personvernpåstanden like smal som prova
Kandidateksponering avheng av nettlesaren og applikasjonen sin politikk, ikkje berre av tunnelstatus, og W3C-spesifikasjonen for motpartstilkopling handsamar IP-handtering som si eiga sak. Ein tilkopla VPN er difor eit dårleg grunnlag for å love at ein samtale berre avdekkjer éi vald adresse. To motpartar bak same tunnel kan til og med velje ein veg som aldri forlèt verten, noko som er både ei personvernbetring og ei avgrensing i tilkoplinga.
Det du kan seie presist, er smalare og meir nyttig: kva kandidatpar som vart valt, kva transport som bar det, og om den vegen vart inne i tunnelen. Skriv ned desse tre fakta for ein samtale som verkar og ein som feilar, og skilnaden peikar vanlegvis på komponenten som må rettast.
Når tilkoplinga verkar, skil yting frå nåbarheit. Tap, forseinking, køar og MTU ligg alle nedstraums for eit riktig kandidatpar, og å handsame ein hakkete samtale som ein tilkoplingsfeil sender deg tilbake til kandidatlista utan grunn.