WSL2 perdeu o DNS depois de conectar a VPN? Duas causas

O ping por endereço funciona dentro da distribuição, as instalações de pacotes e os downloads do git não, e a falha apareceu logo depois que o túnel subiu. Só os nomes deixaram de resolver, o que aponta para o DNS e não para a conectividade. Reinstalar pacotes é o primeiro passo errado mais popular aqui. O WSL2 tem duas maneiras independentes de produzir exatamente esse sintoma, e elas exigem consertos diferentes.

Por que a distribuição mantém o próprio resolver

O cliente DNS do Windows não é usado dentro da distribuição. O WSL2 constrói o próprio arquivo de resolver na inicialização, apontando para um endereço stub que o Windows publica no comutador virtual para a máquina virtual auxiliar.

Esse arranjo é estável em mudanças de rede comuns porque é escrito uma vez e reutilizado. O arranjo deixa de estar correto quando um cliente de túnel reescreve a lista de adaptadores do host depois que a máquina virtual auxiliar já iniciou.

Nada dentro da distribuição acompanha a mudança, então o arquivo continua apontando para um endereço que talvez não esteja mais no caminho. A próxima consulta então espera, expira ou recebe resposta de um servidor que nunca ouviu falar da zona interna. Por dentro, o resolver simplesmente para de responder, e todos os nomes falham de uma vez.

Reúna evidências dos dois lados primeiro

Registre o que a distribuição vê, depois o que o Windows vê, antes de mudar qualquer um dos dois. São as duas visões juntas que distinguem os modos de falha.

Dentro da distribuição, imprima o arquivo de resolver, a tabela de rotas e uma consulta interna e uma pública:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

No Windows, liste os servidores DNS por adaptador e a tabela IPv4 com métricas. Um cliente VPN costuma instalar uma rota para a sub-rede do WSL2, e a métrica dela decide se esse tráfego sai pelo túnel ou fica local.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Métrica de rota ou arquivo desatualizado

A primeira falha é o arquivo desatualizado. O resolver foi escrito para o estado do adaptador na inicialização, e o túnel mudou esse estado. Seu endereço stub pode estar inacessível agora, ou pode nomear um servidor que não sabe nada da zona interna.

A segunda é um problema de roteamento. Quando a VPN adiciona uma rota que cobre a sub-rede do WSL2 com métrica menor que a rota de link do host, os pacotes endereçados à máquina virtual auxiliar entram no túnel. Então expira cada serviço do WSL2, não apenas o DNS.

O teste que os distingue custa uma linha. Se um endereço numérico como um resolver público ainda responde ao ping enquanto os nomes falham, o caminho está intacto e o problema é o DNS. Esse é o caso em que uma mudança de resolver se justifica, e o caso em que não se justifica também fica evidente. Se o teste numérico também falhar, a máquina virtual auxiliar perdeu a rota dela e nenhum arquivo de resolver vai corrigir isso.

Para o caso de roteamento, remova a métrica automática do adaptador do túnel e dê a ele um número acima da rota de link do WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Desligar importa. Mudar a métrica não reescreve a máquina virtual auxiliar em execução, então a distribuição precisa ser reconstruída antes que a mudança fique visível.

Assuma o arquivo, deliberadamente

Se o roteamento está correto e só os nomes internos falham, o resolver é o culpado e você pode parar o gerador. É uma mudança deliberada com custo de manutenção, não um contorno para aplicar sem cuidado.

Crie /etc/wsl.conf dentro da distribuição com a seção de rede que desativa a geração, e depois escreva o arquivo de resolver você mesmo, primeiro o servidor corporativo e depois um público de reserva:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

A ordem importa. Um resolver público não consegue responder a um nome interno, e a reserva existe apenas para consultas de internet. Depois que o arquivo é seu, nada o regenera, então um resolver corporativo que se muda vira uma queda que você mesmo precisa notar.

Verifique nomes e depois pacotes

Verifique um nome interno e um público com o resolver do sistema, e repita depois a operação que falhou. Os gerenciadores de pacotes às vezes usam um resolver próprio, por isso um getent que funciona pode conviver com uma instalação quebrada.

Se você automatizar a reescrita, torne-a idempotente: sem túnel, mantenha o arquivo que já existe em vez de escrever uma lista vazia de servidores.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Uma consulta interna que funciona e uma consulta pública que funciona, de dentro da distribuição, é o resultado que vale registrar. Um ícone verde de VPN no host não prova nenhuma das duas.