resolv.conf no WSL 2: o DNS morre quando a VPN se liga

Navegar dentro da distribuição funciona, e o primeiro nome de anfitrião interno falha no momento em que o túnel sobe. O reflexo é acrescentar um resolver público, que repõe a internet e torna o nome corporativo inacessível durante o resto do dia. No WSL 2, /etc/resolv.conf é saída gerada e não configuração, e é esse o mecanismo que vale a pena compreender. A correção não é um resolver melhor, é a posse do ficheiro.

O ficheiro é gerado, não configurado

O WSL 2 escreve o ficheiro no arranque a partir dos adaptadores Windows que vê nesse momento, e imprime no topo um comentário que o diz. Quando um cliente de VPN acrescenta ou reescreve um adaptador depois, a distribuição não regenera necessariamente nada, e o ficheiro continua a descrever uma rede que já não existe.

Um segundo modo de falha é mais silencioso: o WSL pode copiar servidores apenas de alguns adaptadores. Se o adaptador físico já tiver um resolver IPv6, os servidores IPv4 fornecidos pelo adaptador da VPN podem ser descartados em vez de acrescentados, e o ficheiro parece completo ao omitir exatamente o que responde aos nomes internos.

Compare a vista do Windows com a vista do Linux

Leia os dois lados antes de editar. Dentro da distribuição, veja o que o ficheiro contém e se é um ficheiro normal ou uma ligação. No Windows, liste o resolver de cada adaptador, incluindo o que a VPN criou:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Quando o adaptador da VPN mostra os servidores corporativos e o Linux mostra outra coisa, a divergência está na geração e não no alcance. Compare a lista de adaptadores e também os endereços, porque um adaptador em falta explica um servidor em falta. Essa distinção decide se está a reparar o WSL ou uma firewall, e as duas coisas não têm nada em comum.

Desative a geração e escreva o seu próprio ficheiro

Uma definição documentada impede o WSL de reescrever o ficheiro, e encontra-se em /etc/wsl.conf. Acrescente uma secção de rede a esse ficheiro:

[network]
generateResolvConf = false

Depois termine a distribuição a partir do Windows com wsl --shutdown e volte a iniciá-la. Se o caminho for uma ligação simbólica e não um ficheiro normal, remova a ligação antes de escrever o seu próprio conteúdo, porque escrever através da ligação pode recriar o alvo gerado no arranque seguinte. A partir desse momento o ficheiro é seu e nada o reescreve.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Sem um domínio de pesquisa, um nome de anfitrião não qualificado é completado com a raiz pública e volta como não existe tal domínio. timeout impede que um primeiro servidor morto bloqueie cada consulta, attempts limita quantas tentativas uma consulta gasta, e rotate reparte as novas tentativas em vez de começar sempre pelo topo. A troca é que o ficheiro deixa de seguir uma VPN cujo endereço de resolver muda entre sessões.

Lide com um resolver que se desloca e depois verifique

Alguns clientes fornecem um resolver específico da sessão, por isso um ficheiro estático quebra na ligação seguinte. Duas abordagens são defensáveis. Escreva o ficheiro a partir de um pequeno script sempre que o endereço mudar, ou deixe a geração ativa e garanta que o adaptador de onde o WSL copia transporta o servidor corporativo. A segunda não precisa de gancho e falha sempre que a geração salta o adaptador da VPN; ambas exigem ainda que o conflito de IPv6 seja resolvido primeiro.

O Windows aplica também as suas próprias políticas de nomes, como uma lista de pesquisa de sufixos ou uma política de resolução para domínios específicos, e copiar os endereços dos adaptadores não reproduz essas regras. Se um nome resolve no Windows e não na distribuição com o mesmo servidor, compare o tratamento dos sufixos antes de culpar o túnel.

Teste com um nome e não com um pacote: getent hosts sensor-access0.corp.example passa pela pilha de resolvers, enquanto um ping pode ter sucesso contra um endereço em cache ou literal. Depois repita após desligar e voltar a ligar, porque uma definição que funciona uma vez e é regenerada ao retomar nunca foi corrigida. Guarde o conteúdo anterior e anote que componente é dono do caminho nessa máquina, para que a próxima alteração comece com provas.