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

Прежде чем закрыть заявку, запишите, какой сеанс клиент отслеживал при подъёме туннеля. Именно эта строка превращает загадочный разрыв в воспроизводимое условие для следующего человека за машиной.