Gestopte openconnect: roetes en DNS wys steeds na die tonnel

Die tonnel is af, maar die masjien gedra hom steeds asof dit op is: ’n opsoek hang tot dit uittyd, en ’n roete wys na ’n koppelvlak wat nie meer bestaan nie. Dit is die handtekening van ’n openconnect-proses wat gesterf het sonder om sy ontkoppelhelper te laat loop. Die netwerktoestand wat dit geskep het, is steeds geïnstalleer, en niks anders op die stelsel weet hoe om dit te verwyder nie.

Stap deur die masjien in die volgorde waarin die toestand geskep is: proses, skakel, roete, resolver. Elke stap vertel jou of die kliënt regtig weg is of net van jou terminaal losgemaak is, en daardie onderskeid bepaal of jy enigiets hoegenaamd herstel.

Begin by die proses, nie by die konfigurasie nie

Maak ’n terminaal oop en vra wat nog loop voordat jy aan ’n roete raak. pgrep -a openconnect lys elke instansie met sy argumente, wat die pid-lêer en die skrip wys waarmee dit gestart is. ’n Proses wat jy nie verwag het nie, verduidelik die spooktonnel vinniger as enige log.

As niks loop nie, kyk na die skakel. ip link show tun0 vertel jou of die koppelvlak oorleef het, en ip route show dev tun0 lys roetes wat nog daaraan gebind is. Kyk dan na die resolver met resolvectl status. Teken al drie uitvoere aan voordat jy hulle verander, want daardie rekord is hoe jy later ’n verouderde inskrywing van ’n nuwe een onderskei.

’n Koppelvlak wat weg is, neem gewoonlik sy roetes saam. Roetes wat die skakel oorleef, beteken gewoonlik die proses leef nog of ’n tweede kliënt besit die toestel.

Die helper-skrip is wat die veranderinge ongedaan maak

openconnect verwyder nie self die koppelvlak, roetes of resolver-inskrywings nie. Dit roep ’n eksterne helper, /etc/vpnc/vpnc-script in ’n upstream-bou en /usr/share/vpnc-scripts/vpnc-script in die Debian- en Ubuntu-pakkette, gekies met -s. Dieselfde skrip wat die tonnel opstel, is die een wat dit afbreek.

As die proses eindig sonder om daardie helper te roep, bly die toestand staan. Die OpenConnect-handleiding sê uitdruklik dat roetering en naambediener nie reg sal werk sonder die skrip nie, en dit beskryf die helper as die komponent wat die koppelvlaktoestand by afsluiting afbreek. Dis waarom die pad saak maak wanneer jy die kliënt met -s.

Watter sein daardie pad bereik, het tussen weergawes verander. Die 7.06-handleiding beskou SIGTERM as ’n onmiddellike afsluiting wat die skrip oorslaan. Huidige boue dokumenteer INT en TERM as ’n skoon stop, waar die sessie afgeteken word en die helper loop. Lees die SIGNALS-afdeling van die binêre lêer wat jy werklik het in plaas daarvan om enige van die twee gedrag te aanvaar.

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

Stuur die sein wat jou bou dokumenteer

Sodra jy die sein ken, stop die proses volgens pid eerder as volgens patroon.

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

Herhaal dan die drie kontroles uit die eerste afdeling in plaas daarvan om die afsluitstatus te vertrou. ip link show tun0 behoort te misluk, ip route show dev tun0 behoort niks te druk nie, en resolvectl status behoort nie meer die VPN-skakel te lys nie.

SIGHUP is nie ’n stopknoppie nie: dit ontkoppel, laat die skrip loop en laat die sessie hervatbaar met --cookie. SIGUSR2 forseer ’n onmiddellike herverbinding. SIGKILL slaan die opruiming heeltemal oor, wat presies die toestand is waaroor hierdie artikel gaan.

Herstel die resolver sonder om resolv.conf te vervang

Op die meeste Ubuntu-stelsels is /etc/resolv.conf ’n simskakel na systemd-resolved, nie ’n lêer wat jy moet wysig nie. Om dit te vervang breek naamresolusie vir elke netwerk, nie net die VPN nie. Laat eerder die tonnel se registrasie val:

resolvectl revert tun0
resolvectl query example.com

As die stelsel resolvconf eerder as systemd-resolved gebruik, bly die per-koppelvlak-rekord staan totdat dit aangesê word om die skakel te laat val, en resolvconf -d tun0 is die ekwivalente aksie. Kyk watter resolver in gebruik is voordat jy die opdrag kies.

’n Opsoek wat steeds na ’n bediener agter die dooie skakel mik, hang tot dit uittyd, en daardie vertraging lyk soos ’n stukkende DNS-bediener eerder as ’n oorblywende roete.

Maak die volgende ontkoppeling vervelig

Hou die pid-lêerpad dieselfde by opstart en afsluit deur --pid-file elke keer te gee, of laat openconnect onder ’n eenheid loop wie se KillSignal ooreenstem met die sein wat jou weergawe dokumenteer. Om eers in die voorgrond te toets, wys jou die afsluitboodskappe wat die helper druk.

Koppel, ontkoppel en hardloop die drie kontroles een keer. ’n Skoon afsluiting laat geen VPN-skakel, geen VPN-roete en geen VPN-resolver-inskrywing nie. As een van die drie oorleef, weet jy nou watter komponent versuim het om op te ruim. Die volgende ondersoek begin dan by daardie antwoord eerder as by ’n hangende opsoek.