Por que um hotspot redireciona o DNS antes de a VPN se conectar?
Um hotspot reescreve as consultas na própria rede, e um endpoint com nome de host é resolvido antes de existir qualquer túnel. Rastreie qual resolvedor respondeu a cada consulta.
Entrar numa rede de hotel coloca duas decisões de DNS à sua frente em momentos diferentes: as consultas que o dispositivo faz ao iniciar sessão e as consultas feitas depois de o túnel estar de pé. Um hotspot pode influenciar as primeiras através da rede que controla. As segundas dependem da política do próprio cliente, que é algo separado a inspecionar.
Percorra a conexão por ordem, desde a primeira concessão DHCP até à consulta que resolveu um nome privado. Então duas falhas que num ticket de suporte parecem idênticas separam-se com clareza: uma ocorreu antes de o túnel existir e a outra ocorreu dentro dele.
O que o hotspot pode e não pode tocar
A rede de acesso entrega um endereço de resolvedor por DHCP e pode intercetar a porta 53 para esse endereço. Isso basta para responder a cada consulta desprotegida com um endereço de portal ou uma página de bloqueio. Também basta para quebrar um cliente VPN cujo endpoint está escrito como nome de host.
O que o hotspot não pode é ler ou reescrever uma consulta depois de ela viajar dentro de um túnel estabelecido, supondo que o túnel realmente a transporta. A interceção depende de ver a pergunta em texto simples.
As consultas saem do túnel de qualquer forma por motivos alheios ao hotspot: a definição de DNS seguro do navegador, uma regra de split-DNS que mantém um sufixo corporativo no resolvedor local, ou um cliente configurado para excluir o DNS do túnel. Cada uma é uma escolha do lado do cliente, e cada uma parece interferência do hotspot quando vista de fora.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
A consulta inicial acontece antes de o túnel existir
Um cliente a quem se dá um nome de host tem de o resolver primeiro, e nesse instante nenhum túnel protege a consulta. Se o hotspot responder com um endereço de portal, a negociação falha ou encrava. Se responder com nada, o cliente comunica um erro de nome e o túnel nunca arranca. Qualquer dos dois desfechos explica um registo de túnel vazio que de outra forma parece inocente.
Os sistemas operativos também executam as suas próprias verificações de conetividade e descoberta de portal, descritas nas RFC 8910 e RFC 8952, e esses pedidos saem antes de qualquer VPN estar de pé. Vê-los num registo de proxy é um comportamento esperado e não uma prova de fuga.
A solução prática é dar ao cliente um endpoint que não precise de consulta. Quando isso é impossível, termine primeiro o início de sessão e conecte-se depois.
Descubra qual resolvedor respondeu
Pergunte ao sistema e não ao navegador, e execute a consulta duas vezes: uma através do resolvedor que o dispositivo usa agora, outra contra um endereço fixo.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Uma resposta do primeiro comando diferente da terceira diz-lhe que o resolvedor local devolve outra coisa, que é o que faz um hotspot que redireciona. Uma falha da terceira junto com um sucesso da primeira aponta para o portal: o resolvedor local serviu um endereço de início de sessão enquanto a porta 53 de saída era descartada. Tempos esgotados em ambas significam que a rede descarta o DNS até a autenticação estar concluída.
Repita depois de ligar e compare. Uma resposta em cache sobrevive à transição, por isso limpe a cache ou consulte um nome novo para a segunda observação.
Mantenha as consultas posteriores no caminho que pretendia
Um perfil de túnel completo que também captura o DNS é a disposição mais simples: cada consulta de cada aplicação vai para o resolvedor que o túnel impõe, e a rede local só vê tráfego cifrado. Prove-o resolvendo um nome interno e um público depois de ligar, e comparando então ambas as respostas com o que o resolvedor do túnel devolve por si só.
O split-DNS precisa de uma lista de domínios escrita com intenção: sufixos corporativos pelo túnel, todo o resto localmente, e sem sobreposição entre os dois.
O DNS seguro do navegador fica fora dessa política, por isso, se tiver de estar desativado para o perfil se comportar de forma previsível, desative-o para esse perfil e não para a máquina. Faça-o nas definições do navegador, não editando o resolvedor do sistema, para que a alteração seja visível da próxima vez. Registe a resposta, o resolvedor e a fase de ligação numa linha por teste. Um relatório que diz que o DNS falhou no Wi-Fi do hotel descreve um sintoma com pelo menos três causas diferentes.