VPN eller TURN-relä: vad bär egentligen ett WebRTC-samtal?
En tunnel ändrar vägen som ICE ser; den tilldelar aldrig ett relä och levererar ingen signalering. Jämför vad en VPN-utgång och en TURN-server erbjuder.
Sidan laddas över VPN:en, men samtalet ansluter aldrig: två olika fel i samma adressfält. Tunneln ändrade vägen som webbläsaren använder; den blev inte en signaleringstjänst, en STUN-server eller ett relä och avgör inte vilket kandidatpar ICE väljer. Det är just åtskillnaden av varje komponents uppgift som gör ett vagt ”WebRTC är blockerat” till ett konkret fel.
Fyra uppgifter, varav tunneln bara berör en
Applikationen utbyter sessionsinformation genom någon form av signaleringsarrangemang, och det är den första uppgiften. ICE samlar kandidatadresser och testar par tills ett fungerar, vilket är den andra. STUN låter en motpart lära sig hur dess trafik ser ut utifrån, och TURN tilldelar ett relä för fall där det inte finns någon direkt väg. Dessa fyra roller är olika, och en VPN påverkar adresserna och filtreringen som de möter i stället för att leverera någon av dem.
Därför säger en lyckad inloggning ingenting om medievägen. Signalering går vanligtvis över samma HTTPS som sidan redan använder, på port 443, medan mediet kan färdas över UDP till en helt annan destination.
Privat adressering förvärrar förvirringen. En tunneladress är bara användbar för en motpart när motparten har en avsedd väg tillbaka till den; att vara privat är inte bevis på ömsesidig nåbarhet, och webbläsare behandlar det inte så när de kastar bort kandidater som inte kan kontrolleras. En kandidat som ser lokal ut för dig kan vara otestsbar från den andra sidan. Det gapet är värt att utesluta innan du drar slutsatsen att tunneln tappar media.
Jämför en VPN-utgång med ett TURN-relä
Båda vidarebefordrar paket, och därför blandas de ihop, och jämförelsetabellen ovan är värd att läsa kolumn för kolumn i stället för som en lista över funktioner. En relätilldelning är ett objekt per session som skapas av en autentiserad begäran; en tunnel är en rutt. Den ena har inloggningsuppgifter som löper ut, den andra har en motpartsadress som antingen är nåbar eller inte.
| 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 gör skillnaden konkret. TURN lyssnar som standard på 3478 för UDP och TCP och på 5349 för TLS, och ett nätverk som tillåter 443 men släpper dessa portar kommer att misslyckas med reläade samtal medan surfandet fortsätter normalt. Att ändra VPN:ens port konfigurerar inget av detta, eftersom portarna som betyder något tillhör relätjänsten, inte tunneln.
Läs diagnostiken och testa sedan samtalet
Webbläsare visar informationen du behöver utan paketinsamling. Öppna WebRTC-diagnostiksidan för din webbläsare, ring samtalet och läs det valda kandidatparet i stället för den insamlade listan: vilka lokala och avlägsna kandidattyper som valdes, över vilken transport och adressfamilj, och om vägen är direkt eller reläad.
Två läsningar är värda att känna till i förväg. Om det valda paret är värd-till-värd på privata adresser stannar mediet på en väg du kan resonera om; om det är relä-till-relä förbrukar samtalet reläkapacitet och beror på den tjänstens tillgänglighet. Ett fel som stannar vid ”kontrollerar” utan ett valt par betyder att kandidater samlades in men ingen klarade anslutningskontrollerna.
Jämför sedan samma två ändpunkter i samma samtal genom att bara ändra ett godkänt villkor, och acceptera resultatet på tvåvägsmedia eller data i stället för på en indikator för ansluten. Kandidatinsamling lyckas i många fall som aldrig bär en enda ljudram. Upprepa samtalet på andra sidan av ändringen och spara båda diagnostiska inspelningarna, eftersom att jämföra två körningar säger mer än att läsa en av dem ensam. Samma ändpunkter, samma codec, en ändrad variabel.
En applikation som medvetet ställer sin ICE-transportpolicy till relay begär bara reläkandidater. Den inställningen skapar inget relä och reparerar inte saknade inloggningsuppgifter; den gör kravet explicit, vilket är användbart när någon skyller på VPN:en för en policy som webbplatsen valde.
Håll integritetspåståendet lika snävt som bevisen
Kandidatexponering beror på webbläsarens och applikationens policy, inte bara på tunnelstatus, och W3C-specifikationen för motpartsanslutning behandlar IP-hantering som sin egen sak. En ansluten VPN är därför en svag grund för att lova att ett samtal bara avslöjar en vald adress. Två motparter bakom samma tunnel kan till och med välja en väg som aldrig lämnar värden, vilket är både en integritetsförbättring och en begränsning i anslutningen.
Det du kan säga exakt är snävare och mer användbart: vilket kandidatpar som valdes, vilken transport som bar det och om den vägen stannade inuti tunneln. Skriv ner dessa tre fakta för ett samtal som fungerar och ett som misslyckas, och skillnaden pekar vanligtvis ut komponenten som behöver åtgärdas.
När anslutningen fungerar, skilj prestanda från nåbarhet. Förlust, fördröjning, köer och MTU ligger alla nedströms om ett korrekt kandidatpar, och att behandla ett hackigt samtal som ett anslutningsfel skickar dig tillbaka till kandidatlistan utan anledning.