Як перевести 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 має план зберігання, який не є звичайним текстовим файлом. Коли всі чотири виконуються, відхід від термінала безпечний, і тунель продовжує працювати.

Якщо одна з них не виконується, виправте цей пункт, перш ніж торкатися інших, бо решта перевірок не може його компенсувати. Збережіть і запис переднього плану першого запуску: наступного разу, коли тунель упаде без попередження, саме ця базова лінія відокремить зміну на боці шлюзу від зміни на боці клієнта.