VPN ou relé TURN: o que realmente carrega uma chamada WebRTC?
O túnel muda o caminho que o ICE vê; nunca aloca um relé nem fornece sinalização. Compare o que uma saída VPN e um servidor TURN oferecem.
A página carrega pela VPN, mas a chamada nunca conecta: duas falhas diferentes na mesma barra de endereços. O túnel mudou o caminho que o navegador usa; não se tornou um serviço de sinalização, um servidor STUN nem um relé, e não decide qual par de candidatos o ICE vai escolher. Separar a tarefa que cada componente cumpre é o que transforma um vago “o WebRTC está bloqueado” numa falha concreta.
Quatro tarefas, e o túnel toca apenas uma
A aplicação troca informações de sessão por algum arranjo de sinalização, e essa é a primeira tarefa. O ICE reúne endereços candidatos e testa pares até um funcionar, que é a segunda. O STUN permite a um par saber como o seu tráfego aparece de fora, e o TURN aloca um relé para os casos em que não existe caminho direto. Esses quatro papéis são distintos, e uma VPN afeta os endereços e a filtragem que eles encontram em vez de fornecer qualquer um deles.
Por isso um login bem-sucedido não diz nada sobre o caminho das mídias. A sinalização costuma viajar pelo mesmo HTTPS que a página já usa, na porta 443, enquanto as mídias podem seguir por UDP até um destino completamente diferente.
O endereçamento privado piora a confusão. Um endereço de túnel só é útil para um par quando esse par tem um caminho pretendido de volta até ele; ser privado não é prova de alcançabilidade mútua, e os navegadores não tratam assim quando descartam candidatos que não podem ser verificados. Um candidato que lhe parece local pode ser não testável do outro lado. Vale a pena descartar essa lacuna antes de concluir que o túnel está derrubando mídia.
Compare uma saída VPN com um relé TURN
Ambos encaminham pacotes, por isso são confundidos, e a tabela de comparação acima merece ser lida coluna por coluna e não como uma lista de recursos. A alocação de um relé é um objeto por sessão criado por uma requisição autenticada; um túnel é uma rota. Um tem credenciais que expiram, o outro tem um endereço de par que ou é alcançável ou nã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 porta tornam a diferença concreta. O TURN escuta por padrão na 3478 para UDP e TCP e na 5349 para TLS, e uma rede que permite a 443 mas descarta essas portas fará falhar as chamadas relayadas enquanto a navegação continua normalmente. Mudar a porta da VPN não configura nada disso, porque as portas que importam pertencem ao serviço de relé, não ao túnel.
Leia o diagnóstico e depois teste a chamada
Os navegadores expõem as informações necessárias sem captura de pacotes. Abra a página de diagnóstico do WebRTC do seu navegador, faça a chamada e leia o par de candidatos selecionado em vez da lista coletada: quais tipos de candidato local e remoto foram escolhidos, por qual transporte e família de endereços, e se o caminho é direto ou relayado.
Duas leituras vale a pena conhecer de antemão. Se o par selecionado é host a host em endereços privados, as mídias ficam num caminho sobre o qual é possível raciocinar; se é relé a relé, a chamada consome capacidade de relé e depende da disponibilidade desse serviço. Uma falha que para em “verificando” sem par selecionado significa que candidatos foram coletados, mas nenhum passou nas verificações de conectividade.
Depois compare os mesmos dois extremos na mesma chamada mudando apenas uma condição aprovada, e aceite o resultado com base em mídia ou dados bidirecionais e não num indicador de “conectado”. A coleta de candidatos tem sucesso em muitos casos que não transportam um único quadro de áudio. Repita a chamada do outro lado da mudança e guarde as duas capturas de diagnóstico, porque comparar duas execuções informa mais do que ler qualquer uma delas sozinha. Mesmos extremos, mesmo codec, uma variável alterada.
Uma aplicação que define deliberadamente sua política de transporte ICE como relay só pede candidatos de relé. Esse ajuste não cria um relé nem corrige credenciais ausentes; torna o requisito explícito, o que é útil quando alguém culpa a VPN por uma política que o site escolheu.
Mantenha a afirmação de privacidade tão estreita quanto as provas
A exposição dos candidatos depende da política do navegador e da aplicação, não apenas do estado do túnel, e a especificação W3C de conexão entre pares trata o tratamento de IP como assunto próprio. Uma VPN conectada é, portanto, uma base fraca para prometer que uma chamada revela apenas um endereço escolhido. Dois pares atrás do mesmo túnel podem até escolher um caminho que nunca sai do host, o que é ao mesmo tempo uma melhoria de privacidade e uma restrição de conectividade.
O que você pode afirmar com precisão é mais estreito e mais útil: qual par de candidatos foi selecionado, qual transporte o carregou e se esse caminho ficou dentro do túnel. Anote esses três fatos para uma chamada que funciona e para uma que falha, e a diferença geralmente nomeia o componente que precisa ser corrigido.
Quando a conectividade funciona, separe desempenho de alcançabilidade. Perda, atraso, filas e MTU ficam todos a jusante de um par de candidatos correto, e tratar uma chamada travada como falha de conectividade devolve você à lista de candidatos sem motivo.