O DNS do OpenVPN fica para trás após SIGKILL: verifique primeiro o proprietário

O DNS deixa de resolver depois que um cliente OpenVPN é morto, e o primeiro instinto é reescrever /etc/resolv.conf. Essa alteração pode quebrar um resolvedor que funciona enquanto o verdadeiro estado obsoleto está noutro lugar. A questão a resolver primeiro é quem possui as definições de DNS que o túnel instalou, e se a saída que ignorou a limpeza realmente importou.

Três condições decidem a reparação: o sinal que terminou o processo, o componente do resolvedor que recebeu as definições e se o enlace do túnel ainda existe. Responda por essa ordem e a correção costuma surgir sem tocar num ficheiro global.

Decida que tipo de saída ocorreu

Na edição Community do OpenVPN, tanto o SIGINT como o SIGTERM são pedidos de saída ordeira. O SIGKILL não pode ser capturado: não pode ser bloqueado nem tratado, por isso nenhuma rotina de encerramento tem oportunidade de correr. Um Ctrl+C normal num terminal em primeiro plano gera SIGINT, enquanto um supervisor que desiste de esperar costuma escalar para SIGKILL. A diferença importa porque só o segundo caso garante que os ganchos foram ignorados.

Correr dentro de screen ou tmux não muda o sinal que o Ctrl+C envia. Verifique o que o processo recebeu de facto, não o que o terminal costuma fazer.

Quando um serviço ou gestor de ligações executa o túnel, pare essa ligação através do proprietário em vez de matar o pid. Um gestor pode voltar a levantar o processo, deixando-o com um túnel novo e um estado do resolvedor confuso. Um processo autónomo só precisa de um pedido de terminação normal para a limpeza correr.

Decida quem possui o resolvedor

systemd-resolved, um script ao estilo resolvconf e uma simples reescrita de ficheiro são três proprietários diferentes. O primeiro mantém as definições por enlace em memória e descarta-as quando a interface desaparece. O segundo mantém registos que persistem até algo os remover. O terceiro escreve um ficheiro e deixa a restauração a quem o escreveu.

Identifique o proprietário antes de escolher um comando de reparação. O mesmo sintoma tem três respostas corretas diferentes conforme o que estiver em uso.

Uma VPN gerida pelo NetworkManager pode já possuir as alterações ao resolvedor. Acrescentar um segundo auxiliar por cima cria dois proprietários a competir pelo mesmo enlace, e o estado do perdedor reaparece na ligação seguinte. Se um gestor estiver encarregue, corrija a definição no gestor e não num script.

O que o gancho down pode e não pode fazer

O script down corre uma vez depois de o dispositivo TUN/TAP ser fechado. Acrescentar down-pre inverte essa ordem e executa o script enquanto o dispositivo ainda existe, o que é exigido por auxiliares que precisam do enlace ativo.

Nenhuma das diretivas faz um gancho correr após SIGKILL. Os privilégios também não são restaurados por down-pre: se o daemon descer para um user ou group ou entrar num chroot, o gancho corre com o acesso que isso lhe deixar. Um gancho invocado pode ainda assim falhar ao atualizar o resolvedor. A referência do OpenVPN cobre os sinais e o ciclo de vida do callback.

Verifique o erro do próprio gancho junto ao estado de saída do processo. Uma limpeza em falta e uma limpeza falhada parecem iguais no resolvedor e diferentes nos registos.

Verifique o estado que resta de facto

Num sistema que usa systemd-resolved, resolvectl status mostra qual enlace ainda transporta os servidores DNS da VPN ou os domínios de encaminhamento. Esse enlace pode pertencer a uma ligação que já não existe ou a outro túnel ainda ativo.

Uma interface que desaparece leva consigo a sua configuração por enlace, pelo que um gancho ignorado pode coexistir com DNS limpo. Se o enlace ainda estiver registado e for possuído exclusivamente pela ligação parada, o gestor proprietário deve removê-lo. Se um script mais antigo reescreveu um ficheiro global do resolvedor, procure antes o passo de restauração documentado desse script.

Recupere sem roubar outro enlace

Quando as definições por enlace são suas para gerir, o resolvectl revert recebe o nome do enlace e limpa a configuração de DNS em tempo de execução dessa interface. É uma ação em tempo de execução e não uma edição de perfil, por isso a configuração persistente da ligação fica intacta. Nomeie o enlace errado e limpa o DNS de um túnel que funciona, por isso o nome vem da saída do estado.

Confirme que o /etc/resolv.conf é uma ligação simbólica gerida antes de o editar, depois pare o cliente normalmente mais uma vez e veja o DNS de novo. Se a segunda paragem limpar, o problema anterior era a saída forçada e não a configuração.