Как перевести OpenConnect в фоновый режим после интерактивного входа

Вы завершаете запрос MFA, туннель поднимается, а закрытие терминала уносит соединение с собой. Это проблема надзора, а не аутентификации, и в OpenConnect уже есть переключатель, который её решает. Решение — дать клиенту ответвиться в фон после завершения запуска, когда интерактивная часть действительно закончена. Далее идёт последовательность проверок: пройдите их по порядку и остановитесь на первой, которая не подходит для вашего шлюза.

Подтвердите, что шлюз требует при входе

Прежде чем вводить команду, запишите путь учётных данных, который требует развёртывание. Только сертификат, пароль плюс токен и браузерный обход через поставщика SAML ведут себя по-разному, и фоновый режим не может пропустить ни один из них. Опция меняет то, что происходит после запуска, и никогда — во время него.

Соблазнительное решение — автоматизировать запрос. Обёртка, которая вводит фиксированный ответ при распознавании запроса пароля, ломается в момент, когда шлюз требует одноразовый код, и оставляет учётные данные в файле, читаемом другими учётными записями. Если сессию должен одобрить человек, оставьте человека в процессе.

Запустите первую сессию на переднем плане и прочитайте вывод

Подключитесь один раз нормально и дайте напечататься всему рукопожатию. Запишите используемый протокол, путь сертификата или токена, адрес туннеля, который выдаёт сервер, и каждое предупреждение до принятия соединения. Эта запись — ваша базовая линия и единственный дешёвый способ позже отличить проблему клиента от изменения шлюза. Сохраните её вне буфера терминала.

Затем повторите тот же вызов с фоновым режимом и добавленным PID-файлом, например openconnect --background --pid-file /run/openconnect.pid vpn.example.net, сохраняя протокол и параметры аутентификации, которые требует шлюз, в той же строке. Руководство OpenConnect описывает эту опцию как продолжение в фоне после завершения запуска, и именно поэтому интерактивная фаза должна закончиться первой.

Сделайте работающий процесс находимым и останавливаемым

PID-файл является доказательством только пока соответствует живому процессу. Поместите его в каталог, принадлежащий сервисной учётной записи, и сравните записанный номер с таблицей процессов перед отправкой любого сигнала. Перезагрузки и сбои оставляют файл, и устаревший файл — обычная причина того, что скрипт остановки сообщает об успехе, пока туннель ещё работает. Считайте проверку частью процедуры остановки, а не необязательным шагом.

Отправьте сигнал проверенному PID, затем подтвердите, что интерфейс туннеля действительно исчез, вместо того чтобы доверять коду выхода. Если клиенту нужны повышенные права для настройки интерфейса, сигнал должен исходить от учётной записи, которой разрешено его отправлять.

Не ставьте фоновый режим под супервизор

systemd и подобные супервизоры ожидают владеть запущенным процессом, поэтому клиент, который ответвляется, их путает. Супервизор видит выход лаунчера, пока реальное соединение живёт, поэтому логика перезапуска, отчёты о состоянии и тайм-ауты остановки описывают то, что уже неверно. Напишите юнит в поддерживаемой схеме переднего плана и оставьте супервизору работу демона.

Оставьте --background для сессий, которые человек запускает и затем уходит. Если требуется туннель, существующий до чьего-либо входа, не хватает утверждённой неинтерактивной личности и плана её обновления, и ни один флаг командной строки не даёт ни того, ни другого. Добавление флага в загрузочный скрипт создаёт туннель, который тихо отказывает при первых истёкших учётных данных.

Относитесь к cookie сессии как к учётным данным

OpenConnect документирует отдельную фазу аутентификации через --authenticate, и полученный материал можно вернуть с --cookie-on-stdin. Эта пара существует для интеграционной работы, и то, что она создаёт, так же чувствительно, как пароль, который его создал.

Держите значение вне истории оболочки, журналов и любого тикета, который вы открываете. Скрипт передачи также должен сохранять проверенную информацию о конечной точке, которую клиент получил вместе с cookie; если её потерять, более поздний запуск может подключиться к хосту, который вы никогда не аутентифицировали, что хуже, чем соединение, которое просто не удаётся.

Пройдите список, прежде чем закрыть терминал

Четыре вещи должны быть верны: интерактивный вход завершился на переднем плане, PID-файл указывает на проверенный процесс, вопрос с супервизором решён в ту или иную сторону, и у cookie есть план хранения, который не является простым текстовым файлом. Когда все четыре выполнены, уходить от терминала безопасно, и туннель продолжает работать.

Если одна из них не выполняется, исправьте этот пункт, прежде чем трогать остальные, потому что остальные проверки не могут его компенсировать. Сохраните и запись переднего плана первого запуска: в следующий раз, когда туннель упадёт без предупреждения, именно эта базовая линия отделит изменение на стороне шлюза от изменения на стороне клиента.