openconnect morto: as rotas e o DNS continuam a apontar para o túnel

O túnel está em baixo, mas a máquina continua a comportar-se como se estivesse em cima: uma consulta fica pendurada até expirar, e uma rota aponta para uma interface que já não existe. Essa é a assinatura de um processo openconnect que morreu sem executar o seu assistente de desconexão. O estado de rede que criou continua instalado, e nada mais no sistema sabe como removê-lo.

Percorra a máquina pela ordem em que o estado foi criado: processo, ligação, rota, resolvedor. Cada passo diz-lhe se o cliente desapareceu mesmo ou apenas se desligou do seu terminal, e essa distinção decide se há algo a reparar.

Comece pelo processo, não pela configuração

Abra um terminal e pergunte o que ainda está a correr antes de tocar numa rota. pgrep -a openconnect lista cada instância com os seus argumentos, o que mostra o ficheiro pid e o script que lhe foi dado. Um processo que não esperava explica o túnel fantasma mais depressa do que qualquer registo.

Se nada estiver a correr, veja a ligação. ip link show tun0 diz-lhe se a interface sobreviveu, e ip route show dev tun0 lista as rotas que continuam ligadas a ela. Depois verifique o resolvedor com resolvectl status. Anote as três saídas antes de as alterar, porque é esse registo que lhe permitirá mais tarde distinguir uma entrada obsoleta de uma nova.

Uma interface que desaparece costuma levar as suas rotas consigo. Rotas que sobrevivem à ligação geralmente significam que o processo ainda está vivo ou que um segundo cliente possui o dispositivo.

É o script auxiliar que desfaz as alterações

O openconnect não remove por si a interface, as rotas nem as entradas do resolvedor. Chama um assistente externo, /etc/vpnc/vpnc-script numa compilação upstream e /usr/share/vpnc-scripts/vpnc-script nos pacotes Debian e Ubuntu, escolhido com -s. O mesmo script que levanta o túnel é o que o desmonta.

Se o processo terminar sem chamar esse assistente, o estado fica. manual do OpenConnect é explícito ao afirmar que o encaminhamento e o serviço de nomes não funcionarão corretamente sem o script, e descreve o assistente como o componente que desmonta o estado da interface à saída. É por isso que o caminho importa quando inicia o cliente com -s.

Qual sinal chega a esse caminho mudou entre versões. O manual da 7.06 trata o SIGTERM como uma saída imediata que ignora o script. As compilações atuais documentam INT e TERM como uma paragem limpa, em que a sessão é terminada e o assistente é executado. Leia a secção SIGNALS do binário que realmente tem em vez de presumir qualquer dos dois comportamentos.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Envie o sinal que a sua compilação documenta

Depois de saber o sinal, pare o processo por pid e não por padrão.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Depois repita as três verificações da primeira secção em vez de confiar no estado de saída. ip link show tun0 deveria falhar, ip route show dev tun0 não deveria imprimir nada, e resolvectl status já não deveria listar a ligação VPN.

O SIGHUP não é um botão de paragem: desliga, executa o script e deixa a sessão retomável com --cookie. O SIGUSR2 força uma reconexão imediata. O SIGKILL ignora completamente a limpeza, e é exatamente esse o estado de que trata este artigo.

Repare o resolvedor sem substituir resolv.conf

Na maioria dos sistemas Ubuntu /etc/resolv.conf é uma ligação simbólica para o systemd-resolved, não um ficheiro que deva editar. Substituí-la quebra a resolução de nomes em todas as redes, não só na VPN. Em vez disso, remova o registo do túnel:

resolvectl revert tun0
resolvectl query example.com

Se o sistema usar resolvconf em vez de systemd-resolved, o registo por interface persiste até lhe ser dito para largar a ligação, e resolvconf -d tun0 é a ação equivalente. Verifique qual resolvedor está a ser usado antes de escolher o comando.

Uma consulta ainda dirigida a um servidor atrás da ligação morta fica pendurada até expirar, e esse atraso parece um servidor DNS avariado em vez de uma rota remanescente.

Torne a próxima desconexão aborrecida

Mantenha o mesmo caminho do ficheiro pid no arranque e no encerramento, passando --pid-file sempre, ou execute o openconnect sob uma unidade cujo KillSignal corresponda ao sinal que a sua versão documenta. Testar primeiro em primeiro plano mostra-lhe as mensagens de encerramento que o assistente imprime.

Ligue, desligue e execute as três verificações uma vez. Uma saída limpa não deixa qualquer ligação VPN, rota VPN nem entrada de resolvedor VPN. Se uma das três sobreviver, agora sabe que componente não limpou. A investigação seguinte começa então nessa resposta e não numa consulta pendurada.