Um nome interno ainda resolve para o servidor VPN um dia depois de o túnel ter fechado, e o ficheiro do resolvedor continua a voltar com essa entrada. Onde o resolvconf do Debian detém o estado, esse ficheiro é montado a partir de registos de fornecedores, e um deles é o resto. Apagar o registo leva um minuto; provar que é seguro apagá-lo é o trabalho a sério. Estes portões correm por ordem, e um portão falhado termina o procedimento em vez de o enviar para o passo seguinte.

Confirme que o resolvconf detém o estado

Identifique primeiro o dono, porque o mesmo sintoma sob systemd-resolved exige comandos diferentes e uma reparação diferente. O pacote resolvconf mantém uma base de dados em /run/resolvconf e aponta /etc/resolv.conf para o ficheiro que constrói a partir dessa base. Duas leituras resolvem a questão: o destino da ligação simbólica, e se o pacote está instalado e ativo. Um destino em /run/systemd/resolve significa o outro desenho, onde nada abaixo se aplica.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

Se a ligação apontar para outro sítio ou o pacote faltar, pare aqui. Um invólucro de compatibilidade que pediu o nome emprestado, distribuído por outro gestor de resolvedor, não é dono desta base de dados.

A base de dados guarda entradas, não a resposta

A base de dados guarda entradas e o ficheiro é uma saída, por isso listar as entradas é a única forma de ver que programa instalou a entrada de que quer livrar-se. Os registos são curtos, e as suas chaves são as pegas de que vai precisar mais tarde. Leia-os antes de decidir qual está obsoleto, porque um nome que parece uma interface VPN pode pertencer a outro cliente. Mantenha endereços privados e domínios de pesquisa internos fora dos diagnósticos partilhados; a chave sozinha costuma identificar o registo.

sudo resolvconf --list
sudo resolvconf -i

O primeiro comando imprime os registos fornecidos sem os processar, e o segundo lista as interfaces que atualmente fornecem configuração DNS. As chaves são convencionalmente construídas a partir de um nome de interface e do programa que a fornece. O manual do resolvconf descreve a base de dados a que essas chaves se dirigem.

Copie a chave da saída em vez de a reconstruir. Uma entrada não se chama tun0 só porque um script antigo usou esse nome.

Prove que o registo não tem dono

Um registo é seguro de apagar quando nenhuma ligação viva o instalou. Correlacione a chave com a ligação que a criou, e depois confirme que essa ligação desapareceu. Essa correlação é o portão inteiro, e é o passo mais vezes saltado a caminho do comando de eliminação. Se a evidência for ambígua, trate o registo como vivo e pare.

Nomes de processos são provas fracas. O OpenConnect chama vpnc-script, por isso verificar um processo vpnc não diz nada sobre qual registo é o atual. Uma ligação nova também pode reutilizar um nome de interface deixado por uma antiga, o que faz a chave parecer mais velha do que é. Compare o endereço do servidor dentro do registo com os endereços dos túneis que ainda estão de pé, e pare se coincidirem.

Uma desconexão normal através do gestor que detém a ligação é o primeiro remédio. Retira o que essa ligação instalou e deixa os outros fornecedores intactos.

Verifique a remoção e a reescrita

Com o registo confirmado obsoleto, apague-o pela chave exata e depois leia o resultado em vez de o assumir. O comando altera o estado do resolvedor para todas as aplicações do anfitrião, por isso execute-o numa janela que controle. Ponha a chave entre aspas, porque contém caracteres que a shell de outro modo expandiria. O marcador no bloco representa a chave que copiou da lista, não uma cadeia literal.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

A eliminação executa os scripts de atualização quando a atualização está ativa; com as atualizações desativadas, adia a atualização, pelo que um registo removido e um ficheiro reescrito são dois acontecimentos separados. Releia a lista e confirme que a chave desapareceu antes de olhar para o ficheiro. Depois consulte um nome que ainda deva resolver pelos fornecedores restantes e um nome público, e compare ambos com o que viu antes da alteração. Se um nome privado deixar de resolver por completo, esse registo ainda o transportava.

resolvconf -u executa apenas esses scripts de atualização. Nunca identifica nem apaga um registo obsoleto, e reconstruir a partir de entradas obsoletas reproduz o mesmo ficheiro indesejado.

Um gancho de desconexão morto deixa o registo atrás

Uma limpeza pontual restaura o estado de hoje, e o próximo encerramento interrompido repõe o registo. Percorra o caminho de desmontagem: o gancho de desconexão do cliente, o auxiliar que esse gancho chama, e o que acontece quando um deles é morto. Um encerramento interrompido é a origem habitual, porque o gancho nunca chegou a correr. Registe uma vez o estado de saída do gancho e saberá se está a falhar em silêncio.

Mantenha a configuração e a limpeza sob um só dono. Um segundo script que adivinhe nomes de interfaces acabará por apagar o registo de outra ligação, o que é pior do que a entrada obsoleta com que começou. O dono também deve decidir quando um registo está obsoleto, porque sabe que ligação o instalou.

Depois exercite o ciclo de vida: ligue, desligue, liste de novo os registos. O desaparecimento espontâneo da entrada é a única prova de que a reparação se mantém.

Artigos relacionados