VPN eller TURN-relay: hva bærer egentlig en WebRTC-samtale?
En tunnel endrer veien ICE ser; den tildeler aldri en relay og leverer ikke signalering. Sammenlign hva en VPN-utgang og en TURN-server hver tilbyr.
Siden lastes over VPN-en, men samtalen kobles aldri til: to forskjellige feil i samme adresselinje. Tunnelen endret veien nettleseren bruker; den ble ikke en signaleringstjeneste, en STUN-server eller en relay, og den bestemmer ikke hvilket kandidatpar ICE velger. Det er nettopp skillet mellom oppgavene hver komponent løser som gjør en vag «WebRTC er blokkert» til en konkret feil.
Fire oppgaver, hvorav tunnelen bare berører én
Applikasjonen utveksler sesjonsinformasjon gjennom en eller annen ordning for signalering, og det er den første oppgaven. ICE samler kandidatadresser og tester par til ett virker, som er den andre. STUN lar en motpart lære hvordan trafikken ser ut utenfra, og TURN tildeler en relay for tilfeller der det ikke finnes noen direkte vei. Disse fire rollene er forskjellige, og en VPN påvirker adressene og filtreringen de møter i stedet for å levere noen av dem.
Derfor sier en vellykket innlogging ingenting om medieveien. Signalering går vanligvis over den samme HTTPS-en som siden allerede bruker, på port 443, mens mediet kan reise over UDP til en helt annen destinasjon.
Privat adressering gjør forvirringen verre. En tunneladresse er bare nyttig for en motpart når motparten har en tiltenkt vei tilbake til den; å være privat er ikke bevis for gjensidig nåbarhet, og nettlesere behandler det ikke slik når de forkaster kandidater som ikke kan kontrolleres. En kandidat som ser lokal ut for deg, kan være utestbar fra den andre siden. Det gapet er verdt å utelukke før du konkluderer med at tunnelen slipper mediet.
Sammenlign en VPN-utgang med en TURN-relay
Begge videresender pakker, og derfor blandes de sammen, og sammenligningstabellen over er verdt å lese kolonne for kolonne i stedet for som en liste over funksjoner. En relay-tildeling er et objekt per sesjon laget av en autentisert forespørsel; en tunnel er en rute. Den ene har påloggingsinformasjon som utløper, den andre har en motpartsadresse som enten er nåbar eller ikke.
| 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 |
Portnumre gjør forskjellen konkret. TURN lytter som standard på 3478 for UDP og TCP og på 5349 for TLS, og et nettverk som tillater 443 men forkaster disse portene, vil feile på relayede samtaler mens nettlesing fortsetter normalt. Å endre porten til VPN-en konfigurerer ingenting av dette, fordi portene som betyr noe tilhører relay-tjenesten, ikke tunnelen.
Les diagnostikken, og test deretter samtalen
Nettlesere viser informasjonen du trenger uten pakkefangst. Åpne WebRTC-diagnostikksiden for nettleseren din, foreta samtalen, og les det valgte kandidatparet i stedet for den innsamlede listen: hvilke lokale og eksterne kandidattyper som ble valgt, over hvilken transport og adressefamilie, og om veien er direkte eller relayet.
To lesemåter er verdt å kjenne på forhånd. Hvis det valgte paret er vert-til-vert på private adresser, blir mediet på en vei du kan resonnere om; hvis det er relay-til-relay, bruker samtalen relay-kapasitet og avhenger av tilgjengeligheten til den tjenesten. En feil som stopper ved «sjekker» uten et valgt par betyr at kandidater ble samlet inn, men ingen besto tilkoblingssjekkene.
Sammenlign deretter de samme to endepunktene i samme samtale mens du bare endrer én godkjent betingelse, og godta resultatet på toveis medie eller data i stedet for på en indikator for tilkoblet. Kandidatinnsamling lykkes i mange tilfeller som aldri bærer en eneste lydramme. Gjenta samtalen på den andre siden av endringen og ta vare på begge de diagnostiske opptakene, fordi å sammenligne to kjøringer sier mer enn å lese én av dem alene. Samme endepunkter, samme kodek, én endret variabel.
En applikasjon som bevisst setter ICE-transportpolitikken sin til relay, ber bare om relaykandidater. Den innstillingen lager ikke en relay og reparerer ikke manglende påloggingsinformasjon; den gjør kravet eksplisitt, noe som er nyttig når noen gir VPN-en skylden for en politikk nettstedet valgte.
Hold personvernpåstanden like snever som bevisene
Kandidateksponering avhenger av nettleserens og applikasjonens politikk, ikke bare av tunnelstatus, og W3C-spesifikasjonen for motpartstilkobling behandler IP-håndtering som sin egen sak. En tilkoblet VPN er derfor et dårlig grunnlag for å love at en samtale bare avslører én valgt adresse. To motparter bak samme tunnel kan til og med velge en vei som aldri forlater verten, noe som er både en personvernforbedring og en begrensning i tilkoblingen.
Det du kan si presist, er snevrere og mer nyttig: hvilket kandidatpar som ble valgt, hvilken transport som bar det, og om den veien ble inne i tunnelen. Skriv ned disse tre fakta for en samtale som virker og en som feiler, og forskjellen peker vanligvis på komponenten som må rettes.
Når tilkoblingen virker, skill ytelse fra nåbarhet. Tap, forsinkelse, køer og MTU ligger alle nedstrøms for et riktig kandidatpar, og å behandle en hakkete samtale som en tilkoblingsfeil sender deg tilbake til kandidatlisten uten grunn.