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. Для більшості найменш нав'язливе рішення просто запускати клієнт із сеансу, який залишиться відкритим на весь день, і не чіпати те вікно.

Перш ніж закрити заявку, запишіть, який сеанс клієнт відстежував на момент підняття тунелю. Саме цей рядок перетворює загадковий розрив на відтворювану умову для наступної людини за машиною.