Deade openconnect: rûtes en DNS wize noch altyd nei de tunnel

De tunnel is del, mar de masine hâldt him noch altyd as wie er omheech: in opsyk hinget oant it útrint, en in rûte wiist nei in ynterface dat net mear bestiet. Dat is de hantekening fan in openconnect-proses dy’t stoar sûnder syn ûntkoppelhelper te draaien. De netwurksteat dy’t er makke hat, is noch altyd ynstallearre, en neat oars op it systeem wit hoe’t er dy fuorthelje moat.

Rin de masine lâns yn de folchoarder wêryn’t de steat makke is: proses, keppeling, rûte, resolver. Eltse stap fertelt dy oft de klant echt fuort is of him allinnich fan dyn terminal losmakke hat, en dat ferskil beslút oftst hielendal wat reparearje moatst.

Begjin by it proses, net by de konfiguraasje

Iepenje in terminal en freegje wat der noch rint foardatst in rûte oanreits. pgrep -a openconnect listet eltse eksimplaar mei syn arguminten op, wat it pid-bestân en it skript sjen lit dat it krigen hat. In proses datst net ferwachte hiest, ferklearret de fantoomtunnel flugger as hokker log dan ek.

As der neat rint, sjoch dan nei de keppeling. ip link show tun0 fertelt dy oft it ynterface oerlibbe hat, en ip route show dev tun0 listet rûtes op dy’t der noch oan ferbûn binne. Kontrolearje dan de resolver mei resolvectl status. Skriuw alle trije útkomsten op foardatst se feroarjest, want dat ferslach is hoe’tst letter in ferâldere ynfiering fan in nije ûnderskiedst.

In ynterface dat fuort is, nimt normaal syn rûtes mei. Rûtes dy’t de keppeling oerlibje, betsjutte meastentiids dat it proses noch libbet of dat in twadde klant it apparaat hat.

It helperscript is wat de feroarings weromdraait

openconnect hellet it ynterface, de rûtes of de resolver-ynfieringen sels net fuort. It ropt in eksterne helper oan, /etc/vpnc/vpnc-script yn in upstream-bou en /usr/share/vpnc-scripts/vpnc-script yn ’e Debian- en Ubuntu-pakketten, keazen mei -s. Itselde skript dat de tunnel delset, is ek dat him ôfbrekt.

As it proses einiget sûnder dy helper oan te roppen, bliuwt de steat. De OpenConnect-hanlieding is eksplisyt dat routing en namtsjinst sûnder it skript net goed wurkje sille, en it beskriuwt de helper as it ûnderdiel dat de steat fan it ynterface by it ôfsluten ôfbrekt. Dêrom is it paad fan belang asst de klant startst mei -s.

Hokker sinjaal dat paad berikt, feroare tusken ferzjes. De hânlieding fan 7.06 behannelet SIGTERM as in daliks ôfsluten dat it skript oerslacht. Hjoeddeistige bouwen dokumintearje INT en TERM as in skjinne stop, wêrby’t de sesje ôfmeld wurdt en de helper rint. Lês de seksje SIGNALS fan it binary datst eins hast, ynstee fan ien fan beide gedragingen oan te nimmen.

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

Stjoer it sinjaal dat dyn bou dokumintearret

Asst it sinjaal kenst, stopje it proses dan op pid, net op patroan.

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

Werhelje dan de trije checks út it earste diel ynstee fan op ’e útgongstatus te fertrouwen. ip link show tun0 soe mislukje moatte, ip route show dev tun0 soe neat printsje moatte, en resolvectl status soe de VPN-keppeling net mear listje moatte.

SIGHUP is gjin stopknop: it ûntkoppelt, draait it skript en lit de sesje werombetelber mei --cookie. SIGUSR2 twingt in daliks werferbinen. SIGKILL slacht it opromjen hielendal oer, en dat is krekt de steat dêr’t dit artikel oer giet.

Reparearje de resolver sûnder resolv.conf te ferfangen

Op de measte Ubuntu-systemen is /etc/resolv.conf in symboalyske keppeling nei systemd-resolved, net in bestân datst bewurkje moatst. It ferfangen brekt namme-oplossing foar elk netwurk, net allinnich foar de VPN. Helje ynstee de registraasje fan de tunnel fuort:

resolvectl revert tun0
resolvectl query example.com

As it systeem resolvconf brûkt ynstee fan systemd-resolved, bliuwt de ynfiering per ynterface oant it sein wurdt de keppeling los te litten, en resolvconf -d tun0 is de lykweardige aksje. Kontrolearje hokker resolver brûkt wurdt foardatst it kommando kiest.

In opsyk dy’t noch rjochte is op in server efter de deade keppeling hinget oant it útrint, en dy fertraging liket op in stikken DNS-server ynstee fan in oerbliuwende rûte.

Meitsje de folgjende ûntkoppeling saai

Hâld it paad fan it pid-bestân gelyk by it starten en útskeakeljen troch --pid-file eltse kear te jaan, of draai openconnect ûnder in unit waans KillSignal oerienkomt mei it sinjaal dat dyn ferzje dokumintearret. Earst op ’e foargrûn testen lit dy de útskeakelberjochten sjen dy’t de helper printet.

Ferbyn, ûntkoppel en draai de trije checks ien kear. In skjinne útgong lit gjin VPN-keppeling, gjin VPN-rûte en gjin VPN-resolver-ynfiering efter. As ien fan ’e trije oerlibbet, witst no hokker ûnderdiel net opromme hat. It folgjende ûndersyk begjint dan by dat antwurd ynstee fan by in hingjend opsyk.