AnyConnect пада при затваряне на терминал: проверки на сесиите

Тунелът работи, затваряте резервен терминал и VPN-ът пада без нито едно натискане на клавиш в клиента. При клиента AnyConnect за Linux съобщената причина е отчитане на сесиите, а не маршрутизация: клиентът записва кои сесии за вход са съществували при вдигането на тунела и приема края на която и да е от тях като причина да го разруши. Проверките по-долу се изпълняват по ред и първата неуспешна ви казва дали изобщо гледате това поведение. Нищо в обичайния изход на клиента не споменава терминал, затова първият инстинкт, да обвините концентратора, обикновено е похабен труд.

Не започвайте с редактиране на системни файлове. Всяка стъпка или обяснява падането, или премахва кандидат, а евтините стъпки идват първи.

Отделете падане на сесия от падане на мрежата

Свържете се отново веднага след прекъсването. Тунел, който се връща за секунди, в същата мрежа, без нови идентификационни данни, сочи локален спусък като затворена сесия, а не мъртва връзка, роуминг на Wi-Fi или изтичане на времето за бездействие на концентратора. Тунел, който засича на Connecting или не се вдига, докато не смените мрежата, е друга статия.

Запишете какво е било отворено при вдигането на тунела: терминала, от който сте стартирали клиента, всяка втора обвивка, графичния вход и всяка SSH сесия от друга машина. Ще ви трябва този списък след малко, а възстановяването му по памет след следващото падане е ненадеждно.

Проверете какво е записал клиентът при свързването

Клиентът не изследва родителските процеси или собствеността на терминала. Той прави снимка на множеството сесии за вход, налични при свързването, и по-късно сравнява това множество; когато член изчезне, сравнението се проваля и тунелът си отива с него. Затова затварянето на прозореца, от който сте се свързали, може да е безвредно, докато затварянето на несвързан резервен терминал убива връзката: важно е дали тази сесия е била в първоначалното множество. Проверката е сравнение на множества, а не броене, затова замяната на сесия може да е толкова фатална, колкото загубата на една.

Изброите какво е могъл да види клиентът, преди да промените нещо:

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

Всеки ред от who е запис за потребителски процес в utmp. Ако сесията ви се появи два пъти, веднъж за графичния вход и веднъж за терминала, и двата записа са съществували при свързването и двата са кандидати.

Премахнете само своя запис от utmp

Публикуваното заобикалящо решение прави сесията, която ще използвате, невидима в utmp преди стартирането на клиента. Малка програма на C обхожда getutent(), намира записа, чието ut_line е равно на TTY на стандартния вход, и след това презаписва този запис. Редът е умишлен: setutent(), прочетете записа, копирайте неговото ut_id, задайте ut_type на DEAD_PROCESS, изчистете полетата за потребител и ред, запишете го обратно с pututline(), след това endutent().

Компилирайте го, след което го стартирайте като root от обвивката, която ще стартира клиента:

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

Два режима на отказ обясняват повечето доклади, че инструментът не прави нищо. Той действа върху TTY, свързан със стандартния вход, затова стартирането от скрипт или задача на cron без терминал не му оставя нищо за съпоставяне. И /run/utmp не е достъпен за запис от обикновени потребители, затова стартиране без root се проваля безшумно, освен ако не проверите кода на изхода.

Проверете дали тунелът оцелява при затварянето

Изпробвайте механизма, вместо да го предполагате. Свържете се от сесия, която смятате да задържите, отворете втори терминал, затворете втория, след което потвърдете, че тунелът още работи с vpn state и поглед към списъка с интерфейси. Ако тунелът оцелее, спусъкът е бил конкретен тип сесия, а не всяка сесия, и сте намерили сесията, която трябва да остане отворена.

Ако все още пада, наблюдаваната сесия е била другаде, най-често графичният вход, който е създал терминала ви, и премахването на един запис на TTY няма да помогне. Повторете наблюдението с пълния списък от първата стъпка, вместо да добавяте още хирургия.

Когато презаписът на utmp е грешният отговор

utmp е споделено отчитане, а не частна таблица. Презаписването на записа на сесия, която е още жива, кара who, w и някои инструменти за одит да я отчитат под реалното, а програма, която по-късно затвори същия запис, може да се провали напълно. Дръжте инструмента ограничен до собствената си сесия, пазете копие на оригиналния файл и не го превръщайте в услуга при зареждане, която заличава всеки запис.

Ако вашият обект събира отчитане на сесии за съответствие, заобикалящото решение противоречи на това изискване и поддържаният отговор е версия на клиента или различен метод за достъп, а не пачнат utmp. За повечето хора най-малко инвазивното решение е просто да стартират клиента от сесия, която ще остане отворена цял ден, и да оставят този прозорец на мира.

Преди да затворите тикета, запишете коя сесия е наблюдавал клиентът при вдигането на тунела. Именно този един ред превръща мистериозното прекъсване във възпроизводимо условие за следващия човек на машината.