openconnect morto: as rutas e o DNS seguen apuntando ao túnel

O túnel está caído, pero a máquina segue comportándose como se estivese arriba: unha consulta colga ata esgotar o tempo de espera, e unha ruta apunta a unha interface que xa non existe. Esa é a sinatura dun proceso openconnect que morreu sen executar o seu asistente de desconexión. O estado de rede que creou segue instalado, e nada máis no sistema sabe como eliminalo.

Percorra a máquina na orde en que se creou o estado: proceso, enlace, ruta, resolvedor. Cada paso dille se o cliente se foi de verdade ou só se desenganchou do seu terminal, e esa distinción decide se hai que reparar algo.

Empece polo proceso, non pola configuración

Abra un terminal e pregunte que segue executándose antes de tocar unha ruta. pgrep -a openconnect lista cada instancia cos seus argumentos, o que mostra o ficheiro pid e o script que se lle deu. Un proceso que non esperaba explica o túnel fantasma máis rápido que calquera rexistro.

Se non se executa nada, mire o enlace. ip link show tun0 dille se a interface sobreviviu, e ip route show dev tun0 lista as rutas que seguen ligadas a ela. Despois comprobe o resolvedor con resolvectl status. Anote as tres saídas antes de cambialas, porque ese rexistro é a forma de distinguir máis tarde unha entrada obsoleta dunha nova.

Unha interface que desaparece normalmente leva as súas rutas consigo. As rutas que sobreviven ao enlace adoitan significar que o proceso segue vivo ou que un segundo cliente posúe o dispositivo.

O script auxiliar é o que desfai os cambios

openconnect non elimina por si mesmo a interface, as rutas nin as entradas do resolvedor. Chama un asistente externo, /etc/vpnc/vpnc-script nunha compilación upstream e /usr/share/vpnc-scripts/vpnc-script nos paquetes de Debian e Ubuntu, elixido con -s. O mesmo script que levanta o túnel é o que o desmonta.

Se o proceso sae sen chamar ese asistente, o estado queda. O manual de OpenConnect é explícito en que o enrutamento e o servizo de nomes non funcionarán correctamente sen o script, e describe o asistente como o compoñente que desmonta o estado da interface á saída. Por iso importa a ruta cando inicia o cliente con -s.

Que sinal chega a esa ruta cambiou entre versións. O manual da 7.06 trata SIGTERM como unha saída inmediata que omite o script. As compilacións actuais documentan INT e TERM como unha parada limpa, na que a sesión se desconecta e o asistente se executa. Lea a sección SIGNALS do binario que realmente ten en lugar de supor calquera dos dous comportamentos.

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

Envíe o sinal que documenta a súa compilación

Unha vez que coñeza o sinal, deteña o proceso por pid e non por patrón.

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

Logo repita as tres comprobacións da primeira sección en lugar de confiar no estado de saída. ip link show tun0 debería fallar, ip route show dev tun0 non debería imprimir nada, e resolvectl status xa non debería listar o enlace VPN.

SIGHUP non é un botón de parada: desconecta, executa o script e deixa a sesión retomable con --cookie. SIGUSR2 forza unha reconexión inmediata. SIGKILL omite a limpeza por completo, que é exactamente o estado do que trata este artigo.

Repare o resolvedor sen substituír resolv.conf

Na maioría dos sistemas Ubuntu /etc/resolv.conf é un enlace simbólico a systemd-resolved, non un ficheiro que deba editar. Substituílo rompe a resolución de nomes para todas as redes, non só para a VPN. No seu lugar, elimine o rexistro do túnel:

resolvectl revert tun0
resolvectl query example.com

Se o sistema usa resolvconf en lugar de systemd-resolved, o rexistro por interface persiste ata que se lle di que solte o enlace, e resolvconf -d tun0 é a acción equivalente. Comprobe que resolvedor se está usando antes de elixir o comando.

Unha consulta que segue dirixida a un servidor detrás do enlace morto colga ata esgotar o tempo de espera, e ese atraso parece un servidor DNS roto máis que unha ruta sobrante.

Faga aburrida a próxima desconexión

Manteña a mesma ruta do ficheiro pid ao iniciar e ao apagar pasando --pid-file cada vez, ou execute openconnect baixo unha unidade cuxo KillSignal coincida co sinal que documenta a súa versión. Probar primeiro en primeiro plano amósalle as mensaxes de apagado que imprime o asistente.

Conéctese, desconéctese e execute as tres comprobacións unha vez. Unha saída limpa non deixa ningún enlace VPN, ningunha ruta VPN nin ningunha entrada de resolvedor VPN. Se unha das tres sobrevive, agora sabe que compoñente non limpou. A seguinte investigación comeza entón desde esa resposta e non desde unha consulta colgada.