Як довго OpenConnect має повторювати спроби підключення до обірваного VPN?

--reconnect-timeout відповідає на одне вузьке питання: після падіння тунелю скільки часу цей клієнтський процес продовжує намагатися, перш ніж здатися й завершитися. Сторінка посібника OpenConnect фіксує цей параметр із задокументованим значенням за замовчуванням 300 секунд для повторних спроб після втраченого каналу або партнера, який перестав відповідати, і це число є строком для одного працюючого клієнта, а не доказом того, що VPN залишається доступним. Це також не політика підтримання процесу живим, і саме звідси починається більша частина плутанини.

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

Що насправді обмежує вікно повторного підключення

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

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

Вікно також не регулює, що роблять застосунки, поки воно триває. Залежно від платформи й від того, наскільки далеко зайшов збій, клієнт може перепідключатися, коли маршрути ще встановлені, або після їх вилучення. Тому запит, виданий посеред перерви, зазвичай висить до вичерпання часу очікування замість швидкої відмови.

Перезапуски супервізора й повторні спроби клієнта — два шари

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Дві деталі в цьому рядку мають вагу. --background відокремлює процес, тому файл pid стає єдиною надійною ручкою на нього, а час очікування витрачається лише поки цей самий процес живий; супервізор, який його вбиває, не залишає бюджету на продовження.

Навмисні відключення потребують власного сигналу. Планова пауза й справжній збій виглядають однаково для наївного спостерігача, і обидва читаються як «не підключено». Керуйте паузою через операцію зупинки супервізора або через маркер, який розуміє обгортка, щоб навмисна зупинка не викликала перезапуск, якого ніхто не просив.

Як не дати передачі обігнати цикл повторних спроб

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

Перевірку сервера не слід послаблювати заради зменшення запитів. Саме закріплення або якір довіри, що перевіряє шлюз, робить автоматичне перепідключення безпечним, а його вимкнення заради уникнення питання про сертифікат міняє видиму перерву на невидиму. Зберігайте перевірену ідентичність і натомість виправте запит; клієнт, готовий підключатися до будь-якого шлюзу, гірший за того, що зупиняється й чекає.

Наявність інтерфейсу теж не сигнал здоров’я. Тунельний пристрій може існувати з мертвим сеансом позаду, а процес запуску може існувати взагалі без тунелю. Жодне з цих спостережень не витримує справжнього запиту. Здоров’я має походити з того, що потрібно користувачеві, наприклад із запиту, що проходить тунелем до відомої внутрішньої служби.

Що перевіряти під час перерви й після неї

Проведіть чотири події як окремі тести: перерву, коротшу за вікно, збій, довший за нього, помилку автентифікації та навмисну зупинку. Кожна має завершитися в іншому, передбачуваному стані, і межа між першими двома — це вся причина вибору значення.

Тримайте перевірки спрямованими назовні, бо таблиця процесів сама по собі доводить дуже мало. Стежте, чи pid залишається стабільним під час короткого обриву, потім підтвердьте, що після довгого він зник і був замінений один раз:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Під час короткої перерви підтвердьте, що клієнт справді повторив спробу, а не вийшов раніше, і що маршрути та записи резолвера повернулися без дублікатів. Для довшого збою підтвердьте чистий вихід і рівно один перезапуск після нього. Для помилки автентифікації підтвердьте, що клієнт не крутиться проти шлюзу, який продовжить його відхиляти. Додайте перевірку, що pid повертається до одного значення, а не накопичується.

Для навмисної зупинки URL здоров’я має залишатися недоступним, а процес — зупиненим. Потім замкніть цикл з боку застосунку: той самий запит має зазнати невдачі, поки тунелю немає, і має успішно пройти після його повернення, з адреси джерела, якої очікує ваша політика. Зелений значок тунелю не доказ, а виконаний запит — доказ.