O que uma lista de candidatos WebRTC revela sobre a sua VPN
Um candidato host, reflexivo de servidor ou de retransmissão diz de onde veio um endereço. Só o par ICE selecionado diz qual caminho a mídia realmente usou.
Quando uma página de teste WebRTC imprime 172.20.4.15, ela descobriu que existe uma interface local nessa rede. Isso é uma revelação genuína e não é o mesmo achado que «a mídia saiu pela saída da VPN». A descoberta de candidatos e o encaminhamento de pacotes são mecanismos separados, e a maioria dos relatórios de vazamento funde os dois num único veredicto. Qual deles está a ver decide a correção.
A recolha acontece antes de algo ser enviado
O navegador enumera as interfaces locais, envia um pedido de ligação a um servidor STUN e pede uma alocação a um servidor TURN, e depois escreve os resultados na descrição da sessão como linhas de candidatos. Tudo isso termina sem chamada, sem mídia e sem interlocutor. Uma lista de candidatos é, portanto, um registo da descoberta, não do transporte.
Os navegadores modernos podem substituir o endereço literal de um candidato host por um nome mDNS .local, de modo que a página não consegue ler o IP privado. A rede local continua a ver as consultas de multidifusão que resolvem esse nome, por isso o endereço fica escondido da aplicação em vez de ser removido do cabo.
A ordem também importa: um novo carregamento da página recolhe um novo conjunto, com outra alocação TURN e possivelmente outro mapeamento reflexivo. Duas execuções que não coincidem não são necessariamente duas configurações diferentes.
Três tipos de candidatos, três tipos de provas
Cada linha vem de uma observação diferente. Cada tipo responde a uma pergunta diferente, e a tabela separa-os pelo que podem e não podem estabelecer.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
Um candidato de retransmissão é rotineiramente confundido com o endereço de internet do utilizador. Pertence ao servidor TURN, e a sua presença mostra que havia uma retransmissão disponível, não que o navegador a tenha escolhido. A mesma confusão vai no sentido oposto com os candidatos host, onde um nome mDNS esconde o endereço à página enquanto a rede continua a transportar as consultas. Leia o tipo antes de ler o valor.
O par selecionado responde à pergunta do encaminhamento
O ICE emparelha cada candidato local com cada um remoto, executa verificações de conectividade em cada par e nomeia um vencedor. Esse par nomeado, visível nos diagnósticos do próprio navegador, transporta a mídia. Tudo o resto na lista é uma possibilidade que perdeu.
O vencedor diz-lhe a forma do caminho. De retransmissão para retransmissão passa pelo servidor TURN, um par host fica na rede local e um par reflexivo de servidor vai direto através do NAT. Esse é o facto de que uma verificação de VPN precisa, e é um facto diferente do da lista de endereços. Duas chamadas com listas de candidatos idênticas podem usar pares diferentes.
Os candidatos não selecionados foram recolhidos de qualquer forma, e a recolha é tráfego de rede que sai da máquina. Uma chamada que acabou por usar a retransmissão não significa que nada tenha sido revelado enquanto a lista era construída.
Os controlos correspondem a objetivos, não a uma pontuação de fuga
A especificação de gestão de IP do WebRTC descreve várias políticas: usar apenas a interface que transporta a rota predefinida, usar todas as interfaces e desativar o UDP sem proxy para que o tráfego tenha de passar por uma retransmissão ou um proxy. Cada uma troca conectividade e latência por um tipo diferente de exposição. Qual o navegador implementa, e com que nome, varia conforme a plataforma e a versão.
Escolha a política a partir do objetivo. Esconder os endereços locais de uma página é um objetivo; impedir o tráfego direto entre pares é outro; manter cada pacote dentro do túnel é um terceiro. O primeiro trata sobretudo do que a aplicação aprende, o segundo de que caminho é permitido, e o terceiro tem de ser imposto também na fronteira da plataforma ou da VPN.
Seja qual for o controlo que escolher, verifique as duas metades: execute o teste de recolha e registe os tipos de candidatos, e depois inspecione o par selecionado durante uma sessão real. Uma lista de endereços limpa com um caminho de mídia direto continua a ser um caminho que não pretendia.