Por que o WSL perde o nome do host de trabalho quando a VPN se conecta?

O Windows resolve o host interno sem qualquer queixa, e o mesmo nome falha dentro do WSL no momento em que o túnel sobe. O reparo habitual é escrever um resolvedor público na distribuição, o que restaura a navegação normal e torna o nome do host de trabalho impossível de resolver. Isso troca uma falha por outra e esconde a camada que realmente quebrou. Antes de adicionar ou remover qualquer linha de resolvedor, descubra qual das três camadas está falhando.

Primeiro descarte uma falha de roteamento

Consulte o mesmo nome totalmente qualificado nos dois lados, não dois nomes parecidos. Um sucesso no Windows e uma falha no WSL para a mesma cadeia é a assinatura de dois caminhos de resolução, e poucas outras coisas produzem esse padrão com tanta limpeza. Se o WSL também não alcança o serviço no endereço numérico conhecido, há também um problema de roteamento ou de filtragem. Nesse caso o trabalho de DNS não o revelará, e a tarde vai para a camada errada.

Três sintomas cobrem a maioria desses casos, e cada um aponta para um lugar diferente. Leia a linha que corresponde antes de abrir um arquivo de configuração:

A linha do meio é a que as pessoas leem errado, porque a mudança que a quebrou foi feita semanas antes e parecia bem-sucedida na época. A terceira linha é a que as pessoas diagnosticam errado, porque um nome que resolve parece prova de que a rede está saudável. Ambas as linhas levam você a uma seção diferente abaixo.

O túnel DNS tem um piso de versão

A Microsoft documenta um modo de rede do WSL que tuneliza as requisições DNS para o resolvedor do Windows através de um canal de virtualização. Nas compilações compatíveis do Windows 11 ele está ativado por padrão, e por isso duas máquinas na mesma rede corporativa se comportam de maneira diferente. A variável é o número da compilação, não a política corporativa.

O guia de redes do WSL descreve esse modo e as versões que o suportam. O recurso importa porque a política DNS corporativa costuma viver no resolvedor do Windows, e uma distribuição que herda o caminho do Windows herda a política junto. Uma distribuição que consulta um resolvedor público não tem rota para um nome privado, por mais arrumada que pareça a própria configuração. Esse mecanismo explica todo o sintoma e explica por que a solução alternativa do resolvedor público falha.

Leia a compilação antes de editar qualquer coisa. Uma configuração copiada de uma instalação mais nova não é prova de que uma mais antiga a implemente. Anote o número da compilação ao lado da mudança, porque a diferença entre duas máquinas quase sempre é uma versão e não uma política.

As substituições antigas sobrevivem ao problema que resolveram

As receitas mais antigas desativavam os arquivos de resolvedor gerados, fixavam um servidor de nomes à mão ou bloqueavam o arquivo com um atributo imutável. Essas mudanças permanecem no lugar muito depois de o problema de conectividade que as motivou desaparecer, e costumam ser a razão pela qual uma configuração mais nova parece não fazer nada. Também sobrevivem a uma reinstalação da distribuição na forma de um perfil de shell que reescreve o arquivo a cada login. Este último é o mais difícil de encontrar, porque é invisível a partir do arquivo que todos inspecionam.

Procure um arquivo de resolvedor escrito à mão, um atributo imutável nele e um script de inicialização que o reescreva. Verifique o sinalizador imutável antes de editar, porque uma escrita em um arquivo bloqueado falha de um modo que se lê como problema de permissões. Verifique depois o perfil de shell, porque um script ali restaura o conteúdo antigo em segundos após a sua correção.

Remover uma substituição tem consequências, então anote o que você removeu e por quê. Uma distribuição que realmente precise de um resolvedor estático para outro propósito quebrará quando o arquivo gerado voltar.

Dois arquivos, dois papéis diferentes

Os dois arquivos de configuração vivem em lugares diferentes e controlam coisas diferentes, e confundi-los produz edições aplicadas à camada errada. O arquivo do lado do Windows define propriedades da máquina virtual, enquanto o arquivo do lado da distribuição define como essa distribuição constrói a própria configuração de resolvedor. Nenhum substitui o outro, por isso ambos precisam concordar.

Para uma instalação que suporta o recurso, o fragmento do lado do Windows é curto. É toda a mudança desse lado:

[wsl2]
dnsTunneling=true

Esse fragmento fica no perfil de usuário do Windows e se aplica à máquina virtual, não a uma única distribuição. O túnel também exige que a distribuição não tenha desativado a geração de resolvedor, então o arquivo do lado da distribuição deve deixar esse comportamento em paz. Mude um sem o outro e o modo não faz nada em silêncio, que é a forma mais comum de esse reparo ser relatado como quebrado. Verifique os dois arquivos na mesma sessão, porque duas edições feitas com semanas de diferença são duas edições que ninguém consegue atribuir.

Reinicie e depois consulte dos dois lados

Essas configurações são lidas quando o ambiente inicia, então um shell novo dentro de uma distribuição em execução não as recarregará. Desligue o ambiente em vez de reiniciar o shell, e salve primeiro qualquer trabalho em andamento porque cada distribuição para junto com ele. Essa omissão sozinha explica a maioria dos relatos de que uma mudança não tem efeito.

Depois faça a mesma pergunta dos dois lados. A saída também mostra com qual resolvedor a distribuição realmente ficou:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

O primeiro comando encerra o ambiente, o segundo mostra qual resolvedor a distribuição usa agora, e os dois últimos fazem a mesma pergunta a cada lado. Compare as respostas, não o estado da configuração. Uma consulta que ainda falha após uma reinicialização limpa com os dois arquivos corretos aponta para a política de resolvedor corporativa, e essa conversa tem outro dono.