Drepen openconnect: ruter og DNS peikar framleis mot tunnelen

Tunnelen er nede, men maskinen oppfører seg framleis som om han er oppe: eit oppslag heng til det timer ut, og ei rute peikar inn i eit grensesnitt som ikkje finst lenger. Det er signaturen til ein openconnect-prosess som døydde utan å køyre fråkoplinghjelparen sin. Nettverkstilstanden han skapte, er framleis installert, og ingenting anna på systemet veit korleis han skal fjernast.

Gå gjennom maskinen i den rekkjefølgja tilstanden vart skapt: prosess, lenke, rute, resolver. Kvart trinn fortel om klienten verkeleg er borte eller berre kopla frå terminalen din, og den skilnaden avgjer om du skal reparere noko i det heile.

Byrja med prosessen, ikkje konfigurasjonen

Opne ein terminal og spør kva som framleis køyrer før du rører ei rute. pgrep -a openconnect listar opp kvar instans med argumenta sine, noko som viser pid-fila og skriptet ho fekk. Ein prosess du ikkje venta, forklarer spøkjelsestunnelen raskare enn nokon logg.

Viss ingenting køyrer, sjå på lenka. ip link show tun0 fortel om grensesnittet overlevde, og ip route show dev tun0 listar opp ruter som framleis er bundne til det. Sjekk deretter resolveren med resolvectl status. Skriv ned alle tre utdata før du endrar dei, fordi den registreringa er måten du seinare skil ei utdatert oppføring frå ei ny.

Eit grensesnitt som er borte, tek vanlegvis med seg rutene sine. Ruter som overlever lenka, tyder som regel at prosessen framleis lever, eller at ein annan klient eig eininga.

Hjelpeskriptet er det som rullar endringane tilbake

openconnect fjernar ikkje grensesnittet, rutene eller resolver-oppføringane sjølv. Det kallar ein ekstern hjelpar, /etc/vpnc/vpnc-script i eit upstream-bygg og /usr/share/vpnc-scripts/vpnc-script i Debian- og Ubuntu-pakkene, vald med -s. Det same skriptet som set opp tunnelen, er det som riv han ned.

Viss prosessen avsluttar utan å kalle den hjelparen, blir tilstanden ståande. OpenConnect-handboka seier uttrykkeleg at ruting og namneteneste ikkje vil fungere rett utan skriptet, og ho skildrar hjelparen som komponenten som demonterer grensesnitttilstanden ved avslutning. Derfor er stien viktig når du startar klienten med -s.

Kva signal som når den vegen, endra seg mellom versjonar. Handboka for 7.06 behandlar SIGTERM som ein umiddelbar avslutning som hoppar over skriptet. Noverande bygg dokumenterer INT og TERM som ein rein stopp, der sesjonen blir logga av og hjelparen køyrer. Les SIGNALS-delen i den binærfila du faktisk har, i staden for å anta ein av dei to åtferdene.

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

Send signalet bygget ditt dokumenterer

Når du kjenner signalet, stopp prosessen etter pid og ikkje etter mønster.

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

Gjenta deretter dei tre kontrollane frå første del i staden for å stole på avslutningsstatusen. ip link show tun0 bør mislukkast, ip route show dev tun0 bør ikkje skrive ut noko, og resolvectl status bør ikkje lenger liste VPN-lenka.

SIGHUP er ikkje ein stoppknapp: det koplar frå, køyrer skriptet og lèt sesjonen kunne gjenopptakast med --cookie. SIGUSR2 tvingar ei umiddelbar gjentilkopling. SIGKILL hoppar heilt over oppryddinga, og det er nøyaktig tilstanden denne artikkelen handlar om.

Reparer resolveren utan å erstatte resolv.conf

På dei fleste Ubuntu-system er /etc/resolv.conf ei symbolsk lenke inn i systemd-resolved, ikkje ei fil du bør redigere. Å erstatte ho bryt namneoppslag for alle nettverk, ikkje berre VPN. Fjern i staden registreringa av tunnelen:

resolvectl revert tun0
resolvectl query example.com

Viss systemet brukar resolvconf i staden for systemd-resolved, blir oppføringa per grensesnitt ståande til ho blir beden om å sleppe lenka, og resolvconf -d tun0 er den tilsvarande handlinga. Sjekk kva resolver som blir brukt før du vel kommandoen.

Eit oppslag som framleis er retta mot ein server bak den døde lenka, heng til det timer ut, og den forseinkinga ser ut som ein øydelagd DNS-server snarare enn ei attverande rute.

Gjer den neste fråkoplinga keisam

Hald stien til pid-fila identisk ved oppstart og avslutning ved å gi --pid-file kvar gong, eller køyr openconnect under ein unit der KillSignal samsvarer med signalet versjonen din dokumenterer. Testing først i forgrunnen viser deg avslutningsmeldingane hjelparen skriv ut.

Kopla til, kopla frå og køyr dei tre kontrollane éin gong. Ein rein avslutning etterlèt verken VPN-lenke, VPN-rute eller VPN-resolver-oppføring. Viss éin av dei tre overlever, veit du no kva komponent som ikkje rydda opp. Den neste undersøkinga startar då frå det svaret i staden for frå eit hengande oppslag.