O que uma resposta STUN revela quando a VPN roda no roteador

Quando o túnel vive no roteador, a máquina que executa o navegador não tem nenhuma interface de túnel. Peça a essa máquina seus endereços locais e você obtém um endereço LAN privado e um loopback, nada que se pareça com um endereço VPN. Ainda assim, um servidor STUN do outro lado pode relatar algo significativo sobre o caminho, e o que ele relata depende inteiramente de como aquele pedido específico foi encaminhado e traduzido.

Essa é a parte que merece ir mais devagar. «O navegador não possui o endereço VPN» responde a uma pergunta sobre interfaces, enquanto um endereço refletido é uma resposta sobre um caminho através da tradução. Confundir as duas coisas produz conclusões confiantes sobre divulgação que as evidências não sustentam.

Dois dispositivos, dois conjuntos de interfaces

Numa configuração baseada em roteador, o túnel termina no roteador e o cliente da LAN envia tráfego comum para o seu gateway padrão. A lista de interfaces do cliente permanece curta: um endereço privado, talvez um segundo para outra rede, e o loopback. O risco não é que um deles seja por acaso o endereço do túnel; é que o pedido saia por um caminho que você não escolheu.

Pergunte ao cliente que caminho um destino específico tomaria em vez de perguntar que interfaces existem. A resposta nomeia um gateway e o endereço de origem que o núcleo usaria, o que já é mais informativo do que qualquer inventário de endereços.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

As faixas de documentação são bons destinos de teste porque nunca se resolvem num serviço real. Compare o que o cliente diz com o que o roteador diz, e trate qualquer discordância como prova de que o encaminhamento por políticas, uma regra de túnel dividido ou uma segunda rota padrão está a fazer algo que você não considerou.

O que uma resposta Binding pode dizer

RFC 8489 define o pedido e a resposta Binding, em que o servidor relata o endereço de transporte de origem que observou para esse pedido. É uma afirmação sobre uma quíntupla num instante, não um censo das interfaces do cliente. Por isso tudo o que é interessante acontece entre o cliente e o ponto de observação.

Essa lacuna é preenchida pelo encaminhamento e pela tradução. Um roteador que faz NAT de origem no tráfego de saída substitui a origem privada do cliente pelo seu próprio endereço na interface de saída. Se essa interface é o túnel, o refletor vê o endereço do túnel. Se o pacote ficou excluído do túnel, o refletor vê o que a tradução da WAN produziu. O mesmo cliente, o mesmo refletor, uma resposta diferente.

Três casos que parecem iguais e não são

A distinção útil não é público versus privado, mas qual ponto de controlo tratou o pacote. Trabalhe os casos com as tabelas do próprio roteador abertas, porque um só navegador pode produzir os três conforme uma regra que você esqueceu de ter escrito.

Só o segundo caso viola o requisito de que certo tráfego nunca saia diretamente, e só o primeiro e o terceiro revelam um identificador do lado do túnel. Nenhuma das três linhas é uma afirmação sobre o comportamento de um fornecedor concreto: se um refletor privado é alcançável depende do encaminhamento, dos endereços IP permitidos do outro extremo e da política da firewall nos dois extremos.

Ter uma conta no mesmo fornecedor não estabelece nada disso. Também vale lembrar que um pedido encaminhado pode conservar a origem LAN do cliente se nada a traduzir, portanto o campo de origem tem de ser rastreado em vez de suposto a partir do diagrama de topologia.

Recolher não é selecionar

O WebRTC recolhe endereços candidatos para testar, e um candidato que aparece numa lista de diagnóstico pode nunca ter transportado mídia. Ler a lista como «isto é o que o outro extremo aprendeu» exagera a evidência. O par selecionado é o que transportou realmente a sessão, e vive noutro campo.

Um verificador de saída HTTPS responde a outra pergunta: o endereço de origem que um servidor web viu para esse pedido. É uma verificação cruzada útil precisamente porque usa um protocolo diferente e muitas vezes um destino diferente de um refletor UDP, e a discrepância entre os dois costuma apontar para uma regra de encaminhamento e não para um erro.

Decida a política e depois leia a resposta

Escreva a intenção antes de testar: que tráfego deve usar o túnel, qual pode sair diretamente, que famílias de endereços estão no âmbito e o que deve acontecer quando o túnel está em baixo. Sem essa linha de base, toda a observação é ambígua, porque não consegue separar uma fuga de um caminho que permitiu deliberadamente.

Depois faça uma pergunta de cada vez. Que caminho toma este destino. Que endereço relata este refletor. Que par candidato selecionou a sessão. Guarde as respostas ao lado da política e date-as, porque uma atualização de firmware pode mudar o comportamento padrão de formas que invalidam silenciosamente a conclusão do ano passado.

O roteador continua a ser um ponto de controlo sólido, porque vê tráfego que um cliente não pode contornar sem se reconfigurar a si mesmo. Não é uma promessa de que cada campo de cada protocolo de aplicação não revele nada, nem substitui escrever os caminhos que decidiu permitir.