Zabitý openconnect: trasy a DNS stále mieria do tunela

Tunel je dole, ale stroj sa stále správa, ako keby bol hore: dopyt visí, kým nevyprší, a trasa ukazuje do rozhrania, ktoré už neexistuje. To je podpis procesu openconnect, ktorý zomrel bez spustenia svojho pomocníka na odpojenie. Sieťový stav, ktorý vytvoril, je stále nainštalovaný a nič iné v systéme nevie, ako ho odstrániť.

Prejdite stroj v poradí, v akom stav vznikal: proces, spojenie, trasa, resolver. Každý krok vám povie, či klient naozaj zmizol alebo sa len odpojil od vášho terminálu, a tento rozdiel rozhoduje, či vôbec niečo opravovať.

Začnite procesom, nie konfiguráciou

Otvorte terminál a opýtajte sa, čo ešte beží, skôr než sa dotknete trasy. pgrep -a openconnect vypíše každú inštanciu s jej argumentmi, čo ukáže pid súbor a skript, ktorý jej bol daný. Proces, ktorý ste nečakali, vysvetlí fantómový tunel rýchlejšie než akýkoľvek log.

Ak nič nebeží, pozrite sa na spojenie. ip link show tun0 vám povie, či rozhranie prežilo, a ip route show dev tun0 vypíše trasy, ktoré sú naň stále naviazané. Potom skontrolujte resolver pomocou resolvectl status. Zapíšte všetky tri výstupy pred ich zmenou, pretože práve tento záznam je spôsob, ako neskôr rozlíšiť zastaraný záznam od nového.

Rozhranie, ktoré zmizne, si zvyčajne vezme svoje trasy so sebou. Trasy, ktoré prežijú spojenie, zvyčajne znamenajú, že proces je stále živý alebo že zariadenie vlastní druhý klient.

Práve pomocný skript vracia zmeny späť

openconnect sám neodstraňuje rozhranie, trasy ani záznamy v resolveri. Volá externého pomocníka, /etc/vpnc/vpnc-script v upstream zostavení a /usr/share/vpnc-scripts/vpnc-script v balíkoch Debian a Ubuntu, zvoleného pomocou -s. Ten istý skript, ktorý tunel stavia, ho aj rozoberá.

Ak proces skončí bez zavolania tohto pomocníka, stav zostane. príručka OpenConnect výslovne uvádza, že smerovanie a služba mien nebudú bez skriptu fungovať správne, a opisuje pomocníka ako komponent, ktorý pri ukončení rozoberá stav rozhrania. Preto na ceste záleží, keď klienta spúšťate s -s.

Ktorý signál sa na túto cestu dostane, sa medzi verziami zmenilo. Príručka k 7.06 považuje SIGTERM za okamžité ukončenie, ktoré skript preskočí. Súčasné zostavenia dokumentujú INT a TERM ako čisté zastavenie, pri ktorom sa relácia odhlási a pomocník sa spustí. Čítajte sekciu SIGNALS binárky, ktorú skutočne máte, namiesto toho, aby ste predpokladali jedno z oboch správaní.

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

Pošlite signál, ktorý dokumentuje vaše zostavenie

Keď signál poznáte, zastavte proces podľa pid, nie podľa vzoru.

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

Potom zopakujte tri kontroly z prvej časti, namiesto toho, aby ste dôverovali návratovému kódu. ip link show tun0 by malo zlyhať, ip route show dev tun0 by nemalo nič vypísať a resolvectl status by už nemalo vypisovať VPN spojenie.

SIGHUP nie je tlačidlo stop: odpojí sa, spustí skript a nechá reláciu obnoviteľnú s --cookie. SIGUSR2 vynúti okamžité opätovné pripojenie. SIGKILL úplne preskočí upratovanie, a to je presne stav, o ktorom je tento článok.

Opravte resolver bez nahradenia resolv.conf

Na väčšine systémov Ubuntu je /etc/resolv.conf symbolický odkaz do systemd-resolved, nie súbor, ktorý by ste mali upravovať. Jeho nahradenie pokazí preklad mien pre každú sieť, nielen pre VPN. Namiesto toho zrušte registráciu tunela:

resolvectl revert tun0
resolvectl query example.com

Ak systém používa resolvconf namiesto systemd-resolved, záznam pre rozhranie pretrvá, kým sa mu nepovie, aby spojenie uvolnil, a resolvconf -d tun0 je ekvivalentná akcia. Pred výberom príkazu skontrolujte, ktorý resolver sa používa.

Dopyt stále mieriaci na server za mŕtvym spojením visí, kým nevyprší, a to oneskorenie vyzerá skôr ako pokazený DNS server než ako zvyšná trasa.

Urobte nasledujúce odpojenie nudným

Udržujte cestu k pid súboru rovnakú pri štarte aj vypnutí tým, že budete odovzdávať --pid-file zakaždým, alebo spustite openconnect pod unitom ktorého KillSignal zodpovedá signálu, ktorý dokumentuje vaša verzia. Testovanie najprv v popredí vám ukáže správy o vypnutí, ktoré pomocník tlačí.

Pripojte sa, odpojte sa a raz spustite tri kontroly. Čisté ukončenie nezanechá žiadne VPN spojenie, žiadnu VPN trasu ani žiadny záznam VPN resolvera. Ak jedna z troch prežije, už viete, ktorá komponenta upratovanie nezvládla. Ďalšie vyšetrovanie potom začína od tejto odpovede, nie od visiaceho dopytu.