Ubit openconnect: poti in DNS še vedno kažejo v tunel

Tunel je izklopljen, a stroj se še vedno obnaša, kot da je vklopljen: poizvedba visi, dokler ne poteče čas, in pot kaže v vmesnik, ki ne obstaja več. To je podpis procesa openconnect, ki je umrl, ne da bi zagnal svojega pomočnika za odklop. Omrežno stanje, ki ga je ustvaril, je še vedno nameščeno, in nič drugega v sistemu ne ve, kako ga odstraniti.

Prehodite stroj v vrstnem redu, v katerem je stanje nastalo: proces, povezava, pot, resolver. Vsak korak vam pove, ali je odjemalec res izginil ali se je le odklopil od vašega terminala, in ta razlika odloči, ali sploh kaj popraviti.

Začnite s procesom, ne s konfiguracijo

Odprite terminal in vprašajte, kaj še teče, preden se dotaknete poti. pgrep -a openconnect izpiše vsak primerek z njegovimi argumenti, kar pokaže datoteko pid in skript, ki mu je bil dan. Proces, ki ga niste pričakovali, pojasni fantomski tunel hitreje kot kateri koli dnevnik.

Če nič ne teče, poglejte povezavo. ip link show tun0 vam pove, ali je vmesnik preživel, in ip route show dev tun0 izpiše poti, ki so še vedno vezane nanj. Nato preverite resolver s resolvectl status. Zapišite vse tri izhode, preden jih spremenite, ker je prav ta zapis način, da pozneje ločite zastarel vnos od novega.

Vmesnik, ki izgine, običajno odnese svoje poti s seboj. Poti, ki preživijo povezavo, običajno pomenijo, da je proces še živ ali da napravo poseduje drug odjemalec.

Prav pomožni skript razveljavi spremembe

openconnect sam ne odstrani vmesnika, poti ali vnosov resolverja. Pokliče zunanjega pomočnika, /etc/vpnc/vpnc-script v gradnji upstream in /usr/share/vpnc-scripts/vpnc-script v paketih Debian in Ubuntu, izbranega s -s. Isti skript, ki postavi tunel, ga tudi razstavi.

Če proces konča, ne da bi poklical tega pomočnika, stanje ostane. priročnik OpenConnect izrecno navaja, da usmerjanje in storitev imen brez skripta ne bosta delovala pravilno, in opisuje pomočnika kot komponento, ki ob izstopu razstavi stanje vmesnika. Zato je pot pomembna, ko odjemalca zaženete s -s.

Kateri signal doseže to pot, se je med različicami spremenilo. Priročnik za 7.06 obravnava SIGTERM kot takojšen izstop, ki preskoči skript. Sedanje gradnje dokumentirajo INT in TERM kot čisto zaustavitev, pri kateri se seja odjavi in pomočnik se izvede. Preberite razdelek SIGNALS binarne datoteke, ki jo dejansko imate, namesto da bi predpostavili eno od obeh vedenj.

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

Pošljite signal, ki ga dokumentira vaša gradnja

Ko signal poznate, ustavite proces po pid, ne po vzorcu.

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

Nato ponovite tri preverbe iz prvega razdelka, namesto da bi zaupali izhodnemu statusu. ip link show tun0 bi morala spodleteti, ip route show dev tun0 ne bi smel ničesar natisniti in resolvectl status ne bi smel več izpisati povezave VPN.

SIGHUP ni gumb za zaustavitev: odklopi, izvede skript in pusti sejo obnovljivo s --cookie. SIGUSR2 vsili takojšnjo ponovno povezavo. SIGKILL popolnoma preskoči čiščenje, in to je natanko stanje, o katerem je ta članek.

Popravite resolver brez zamenjave resolv.conf

V večini sistemov Ubuntu je /etc/resolv.conf simbolična povezava v systemd-resolved, ne datoteka, ki bi jo morali urejati. Njena zamenjava pokvari razreševanje imen za vsako omrežje, ne le za VPN. Namesto tega odstranite registracijo tunela:

resolvectl revert tun0
resolvectl query example.com

Če sistem uporablja resolvconf namesto systemd-resolved, vnos na vmesnik ostane, dokler se mu ne reče, naj spusti povezavo, in resolvconf -d tun0 je enakovredno dejanje. Pred izbiro ukaza preverite, kateri resolver se uporablja.

Poizvedba, ki je še vedno usmerjena na strežnik za mrtvo povezavo, visi, dokler ne poteče čas, in ta zamuda je videti kot pokvarjen strežnik DNS, ne kot preostala pot.

Naj bo naslednji odklop dolgočasen

Ohranite isto pot datoteke pid ob zagonu in izklopu tako, da podajate --pid-file vsakič, ali zaženite openconnect pod enoto katere KillSignal ustreza signalu, ki ga dokumentira vaša različica. Preizkušanje najprej v ospredju vam pokaže sporočila ob izklopu, ki jih izpiše pomočnik.

Povežite se, odklopite se in enkrat zaženite tri preverbe. Čist izhod ne pusti niti povezave VPN, niti poti VPN niti vnosa resolverja VPN. Če ena od treh preživi, zdaj veste, katera komponenta ni počistila. Naslednja preiskava se potem začne pri tem odgovoru in ne pri viseči poizvedbi.