VPN alebo relay TURN: čo vlastne prenáša hovor WebRTC?
Tunel mení cestu, ktorú vidí ICE; nikdy nepridelí relay ani neposkytuje signalizáciu. Porovnajte, čo ponúka výstup VPN a server TURN.
Stránka sa načíta cez VPN, no hovor sa nikdy nepripojí: dve rôzne poruchy s tou istou adresnou lištou. Tunel zmenil cestu, ktorú prehliadač používa; nestal sa službou signalizácie, serverom STUN ani relay a nerozhoduje, ktorú dvojicu kandidátov ICE vyberie. Práve oddelenie úlohy jednotlivých komponentov mení neurčité „WebRTC je zablokované“ na konkrétnu poruchu.
Štyri úlohy, z ktorých sa tunel dotýka jedinej
Aplikácia si vymieňa informácie o relácii cez nejaké usporiadanie signalizácie, a to je prvá úloha. ICE zhromažďuje adresy kandidátov a testuje dvojice, kým jedna nefunguje, čo je druhá. STUN umožňuje protistrane zistiť, ako jej prevádzka vyzerá zvonku, a TURN pridelí relay pre prípady, keď neexistuje priama cesta. Tieto štyri role sú odlišné a VPN ovplyvňuje adresy a filtrovanie, s ktorými sa stretávajú, namiesto toho, aby niektorú z nich poskytoval.
Preto úspešné prihlásenie nič nehovorí o ceste médií. Signalizácia zvyčajne ide po tom istom HTTPS, ktoré stránka už používa, na porte 443, zatiaľ čo médiá môžu putovať cez UDP do úplne iného cieľa.
Súkromné adresovanie zmätok zhoršuje. Adresa tunela je pre protistranu užitočná len vtedy, keď má k nej zamýšľanú cestu späť; to, že je súkromná, nie je dôkazom vzájomnej dostupnosti a prehliadače to tak neberú, keď zahadzujú kandidátov, ktorých nemožno overiť. Kandidát, ktorý sa vám zdá lokálny, môže byť z druhej strany neoveriteľný. Túto medzeru stojí za to vylúčiť skôr, než uzavriete, že tunel zahadzuje médiá.
Porovnajte výstup VPN s relay TURN
Oba preposielajú pakety, a preto sa zamieňajú, a porovnávaciu tabuľku vyššie stojí za to čítať stĺpec po stĺpci, nie ako zoznam funkcií. Pridelenie relay je objekt pre každú reláciu vytvorený autentizovanou požiadavkou; tunel je trasa. Jedno má prihlasovacie údaje, ktoré vypršia, druhé má adresu protistrany, ktorá buď dostupná je, alebo 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 |
Čísla portov robia rozdiel konkrétnym. TURN v predvolenom nastavení načúva na 3478 pre UDP a TCP a na 5349 pre TLS, a sieť, ktorá povolí 443, ale tieto porty zahodí, neuspeje pri relayovaných hovoroch, zatiaľ čo prehliadanie pokračuje normálne. Zmena portu VPN nič z toho nenastaví, pretože dôležité porty patria službe relay, nie tunelu.
Prečítajte si diagnostiku a potom hovor otestujte
Prehliadače ukazujú potrebné informácie bez zachytávania paketov. Otvorte diagnostickú stránku WebRTC pre svoj prehliadač, uskutočnite hovor a čítajte vybranú dvojicu kandidátov, nie zhromaždený zoznam: ktoré typy lokálnych a vzdialených kandidátov boli zvolené, cez aký transport a rodinu adries a či je cesta priama alebo relayovaná.
Dve čítania je dobré poznať vopred. Ak je vybraná dvojica hostiteľ-hostiteľ na súkromných adresách, médiá zostávajú na ceste, o ktorej možno uvažovať; ak ide o relay-relay, hovor spotrebúva kapacitu relay a závisí od dostupnosti tejto služby. Porucha, ktorá sa zastaví na „kontrola“ bez vybranej dvojice, znamená, že kandidáti boli zhromaždení, ale žiadny neprešiel kontrolami konektivity.
Potom porovnajte tie isté dva koncové body v tom istom hovore so zmenou jedinej schválenej podmienky a výsledok prijmite podľa obojsmerných médií alebo dát, nie podľa indikátora „pripojené“. Zhromažďovanie kandidátov uspeje v mnohých prípadoch, ktoré neprenášajú jediný zvukový rámec. Zopakujte hovor na druhej strane zmeny a uchovajte oba diagnostické záznamy, pretože porovnanie dvoch behov je informatívnejšie než čítanie ktoréhokoľvek z nich samostatne. Rovnaké koncové body, rovnaký kodek, jedna zmenená premenná.
Aplikácia, ktorá zámerne nastaví svoju transportnú politiku ICE na relay, žiada len kandidátov relay. Toto nastavenie relay nevytvára a neopravuje chýbajúce prihlasovacie údaje; robí požiadavku explicitnou, čo je užitočné, keď niekto obviňuje VPN z politiky, ktorú zvolil web.
Držte tvrdenie o súkromí tak úzke, ako dovoľujú dôkazy
Vystavenie kandidátov závisí od politiky prehliadača a aplikácie, nielen od stavu tunela, a špecifikácia W3C pre prepojenie protistrán považuje zaobchádzanie s IP za vlastnú záležitosť. Pripojená VPN je preto slabý základ pre sľub, že hovor prezradí len jednu zvolenú adresu. Dve protistrany za tým istým tunelom môžu dokonca zvoliť cestu, ktorá nikdy neopustí hostiteľa, čo je súčasne zlepšenie súkromia aj obmedzenie konektivity.
Čo môžete povedať presne, je užšie a užitočnejšie: ktorá dvojica kandidátov bola vybraná, ktorý transport ju niesol a či táto cesta zostala vnútri tunela. Zapíšte tieto tri skutočnosti pre fungujúci aj zlyhávajúci hovor, a rozdiel zvyčajne pomenuje komponent, ktorý treba opraviť.
Keď konektivita funguje, oddeľte výkon od dosiahnuteľnosti. Strata, oneskorenie, fronty a MTU ležia všetky po prúde správnej dvojice kandidátov, a liečba trhaného hovoru ako poruchy konektivity vás bez dôvodu vracia k zoznamu kandidátov.