VPN kontra TURN-relay: hvad bærer egentlig et WebRTC-opkald?
En tunnel ændrer den vej, ICE ser; den tildeler aldrig en relay og leverer ikke signalering. Sammenlign, hvad en VPN-udgang og en TURN-server hver især giver.
Siden indlæses over VPN’en, men opkaldet bliver aldrig forbundet: to forskellige fejl med samme adresselinje. Tunnelen ændrede den vej, browseren bruger; den blev ikke en signaleringstjeneste, en STUN-server eller en relay, og den bestemmer ikke, hvilket kandidatpar ICE vælger. Det er adskillelsen af den opgave, hver komponent løser, der forvandler et vagt “WebRTC er blokeret” til en konkret fejl.
Fire opgaver, hvoraf tunnelen kun rører én
Applikationen udveksler sessionsoplysninger gennem en eller anden signaleringsordning, og det er den første opgave. ICE indsamler kandidatadresser og tester par, indtil et virker, hvilket er den anden. STUN lader en peer lære, hvordan dens trafik ser ud udefra, og TURN tildeler en relay til tilfælde, hvor der ikke findes nogen direkte vej. De fire roller er forskellige, og en VPN påvirker de adresser og den filtrering, de møder, i stedet for at levere nogen af dem.
Derfor siger et vellykket login intet om mediebanen. Signalering kører normalt over den samme HTTPS, som siden allerede bruger, på port 443, mens mediet kan rejse over UDP til en helt anden destination.
Privat adressering gør forvirringen værre. En tunneladresse er kun nyttig for en peer, når den peer har en tiltænkt vej tilbage til den; at være privat er ikke bevis for gensidig tilgængelighed, og browsere behandler det ikke sådan, når de kasserer kandidater, der ikke kan kontrolleres. En kandidat, der ser lokal ud for dig, kan være utestbar fra den anden side. Det gab er værd at udelukke, før du konkluderer, at tunnelen taber mediet.
Sammenlign en VPN-udgang med en TURN-relay
Begge videresender pakker, og derfor blandes de sammen, og sammenligningstabellen ovenfor er værd at læse kolonne for kolonne i stedet for som en liste af funktioner. En relay-tildeling er et objekt pr. session, oprettet af en autentificeret anmodning; en tunnel er en rute. Den ene har legitimationsoplysninger, der udløber, den anden har en peer-adresse, der enten er tilgængelig 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 gør forskellen konkret. TURN lytter som standard på 3478 for UDP og TCP og på 5349 for TLS, og et netværk, der tillader 443, men dropper disse porte, vil fejle på relayede opkald, mens browsing fortsætter normalt. At ændre VPN’ens port konfigurerer intet af det, fordi de porte, der betyder noget, tilhører relaytjenesten, ikke tunnelen.
Læs diagnostikken, og test derefter opkaldet
Browsere viser de oplysninger, du har brug for, uden en pakkefangst. Åbn WebRTC-diagnostiksiden for din browser, foretag opkaldet, og læs det valgte kandidatpar i stedet for den indsamlede liste: hvilke lokale og fjernkandidattyper der blev valgt, over hvilken transport og adressefamilie, og om vejen er direkte eller relayet.
To aflæsninger er værd at kende på forhånd. Hvis det valgte par er vært-til-vært på private adresser, bliver mediet på en vej, du kan ræsonnere om; hvis det er relay-til-relay, bruger opkaldet relaykapacitet og afhænger af den tjenestes tilgængelighed. En fejl, der stopper ved “kontrollerer” uden et valgt par, betyder, at kandidater blev indsamlet, men ingen bestod forbindelseskontrollerne.
Sammenlign derefter de samme to endepunkter i det samme opkald, mens du kun ændrer én godkendt betingelse, og accepter resultatet på tovejsmedie eller -data i stedet for på en indikator for forbundet. Kandidatindsamling lykkes i mange tilfælde, der aldrig bærer en eneste lydramme. Gentag opkaldet på den anden side af ændringen, og gem begge diagnostiske optagelser, fordi sammenligning af to kørsler er mere oplysende end at læse en af dem alene. Samme endepunkter, samme codec, én variabel ændret.
En applikation, der bevidst sætter sin ICE-transportpolitik til relay, beder kun om relaykandidater. Den indstilling opretter ikke en relay og reparerer ikke manglende legitimationsoplysninger; den gør kravet eksplicit, hvilket er nyttigt, når nogen giver VPN’en skylden for en politik, som webstedet valgte.
Hold privatlivspåstanden så snæver som bevismaterialet
Kandidateksponering afhænger af browserens og applikationens politik, ikke kun af tunnelstatus, og W3C’s specifikation for peer-forbindelse behandler IP-håndtering som sit eget anliggende. En tilsluttet VPN er derfor et dårligt grundlag for at love, at et opkald kun afslører én valgt adresse. To peers bag samme tunnel kan endda vælge en vej, der aldrig forlader værten, hvilket er en forbedring af privatlivet og en begrænsning af forbindelsen på samme tid.
Det, du præcist kan sige, er snævrere og mere nyttigt: hvilket kandidatpar der blev valgt, hvilken transport der bar det, og om den vej blev inde i tunnelen. Skriv de tre fakta ned for et fungerende opkald og for et fejlende, og forskellen peger som regel på den komponent, der skal rettes.
Når forbindelsen virker, så adskil ydeevne fra tilgængelighed. Tab, forsinkelse, kødannelse og MTU ligger alle nedstrøms for et korrekt kandidatpar, og at behandle et hakket opkald som en forbindelsesfejl sender dig tilbage til kandidatlisten uden grund.