Drept openconnect: ruter og DNS peker fortsatt mot tunnelen

Tunnelen er nede, men maskinen oppfører seg fortsatt som om den er oppe: et oppslag henger til det timer ut, og en rute peker inn i et grensesnitt som ikke finnes lenger. Det er signaturen til en openconnect-prosess som døde uten å kjøre frakoblingshjelperen sin. Nettverkstilstanden den skapte, er fortsatt installert, og ingenting annet på systemet vet hvordan den skal fjernes.

Gå gjennom maskinen i den rekkefølgen tilstanden ble skapt: prosess, lenke, rute, resolver. Hvert trinn forteller om klienten virkelig er borte eller bare koblet fra terminalen din, og den forskjellen avgjør om du skal reparere noe i det hele tatt.

Begynn med prosessen, ikke konfigurasjonen

Åpne en terminal og spør hva som fortsatt kjører før du rører en rute. pgrep -a openconnect lister opp hver instans med argumentene sine, noe som viser pid-filen og skriptet den fikk. En prosess du ikke forventet, forklarer spøkelsestunnelen raskere enn noen logg.

Hvis ingenting kjører, se på lenken. ip link show tun0 forteller om grensesnittet overlevde, og ip route show dev tun0 lister opp ruter som fortsatt er bundet til det. Sjekk deretter resolveren med resolvectl status. Skriv ned alle tre utdataene før du endrer dem, fordi den registreringen er måten du senere skiller en utdatert oppføring fra en ny.

Et grensesnitt som er borte, tar vanligvis med seg rutene sine. Ruter som overlever lenken, betyr som regel at prosessen fortsatt lever, eller at en annen klient eier enheten.

Hjelpeskriptet er det som ruller endringene tilbake

openconnect fjerner ikke grensesnittet, rutene eller resolver-oppføringene selv. Det kaller en ekstern hjelper, /etc/vpnc/vpnc-script i et upstream-bygg og /usr/share/vpnc-scripts/vpnc-script i Debian- og Ubuntu-pakkene, valgt med -s. Det samme skriptet som setter opp tunnelen, er det som river den ned.

Hvis prosessen avsluttes uten å kalle den hjelperen, blir tilstanden stående. OpenConnect-håndboken sier uttrykkelig at ruting og navnetjeneste ikke vil fungere riktig uten skriptet, og den beskriver hjelperen som komponenten som demonterer grensesnitttilstanden ved avslutning. Derfor er stien viktig når du starter klienten med -s.

Hvilket signal som når den veien, endret seg mellom versjoner. Håndboken for 7.06 behandler SIGTERM som en umiddelbar avslutning som hopper over skriptet. Nåværende bygg dokumenterer INT og TERM som en ren stopp, der sesjonen logges av og hjelperen kjører. Les SIGNALS-delen i den binærfilen du faktisk har, i stedet for å anta en av de to oppførslene.

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

Send signalet bygget ditt dokumenterer

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

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

Gjenta deretter de tre kontrollene fra første del i stedet for å stole på avslutningsstatusen. ip link show tun0 bør mislykkes, ip route show dev tun0 bør ikke skrive ut noe, og resolvectl status bør ikke lenger liste VPN-lenken.

SIGHUP er ikke en stoppknapp: den kobler fra, kjører skriptet og lar sesjonen kunne gjenopptas med --cookie. SIGUSR2 tvinger en umiddelbar gjentilkobling. SIGKILL hopper helt over oppryddingen, og det er nøyaktig tilstanden denne artikkelen handler om.

Reparer resolveren uten å erstatte resolv.conf

På de fleste Ubuntu-systemer er /etc/resolv.conf en symbolsk lenke inn i systemd-resolved, ikke en fil du bør redigere. Å erstatte den bryter navneoppslag for alle nettverk, ikke bare VPN. Fjern i stedet registreringen av tunnelen:

resolvectl revert tun0
resolvectl query example.com

Hvis systemet bruker resolvconf i stedet for systemd-resolved, blir oppføringen per grensesnitt stående til den blir bedt om å slippe lenken, og resolvconf -d tun0 er den tilsvarende handlingen. Sjekk hvilken resolver som brukes før du velger kommandoen.

Et oppslag som fortsatt er rettet mot en server bak den døde lenken, henger til det timer ut, og den forsinkelsen ser ut som en ødelagt DNS-server snarere enn en gjenværende rute.

Gjør den neste frakoblingen kjedelig

Hold stien til pid-filen identisk ved oppstart og avslutning ved å gi --pid-file hver gang, eller kjør openconnect under en unit der KillSignal samsvarer med signalet versjonen din dokumenterer. Testing først i forgrunnen viser deg avslutningsmeldingene hjelperen skriver ut.

Koble til, koble fra og kjør de tre kontrollene én gang. En ren avslutning etterlater verken VPN-lenke, VPN-rute eller VPN-resolver-oppføring. Hvis én av de tre overlever, vet du nå hvilken komponent som ikke ryddet opp. Den neste undersøkelsen starter da fra det svaret i stedet for fra et hengende oppslag.