VPN sau releu TURN: care transportă de fapt un apel WebRTC?
Tunelul schimbă calea pe care o vede ICE; nu alocă niciodată un releu și nu oferă semnalizare. Comparați ce oferă o ieșire VPN și un server TURN.
Pagina se încarcă prin VPN, dar apelul nu se conectează niciodată: două defecțiuni diferite în aceeași bară de adrese. Tunelul a schimbat calea folosită de browser; nu a devenit un serviciu de semnalizare, un server STUN sau un releu și nu decide ce pereche de candidați va alege ICE. Tocmai separarea sarcinii fiecărei componente transformă un vag „WebRTC este blocat” într-o defecțiune concretă.
Patru sarcini, iar tunelul atinge doar una
Aplicația schimbă informații de sesiune printr-o anumită soluție de semnalizare, iar aceasta este prima sarcină. ICE adună adrese candidate și testează perechi până când una funcționează, care este a doua. STUN îi permite unui partener să afle cum arată traficul său din exterior, iar TURN alocă un releu pentru cazurile în care nu există o cale directă. Aceste patru roluri sunt distincte, iar o VPN afectează adresele și filtrarea pe care le întâlnesc în loc să ofere vreunul dintre ele.
De aceea o autentificare reușită nu spune nimic despre calea media. Semnalizarea călătorește de obicei pe același HTTPS pe care pagina îl folosește deja, pe portul 443, în timp ce media poate merge prin UDP către o destinație complet diferită.
Adresarea privată agravează confuzia. O adresă de tunel este utilă unui partener doar când acesta are o cale intenționată înapoi spre ea; a fi privată nu este dovadă de accesibilitate reciprocă, iar browserele nu o tratează astfel când elimină candidați care nu pot fi verificați. Un candidat care vi se pare local poate fi netestabil din cealaltă parte. Merită să eliminați acest gol înainte de a concluziona că tunelul pierde media.
Comparați o ieșire VPN cu un releu TURN
Ambele redirecționează pachete, de aceea sunt confundate, iar tabelul comparativ de mai sus merită citit coloană cu coloană, nu ca o listă de funcții. Alocarea unui releu este un obiect pe sesiune creat de o cerere autentificată; un tunel este o rută. Unul are credențiale care expiră, celălalt are o adresă de partener care fie este accesibilă, fie nu.
| 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 |
Numerele de port fac diferența concretă. TURN ascultă implicit pe 3478 pentru UDP și TCP și pe 5349 pentru TLS, iar o rețea care permite 443 dar aruncă acele porturi va eșua apelurile relayate în timp ce navigarea continuă normal. Schimbarea portului VPN nu configurează nimic din asta, pentru că porturile importante aparțin serviciului de releu, nu tunelului.
Citiți diagnosticul, apoi testați apelul
Browserele expun informațiile necesare fără captură de pachete. Deschideți pagina de diagnostic WebRTC a browserului, faceți apelul și citiți perechea de candidați selectată în locul listei colectate: ce tipuri de candidați locali și la distanță au fost alese, prin ce transport și familie de adrese, și dacă calea este directă sau relayată.
Două lecturi merită cunoscute dinainte. Dacă perechea selectată este gazdă-la-gazdă pe adrese private, media rămâne pe o cale despre care se poate raționa; dacă este releu-la-releu, apelul consumă capacitate de releu și depinde de disponibilitatea acelui serviciu. O defecțiune care se oprește la „se verifică” fără pereche selectată înseamnă că s-au adunat candidați, dar niciunul nu a trecut verificările de conectivitate.
Apoi comparați aceleași două capete în același apel schimbând doar o condiție aprobată, și acceptați rezultatul pe media sau date bidirecționale, nu pe un indicator „conectat”. Colectarea candidaților reușește în multe cazuri care nu transportă nici un cadru audio. Repetați apelul de cealaltă parte a schimbării și păstrați ambele capturi de diagnostic, pentru că a compara două rulări spune mai mult decât a citi oricare singură. Aceleași capete, același codec, o variabilă schimbată.
O aplicație care își setează deliberat politica de transport ICE pe relay cere doar candidați de releu. Această setare nu creează un releu și nu repară credențialele lipsă; face cerința explicită, ceea ce este util când cineva dă vina pe VPN pentru o politică aleasă de site.
Păstrați afirmația despre confidențialitate la fel de îngustă ca dovezile
Expunerea candidaților depinde de politica browserului și a aplicației, nu doar de starea tunelului, iar specificația W3C pentru conexiunea între parteneri tratează gestionarea IP ca pe o chestiune proprie. Prin urmare, un VPN conectat este o bază slabă pentru a promite că un apel dezvăluie doar o adresă aleasă. Doi parteneri din spatele aceluiași tunel pot chiar alege o cale care nu părăsește niciodată gazda, ceea ce este simultan o îmbunătățire a confidențialității și o restricție de conectivitate.
Ce puteți afirma cu precizie este mai îngust și mai util: ce pereche de candidați a fost selectată, ce transport a purtat-o și dacă acea cale a rămas în interiorul tunelului. Notați aceste trei fapte pentru un apel care funcționează și pentru unul care eșuează, iar diferența numește de obicei componenta de reparat.
Odată ce conectivitatea funcționează, separați performanța de accesibilitate. Pierdere, întârziere, cozi și MTU stau toate în aval de o pereche corectă de candidați, iar tratarea unui apel sacadat ca defecțiune de conectivitate vă trimite înapoi la lista de candidați fără motiv.