AnyConnect spadne při zavření terminálu: kontroly relací

Tunel běží, zavřete jeden přebytečný terminál a VPN spadne, aniž byste v klientovi stiskli jedinou klávesu. U linuxového klienta AnyConnect je hlášenou příčinou účtování relací, nikoli směrování: klient si zaznamená, které přihlašovací relace existovaly při navázání tunelu, a konec kterékoli z nich považuje za důvod tunel strhnout. Následující kontroly se provádějí v pořadí a první neúspěšná vám řekne, zda vůbec toto chování řešíte. Nic v obvyklém výstupu klienta nezmiňuje terminál, a proto je první instinkt, obviňovat koncentrátor, obvykle zbytečná práce.

Nezačínejte úpravou systémových souborů. Každý krok buď výpadek vysvětlí, nebo odstraní kandidáta, a levné kroky jdou první.

Oddělte výpadek relace od výpadku podkladové sítě

Po odpojení se okamžitě připojte znovu. Tunel, který se vrátí během sekund, na stejné síti, bez nových přihlašovacích údajů, ukazuje na místní spouštěč, jako je zavřená relace, a ne na mrtvý uplink, roaming Wi-Fi nebo časový limit nečinnosti na koncentrátoru. Tunel, který visí na Connecting nebo selhává, dokud nezměníte síť, patří do jiného článku.

Zapište, co bylo otevřené při navázání tunelu: terminál, ze kterého jste klienta spustili, případný druhý shell, grafické přihlášení a jakoukoli relaci SSH z jiného stroje. Ten seznam budete za chvíli potřebovat a rekonstruovat ho po dalším výpadku z paměti je nespolehlivé.

Zkontrolujte, co klient při připojení zaznamenal

Klient nezkoumá rodičovské procesy ani vlastnictví terminálu. Pořídí snímek množiny přihlašovacích relací přítomných při připojení a tuto množinu později porovná; když člen zmizí, porovnání selže a tunel jde s ním. Proto může být zavření okna, ze kterého jste se připojili, neškodné, zatímco zavření nesouvisejícího přebytečného terminálu spojení zabije: rozhoduje, zda byla ta relace v původní množině. Kontrola je porovnání množin, nikoli počítání, a proto může být nahrazení relace stejně fatální jako ztráta jedné z nich.

Vypište, co klient mohl vidět, než cokoli změníte:

who
w
last -n 10
sudo ls -l /run/utmp

Každý řádek z who je záznam uživatelského procesu v utmp. Pokud se vaše relace objeví dvakrát, jednou za grafické přihlášení a jednou za terminál, existovaly při připojení oba záznamy a oba jsou kandidáty.

Odeberte z utmp jen svůj vlastní záznam

Zveřejněný workaround udělá relaci, kterou se chystáte použít, neviditelnou v utmp ještě před spuštěním klienta. Malý program v C projde getutent(), najde záznam, jehož ut_line se rovná TTY standardního vstupu, a tento záznam pak přepíše. Pořadí je záměrné: setutent(), načíst záznam, zkopírovat jeho ut_id, nastavit ut_type na DEAD_PROCESS, vymazat pole uživatele a řádku, zapsat ho zpět pomocí pututline() a potom endutent().

Zkompilujte ho a poté ho spusťte jako root z shellu, který bude klienta spouštět:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

Dva režimy selhání vysvětlují většinu hlášení, že nástroj nic nedělá. Působí na TTY připojené ke standardnímu vstupu, takže spuštění ze skriptu nebo z úlohy cron bez terminálu mu nenechá co porovnat. A /run/utmp není pro běžné uživatele zapisovatelný, takže běh bez rootu tiše selže, pokud nezkontrolujete návratový kód.

Ověřte, že tunel zavření přežije

Otestujte mechanismus, místo abyste ho předpokládali. Připojte se z relace, kterou hodláte držet, otevřete druhý terminál, zavřete ten druhý a poté pomocí vpn state a pohledu na seznam rozhraní potvrďte, že tunel stále běží. Pokud přežije, byl spouštěčem konkrétní typ relace, nikoli každá relace, a našli jste relaci, která musí zůstat otevřená.

Pokud stále padá, sledovaná relace byla jinde, nejčastěji grafické přihlášení, které zplodilo váš terminál, a odstranění jednoho záznamu TTY nepomůže. Zopakujte pozorování s úplným seznamem z prvního kroku, místo abyste přidávali další chirurgii.

Kdy je přepsání utmp špatná odpověď

utmp je sdílené účtování, ne soukromá tabulka. Přepsání záznamu relace, která je stále živá, způsobí, že who, w a některé auditní nástroje ji vykazují nižší, a program, který stejný záznam později zavře, může úplně selhat. Omezte nástroj na svou vlastní relaci, uchovejte kopii původního souboru a nepřeměňujte ho ve spouštěcí službu, která odstraní každý záznam.

Pokud vaše organizace sbírá účtování relací kvůli souladu, je workaround v rozporu s tímto požadavkem a podporovanou odpovědí je jiná verze klienta nebo jiný způsob přístupu, ne záplatovaný utmp. Pro většinu lidí je nejméně invazivní opravou prostě spustit klienta z relace, která zůstane otevřená celý den, a nechat to okno být.

Než ticket zavřete, zaznamenejte, kterou relaci klient sledoval, když tunel vznikl. Právě ten jediný řádek mění záhadné odpojení v reprodukovatelnou podmínku pro dalšího člověka u stroje.