Editar o resolv.conf não corrige o DNS depois que a VPN se desconecta

Você desconecta a VPN, o ping 1.1.1.1 ainda responde, e toda consulta de nome trava antes que a página finalmente desista. Então o cat /etc/resolv.conf mostra um servidor de nomes que só existiu dentro do túnel, normalmente o primeiro da lista. Apagar essa linha parece corrigir o problema por uns dez minutos, até uma suspensão, um roaming de Wi-Fi ou um reinício colocá-la de volta. O arquivo que você editou não é a configuração; é uma representação do estado do link que pertence a outro componente.

Por que uma entrada obsoleta custa segundos por consulta

O resolver da glibc percorre a lista de servidores de nomes em ordem e espera um tempo limite terminar antes de tentar o próximo, e o resolv.conf(5) limita essa lista a três entradas. Coloque um resolver do lado do túnel como 10.8.0.1 no topo depois que o túnel sumir, e toda consulta paga o tempo limite antes de cair para um servidor que responde. É por isso que o sintoma parece uma conexão morta e não um erro de DNS: os navegadores bloqueiam, estouram o tempo e às vezes entregam um endereço em cache que depois fica obsoleto.

Isso também explica por que a queixa chega como «a internet quebrou». Um ping para um endereço IP prova que o link está bom, o que faz a falha parecer da aplicação. A lista de resolvers é a primeira coisa a ler e a última a editar.

O mito: o resolv.conf é um arquivo de configuração

Pergunte o que o caminho realmente é antes de mudá-lo:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Num host com systemd-resolved ele é um link simbólico para um arquivo stub que aponta para 127.0.0.53, e os servidores reais vivem no estado por link que o resolvectl imprime. Num host com NetworkManager pode ser um arquivo que o NetworkManager escreve a partir da conexão ativa. Com alguns clientes de fabricante é um arquivo simples reescrito no lugar ao conectar e, se você não tiver sorte, nunca restaurado ao desconectar. São três donos diferentes, e editar os dois primeiros à mão ou não faz nada ou dura até o próximo evento de rede.

O resolvectl status é a visão que diz a verdade: servidores DNS por link, domínios de roteamento e se o link do túnel ainda existe. O resolvectl query example.com vai além e mostra qual interface respondeu. Use os dois antes de tocar num arquivo, e lembre-se de que um navegador com DNS seguro próprio ignora tudo isso.

Encontre o dono antes de editar qualquer coisa

Três componentes costumam competir pelo mesmo ajuste: systemd-resolved, NetworkManager e o que o cliente de VPN tiver instalado. Identifique primeiro o vivo:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Se o resolved está ativo e o link simbólico aponta para o stub dele, o arquivo global é saída gerada e sua edição é cosmética. Se o NetworkManager é dono da conexão, os servidores pertencem ao perfil de conexão, então a correção é uma mudança de propriedade via nmcli e não uma edição de arquivo. Se um daemon do fabricante está rodando, só o caminho de restauração dele sobrevive à próxima conexão.

Limpe o estado do link que o cliente deixou para trás

Um cliente morto não consegue executar seu hook de limpeza. SIGKILL não pode ser capturado de forma alguma, enquanto SIGINT e SIGTERM podem, então um túnel que «simplesmente parou» depois de um kill forçado frequentemente deixa no lugar tanto o registro da interface quanto a entrada do resolver. Encontre o PID específico e envie o sinal apenas para ele:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Não recorra a pkill -f vpn nem killall vpn antes de ler a lista completa de correspondências. O -f casa com a linha de comando inteira, então pode encerrar um script wrapper, uma sessão de editor ou um processo não relacionado cujo caminho contenha a string. Encerrar o processo errado no meio do trabalho é como um problema de resolver vira um arquivo perdido.

O resolvectl revert recompõe a configuração de DNS em tempo de execução daquele link, o que é mais estreito que reiniciar o resolver e muito mais estreito que editar o arquivo global. Se o link do túnel sumiu por completo, o systemctl restart NetworkManager reconstrói o estado da conexão e é o passo ao qual as threads de origem voltam sem parar. Cuidado com um gerenciador de serviços com Restart=always, porque ele pode recolocar um cliente morto, e suas configurações de DNS, direto no lugar.

A outra direção: DNS empurrado que nunca chegou

A imagem espelhada da entrada obsoleta é um túnel sem nenhum resolver utilizável. Uma opção de DNS no perfil é um pedido; o componente que gerencia a conexão precisa entregá-la ao resolver. Se o log mostra que o servidor foi recebido mas o link do túnel não carrega nenhuma configuração de DNS, falta a integração, não o servidor.

Teste a entrega fazendo-a à mão, o que separa «o servidor está errado» de «ninguém aplicou»:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

O domínio de roteamento que captura tudo envia cada nome para aquele link, que é o que um cliente de túnel completo quer e o que o DNS dividido não deve usar. Essas configurações desaparecem na próxima conexão. Para torná-las persistentes no NetworkManager, desative o DNS automático, defina o servidor na conexão e adicione o domínio:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Para um túnel corporativo que só deve responder a nomes internos, liste essas zonas com um til inicial em vez do captura-tudo, para que os nomes públicos continuem usando o resolver local.

Gambiarras que viram a próxima queda

Copiar o resolv.conf antes de conectar e restaurá-lo depois é uma linha legítima num runbook, e é uma gambiarra e não um conserto. Ela falha exatamente quando importa, porque um travamento ou um reinício forçado pula a restauração. Anote como gambiarra para que a próxima pessoa não construa em cima dela.

Desativar o systemd-resolved e codificar servidores públicos na mão é a outra jogada popular. Torna conectar e desconectar previsíveis e remove o DNS por link de todas as outras redes, o que quebra o DNS dividido para nomes internos e anula o propósito de um túnel feito para manter as consultas dentro dele. Instalar o resolvconf e fixar servidores públicos custa o mesmo com uma camada extra. Trate qualquer uma das duas como diagnóstico: se ela devolve a navegação, você aprendeu que a integração do resolver é a culpada, não que os servidores públicos estão corretos.

O conserto duradouro é um dono por camada: decida qual componente possui o DNS do link do túnel e qual possui o padrão global, anote isso e remova os outros do caminho. Depois verifique após uma desconexão com um nome que só a VPN resolve. Se um nome privado ainda responde, o registro não foi removido; se nada resolve, o arquivo aponta para um servidor que não existe mais. As duas coisas aparecem no resolvectl antes de você abrir um navegador.