Zabitý openconnect: trasy a DNS stále míří do tunelu

Tunel je dole, ale stroj se pořád chová, jako by byl nahoře: dotaz visí, dokud nevyprší, a trasa ukazuje do rozhraní, které už neexistuje. To je podpis procesu openconnect, který zemřel, aniž spustil svého pomocníka pro odpojení. Síťový stav, který vytvořil, je stále nainstalovaný a nic jiného v systému neví, jak ho odstranit.

Projděte stroj v pořadí, v jakém stav vznikal: proces, link, trasa, resolver. Každý krok vám řekne, zda klient skutečně zmizel, nebo se jen odpojil od vašeho terminálu, a tento rozdíl rozhoduje, zda vůbec něco opravovat.

Začněte procesem, ne konfigurací

Otevřete terminál a zeptejte se, co ještě běží, než se dotknete trasy. pgrep -a openconnect vypíše každou instanci s jejími argumenty, což ukáže pid soubor a skript, který jí byl dán. Proces, který jste nečekali, vysvětlí fantomový tunel rychleji než jakýkoli log.

Pokud nic neběží, podívejte se na link. ip link show tun0 vám řekne, zda rozhraní přežilo, a ip route show dev tun0 vypíše trasy, které jsou na něj stále vázané. Pak zkontrolujte resolver pomocí resolvectl status. Zapište všechny tři výstupy, než je změníte, protože právě tento záznam vám později umožní rozeznat zastaralý záznam od nového.

Rozhraní, které zmizí, obvykle vezme své trasy s sebou. Trasy, které link přežijí, obvykle znamenají, že proces je stále živý nebo že zařízení vlastní druhý klient.

Právě pomocný skript vrací změny zpět

openconnect sám neodstraňuje rozhraní, trasy ani záznamy v resolveru. Volá externího pomocníka, /etc/vpnc/vpnc-script v upstream sestavení a /usr/share/vpnc-scripts/vpnc-script v balíčcích Debian a Ubuntu, zvoleného pomocí -s. Stejný skript, který tunel staví, ho také bourá.

Pokud proces skončí, aniž by tohoto pomocníka zavolal, stav zůstane. příručka OpenConnect výslovně uvádí, že směrování a služba jmen nebudou bez skriptu fungovat správně, a popisuje pomocníka jako komponentu, která při ukončení rozebírá stav rozhraní. Proto na cestě záleží, když klienta spouštíte s -s.

Který signál se na tuto cestu dostane, se mezi verzemi změnilo. Příručka k 7.06 považuje SIGTERM za okamžité ukončení, které skript přeskočí. Současná sestavení dokumentují INT a TERM jako čisté zastavení, při němž se relace odhlásí a pomocník se spustí. Čtěte sekci SIGNALS binárky, kterou skutečně máte, místo abyste předpokládali jedno z obou chování.

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

Pošlete signál, který vaše sestavení dokumentuje

Když signál znáte, zastavte proces podle pid, ne podle vzoru.

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

Pak zopakujte tři kontroly z první části, místo abyste věřili návratovému kódu. ip link show tun0 by měl selhat, ip route show dev tun0 by neměl nic vypsat a resolvectl status by už neměl vypisovat VPN link.

SIGHUP není tlačítko stop: odpojí se, spustí skript a nechá relaci obnovitelnou s --cookie. SIGUSR2 vynutí okamžité opětovné připojení. SIGKILL zcela přeskočí úklid, což je přesně stav, o kterém je tento článek.

Opravte resolver bez nahrazení resolv.conf

Na většině systémů Ubuntu je /etc/resolv.conf symbolický odkaz do systemd-resolved, ne soubor, který byste měli upravovat. Jeho nahrazení rozbije překlad jmen pro každou síť, ne jen VPN. Místo toho zrušte registraci tunelu:

resolvectl revert tun0
resolvectl query example.com

Pokud systém používá resolvconf místo systemd-resolved, záznam pro rozhraní přetrvá, dokud se mu neřekne, aby link uvolnil, a resolvconf -d tun0 je ekvivalentní akce. Před výběrem příkazu zkontrolujte, který resolver se používá.

Dotaz stále mířící na server za mrtvým linkem visí, dokud nevyprší, a to zpoždění vypadá spíš jako rozbitý DNS server než jako zbylá trasa.

Udělejte příští odpojení nudným

Udržujte cestu k pid souboru stejnou při startu i vypnutí tím, že budete předávat --pid-file pokaždé, nebo spusťte openconnect pod unitem jehož KillSignal odpovídá signálu, který vaše verze dokumentuje. Testování nejprve v popředí vám ukáže zprávy o vypnutí, které pomocník tiskne.

Připojte se, odpojte se a jednou spusťte tři kontroly. Čisté ukončení nezanechá žádný VPN link, žádnou VPN trasu ani žádný záznam VPN resolveru. Pokud jedna ze tří přežije, už víte, která komponenta úklid nezvládla. Další vyšetřování pak začíná od této odpovědi, ne od visícího dotazu.