O túnel dividido exclui o navegador, não as suas consultas DNS

Navegador excluído do túnel, a página de IP público confirma que o seu tráfego sai pela ligação de casa, e a wiki interna continua a não abrir. A resolução de nomes foi para outro lado, e esse outro lado costuma ser o resolvedor configurado pela VPN. O caminho dos dados e o caminho do resolvedor são decisões separadas na maioria dos projetos de túnel dividido. Verifique qual o navegador realmente usou antes de chamar a exclusão de avariada.

O caminho dos dados e o caminho do resolvedor separam-se

Uma exclusão retira os pacotes de uma aplicação do túnel, o que é uma decisão de encaminhamento e firewall no caminho dos dados. A resolução de nomes é outra consulta: um processo pergunta ao resolvedor do sistema, e esse resolvedor decide que servidor recebe a pergunta.

Ambos podem ser intencionais e diferentes. Uma implementação de trabalho pode manter os espaços de nomes internos no resolvedor corporativo enquanto envia a navegação pública selecionada para fora do túnel, precisamente porque os nomes internos não são resolvidos em mais lado nenhum. O caso confuso é o inverso: um site público falha porque o navegador nunca perguntou ao resolvedor que a implementação esperava. Registe a rota e o resolvedor em separado, e metade das discussões desaparece.

Descubra que processo faz a pergunta

Um navegador pode usar o resolvedor do sistema, o seu próprio serviço de DNS cifrado, ou um resolvedor que o sistema operativo atribui por rede. O primeiro segue a política da plataforma, o segundo contorna essa política por completo, e o terceiro depende da ligação para a qual a consulta é encaminhada.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Leia a configuração efetiva antes de testar: que ligações transportam servidores DNS, que espaços de nomes reivindicam, e se uma política por nome substitui a predefinição. No Linux, o DNS dividido usa domínios de encaminhamento; no Windows, a tabela de políticas de resolução de nomes faz o mesmo para os espaços de nomes. Nenhuma das duas é visível a partir de uma página de teste de fugas.

Decida que resolvedor vê que nome

Escreva o mapeamento pretendido antes de mudar qualquer coisa: nomes internos para o resolvedor corporativo, nomes públicos para o serviço que a política permitir, e exceções com um responsável. Sem essa lista, cada etiqueta do teste de fugas torna-se uma discussão de política que ninguém consegue encerrar.

Depois verifique a configuração do próprio navegador, porque o DNS cifrado no navegador é aplicado antes de o sistema operativo receber a consulta. Um utilizador que o ativou para contornar um portal cativo substituiu em silêncio o resolvedor escolhido pela implementação. É uma decisão de configuração e não uma fuga, e merece uma decisão em vez de uma lista de bloqueio.

Não reescreva todos os campos DNS para tornar uma etiqueta de teste verde. A etiqueta descreve uma consulta de um processo num instante.

Verifique consulta e ligação em separado

Teste os dois caminhos em separado. O teste de ligação mostra a rota dos dados, e o teste do resolvedor mostra quem recebeu o nome.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Pergunte também ao resolvedor de forma explícita, para que uma falha possa ser atribuída ao servidor e não ao caminho. Depois reinicie o navegador e repita, porque as aplicações guardam em cache as respostas negativas e uma falha antiga parece persistente.

Após uma alteração aprovada, registe a rota dos dados e o destinatário do resolvedor como duas linhas separadas com a data. Se o comportamento voltar na próxima reconexão, o perfil que o fornece é o que deve ser corrigido, não o navegador.