openconnect mort: les rutes i el DNS encara apunten al túnel

El túnel està caigut, però la màquina encara es comporta com si estigués aixecat: una consulta es penja fins que expira, i una ruta apunta a una interfície que ja no existeix. Aquesta és la signatura d’un procés openconnect que va morir sense executar el seu assistent de desconnectament. L’estat de xarxa que va crear encara està instal·lat, i res més al sistema sap com eliminar-lo.

Recorreu la màquina en l’ordre en què es va crear l’estat: procés, enllaç, ruta, resolutor. Cada pas us diu si el client ha desaparegut de debò o només s’ha desenganxat del vostre terminal, i aquesta distinció decideix si heu de reparar res.

Comenceu pel procés, no per la configuració

Obriu un terminal i pregunteu què encara s’executa abans de tocar cap ruta. pgrep -a openconnect llista cada instància amb els seus arguments, cosa que mostra el fitxer pid i l’script que se li va donar. Un procés que no esperàveu explica el túnel fantasma més de pressa que qualsevol registre.

Si no s’executa res, mireu l’enllaç. ip link show tun0 us diu si la interfície ha sobreviscut, i ip route show dev tun0 llista les rutes que encara hi estan lligades. Després comproveu el resolutor amb resolvectl status. Anoteu les tres sortides abans de canviar-les, perquè aquest registre és com distingireu més tard una entrada obsoleta d’una de nova.

Una interfície que desapareix normalment s’emporta les seves rutes. Les rutes que sobreviuen a l’enllaç solen significar que el procés encara és viu o que un segon client posseeix el dispositiu.

L’script auxiliar és el que desfà els canvis

openconnect no elimina ell mateix la interfície, les rutes ni les entrades del resolutor. Crida un assistent extern, /etc/vpnc/vpnc-script en una compilació upstream i /usr/share/vpnc-scripts/vpnc-script als paquets de Debian i Ubuntu, triat amb -s. El mateix script que aixeca el túnel és el que el desmunta.

Si el procés surt sense cridar aquest assistent, l’estat es queda. El manual d’OpenConnect és explícit que l’encaminament i el servei de noms no funcionaran correctament sense l’script, i descriu l’assistent com el component que desmunta l’estat de la interfície en sortir. És per això que el camí importa quan inicieu el client amb -s.

Quin senyal arriba a aquest camí va canviar entre versions. El manual de la 7.06 tracta SIGTERM com una sortida immediata que omet l’script. Les compilacions actuals documenten INT i TERM com una aturada neta, on la sessió es desconnecta i l’assistent s’executa. Llegiu la secció SIGNALS del binari que realment teniu en lloc de suposar cap de les dues conductes.

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

Envieu el senyal que documenta la vostra compilació

Un cop sapigueu el senyal, atureu el procés per pid i no per patró.

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

Després repetiu les tres comprovacions de la primera secció en lloc de confiar en l’estat de sortida. ip link show tun0 hauria de fallar, ip route show dev tun0 no hauria d’imprimir res, i resolvectl status ja no hauria de llistar l’enllaç VPN.

SIGHUP no és un botó d’aturada: desconnecta, executa l’script i deixa la sessió reprenible amb --cookie. SIGUSR2 força una reconnexió immediata. SIGKILL omet la neteja del tot, que és exactament l’estat d’aquest article.

Repareu el resolutor sense substituir resolv.conf

A la majoria de sistemes Ubuntu /etc/resolv.conf és un enllaç simbòlic cap a systemd-resolved, no un fitxer que hàgiu d’editar. Substituir-lo trenca la resolució de noms per a totes les xarxes, no només per a la VPN. En lloc d’això, elimineu el registre del túnel:

resolvectl revert tun0
resolvectl query example.com

Si el sistema fa servir resolvconf en lloc de systemd-resolved, el registre per interfície persisteix fins que se li diu que deixi anar l’enllaç, i resolvconf -d tun0 és l’acció equivalent. Comproveu quin resolutor s’utilitza abans de triar l’ordre.

Una consulta encara adreçada a un servidor darrere de l’enllaç mort es penja fins que expira, i aquest retard sembla un servidor DNS espatllat més que una ruta sobrant.

Feu avorrida la propera desconnexió

Manteniu el mateix camí del fitxer pid a l’inici i a l’aturada passant --pid-file cada vegada, o executeu openconnect sota una unitat amb un KillSignal que coincideixi amb el senyal que documenta la vostra versió. Provar primer en primer pla us mostra els missatges d’aturada que imprimeix l’assistent.

Connecteu, desconnecteu i executeu les tres comprovacions una vegada. Una sortida neta no deixa cap enllaç VPN, cap ruta VPN ni cap entrada de resolutor VPN. Si una de les tres sobreviu, ara sabeu quin component no va netejar. La investigació següent comença llavors des d’aquesta resposta i no des d’una consulta penjada.