VPN ou relé TURN: cal transporta realmente unha chamada WebRTC?
O túnel cambia a ruta que ve ICE; nunca asigna un relé nin proporciona sinalización. Compare o que achega unha saída VPN e un servidor TURN.
A páxina carga pola VPN, pero a chamada nunca conecta: dous fallos distintos coa mesma barra de enderezos. O túnel cambiou a ruta que usa o navegador; non se converteu nun servizo de sinalización, nun servidor STUN nin nun relé, e non decide que par de candidatos escollerá ICE. Separar a tarefa que cumpre cada compoñente é o que converte un vago “WebRTC está bloqueado” nun fallo concreto.
Catro tarefas, e o túnel só toca unha
A aplicación intercambia información de sesión mediante algún mecanismo de sinalización, e esa é a primeira tarefa. ICE reúne enderezos candidatos e proba pares ata que un funciona, que é a segunda. STUN permite a un par saber como se ve o seu tráfico desde fóra, e TURN asigna un relé para os casos en que non existe unha ruta directa. Esas catro funcións son distintas, e unha VPN afecta os enderezos e o filtrado que atopan en lugar de fornecer calquera delas.
Por iso un inicio de sesión correcto non di nada sobre a ruta dos medios. A sinalización adoita viaxar polo mesmo HTTPS que a páxina xa usa, no porto 443, mentres que os medios poden ir por UDP ata un destino completamente distinto.
O enderezamento privado empeora a confusión. Un enderezo de túnel só é útil para un par cando este ten unha ruta prevista de volta cara a el; ser privado non é proba de alcanzabilidade mutua, e os navegadores non o tratan así cando descartan candidatos que non se poden comprobar. Un candidato que a vostede lle parece local pode ser incomprobable desde o outro lado. Paga a pena descartar esa lagoa antes de concluír que o túnel está a perder medios.
Compare unha saída VPN cun relé TURN
Ambos reenvían paquetes, por iso se confunden, e a táboa comparativa de arriba merece lerse columna por columna e non como unha lista de funcións. A asignación dun relé é un obxecto por sesión creado por unha petición autenticada; un túnel é unha ruta. Un ten credenciais que caducan, o outro ten un enderezo de par que ou é alcanzable ou non o é.
| 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 |
Os números de porto fan concreta a diferenza. TURN escoita por defecto no 3478 para UDP e TCP e no 5349 para TLS, e unha rede que permite o 443 pero descarta eses portos fará fallar as chamadas relayadas mentres a navegación continúa con normalidade. Cambiar o porto da VPN non configura nada diso, porque os portos que importan pertencen ao servizo de relé, non ao túnel.
Lea o diagnóstico e despois probe a chamada
Os navegadores expoñen a información que necesita sen capturar paquetes. Abra a páxina de diagnóstico de WebRTC do seu navegador, faga a chamada e lea o par de candidatos seleccionado en lugar da lista recollida: que tipos de candidato local e remoto se elixiron, por que transporte e familia de enderezos, e se a ruta é directa ou relayada.
Dúas lecturas convén coñecelas de antemán. Se o par seleccionado é host a host en enderezos privados, os medios quedan nunha ruta sobre a que pode razoar; se é relé a relé, a chamada consume capacidade de relé e depende da dispoñibilidade dese servizo. Un fallo que se detén en “comprobando” sen par seleccionado significa que se reuniron candidatos, pero ningún superou as comprobacións de conectividade.
Despois compare os mesmos dous extremos na mesma chamada cambiando só unha condición aprobada, e acepte o resultado por medios ou datos bidireccionais e non por un indicador de conectado. A recollida de candidatos ten éxito en moitos casos que non transportan nin un só fotograma de audio. Repita a chamada no outro lado do cambio e conserve as dúas capturas de diagnóstico, porque comparar dúas execucións informa máis que ler calquera delas soa. Mesmos extremos, mesmo códec, unha variable alterada.
Unha aplicación que fixa deliberadamente a súa política de transporte ICE en relay só pide candidatos de relé. Ese axuste non crea un relé nin repara credenciais ausentes; fai explícito o requisito, o que resulta útil cando alguén culpa a VPN dunha política que elixiu o sitio.
Manteña a afirmación de privacidade tan estreita como as probas
A exposición de candidatos depende da política do navegador e da aplicación, non só do estado do túnel, e a especificación W3C de conexión entre pares trata o manexo de IP como un asunto propio. Unha VPN conectada é, por tanto, unha base pobre para prometer que unha chamada só revela un enderezo elixido. Dous pares tras o mesmo túnel poden incluso elixir unha ruta que nunca sae do host, o que é á vez unha mellora de privacidade e unha restrición de conectividade.
O que pode afirmar con precisión é máis estreito e máis útil: que par de candidatos se seleccionou, que transporte o levou e se esa ruta quedou dentro do túnel. Anote eses tres feitos para unha chamada que funciona e para unha que falla, e a diferenza adoita nomear o compoñente que hai que arranxar.
Unha vez que a conectividade funciona, separe o rendemento da alcanzabilidade. Perda, retardo, colas e MTU están todos augas abaixo dun par de candidatos correcto, e tratar unha chamada entrecortada como un fallo de conectividade devólveo á lista de candidatos sen motivo.