Dræbt openconnect: ruter og DNS peger stadig på tunnelen

Tunnelen er nede, men maskinen opfører sig stadig, som om den er oppe: et opslag hænger, indtil det timer ud, og en rute peger ind i et interface, der ikke findes længere. Det er signaturen på en openconnect-proces, der døde uden at køre sin afbrydelseshjælper. Den netværkstilstand, den skabte, er stadig installeret, og intet andet på systemet ved, hvordan den skal fjernes.

Gå gennem maskinen i den rækkefølge, tilstanden blev skabt: proces, link, rute, resolver. Hvert trin fortæller dig, om klienten reelt er væk, eller blot er koblet af din terminal, og den forskel afgør, om du overhovedet skal reparere noget.

Begynd med processen, ikke konfigurationen

Åbn en terminal, og spørg, hvad der stadig kører, før du rører en rute. pgrep -a openconnect lister hver instans med dens argumenter, hvilket viser pid-filen og det script, den fik. En proces, du ikke forventede, forklarer spøgelsestunnelen hurtigere end nogen log.

Hvis intet kører, så se på linket. ip link show tun0 fortæller dig, om interfacet overlevede, og ip route show dev tun0 lister ruter, der stadig er bundet til det. Tjek derefter resolveren med resolvectl status. Skriv alle tre output ned, før du ændrer dem, for den registrering er måden, hvorpå du senere skelner en forældet post fra en ny.

Et interface, der er væk, tager normalt sine ruter med sig. Ruter, der overlever linket, betyder som regel, at processen stadig er i live, eller at en anden klient ejer enheden.

Hjælpescriptet er det, der ruller ændringerne tilbage

openconnect fjerner ikke selv interfacet, ruterne eller resolver-posterne. Det kalder en ekstern hjælper, /etc/vpnc/vpnc-script i et upstream-build og /usr/share/vpnc-scripts/vpnc-script i Debian- og Ubuntu-pakkerne, valgt med -s. Det samme script, der sætter tunnelen op, er det, der river den ned.

Hvis processen afsluttes uden at kalde den hjælper, bliver tilstanden. OpenConnect-manualen er eksplicit i, at routing og navnetjeneste ikke vil fungere korrekt uden scriptet, og den beskriver hjælperen som den komponent, der demonterer interfacets tilstand ved afslutning. Det er derfor, stien betyder noget, når du starter klienten med -s.

Hvilket signal der når den vej, ændrede sig mellem versioner. 7.06-manualen behandler SIGTERM som en øjeblikkelig afslutning, der springer scriptet over. Nuværende builds dokumenterer INT og TERM som et rent stop, hvor sessionen logges af, og hjælperen kører. Læs SIGNALS-afsnittet i den binære fil, du faktisk har, i stedet for at antage en af de to opførsler.

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

Send det signal, din build dokumenterer

Når du kender signalet, stop processen efter pid i stedet for efter mønster.

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

Gentag derefter de tre kontroller fra første afsnit i stedet for at stole på exit-status. ip link show tun0 bør fejle, ip route show dev tun0 bør ikke udskrive noget, og resolvectl status bør ikke længere liste VPN-linket.

SIGHUP er ikke en stopknap: den afbryder, kører scriptet og efterlader sessionen genoptagelig med --cookie. SIGUSR2 tvinger en øjeblikkelig genopkobling. SIGKILL springer oprydningen helt over, og det er præcis den tilstand, denne artikel handler om.

Reparer resolveren uden at erstatte resolv.conf

På de fleste Ubuntu-systemer er /etc/resolv.conf et symbolsk link ind i systemd-resolved, ikke en fil, du bør redigere. At erstatte den ødelægger navneopløsning for alle netværk, ikke kun VPN. Fjern i stedet tunnelens registrering:

resolvectl revert tun0
resolvectl query example.com

Hvis systemet bruger resolvconf i stedet for systemd-resolved, bevares posten for hvert interface, indtil den får besked om at slippe linket, og resolvconf -d tun0 er den tilsvarende handling. Tjek, hvilken resolver der bruges, før du vælger kommandoen.

Et opslag, der stadig er rettet mod en server bag det døde link, hænger, indtil det timer ud, og den forsinkelse ligner en ødelagt DNS-server snarere end en efterladt rute.

Gør den næste afbrydelse kedelig

Hold pid-filens sti identisk ved opstart og nedlukning ved at give --pid-file hver gang, eller kør openconnect under en unit hvis KillSignal matcher det signal, din version dokumenterer. Test først i forgrunden viser dig de nedlukningsbeskeder, hjælperen udskriver.

Forbind, afbryd og kør de tre kontroller én gang. En ren afslutning efterlader hverken VPN-link, VPN-rute eller VPN-resolver-post. Hvis en af de tre overlever, ved du nu, hvilken komponent der ikke ryddede op. Den næste undersøgelse starter så fra det svar i stedet for fra et hængende opslag.