OpenVPN keepalive чи рестарт systemd: що саме відновлює зв’язок?

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

Три відмови, що виглядають як одна

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

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

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

У що насправді розгортається keepalive

Директива keepalive — це скорочення, і розгортання відрізняється залежно від режиму. На сервері keepalive 10 60 стає локальним пінгом кожні десять секунд, локальним тайм-аутом перезапуску 120 секунд і переданими клієнтам значеннями 10 та 60. Серверний тайм-аут навмисно подвоєно, щоб клієнт мав шанс перезапуститися, перш ніж сервер здасться. Читайте розгорнуту форму в робочій конфігурації, а не скорочення в профілі.

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

Серцебиття — це трафік партнерів OpenVPN, а не ICMP-перевірка якогось публічного хоста. Відповідь лише доводить, що дальній кінець тунелю живий. Вона нічого не каже про базу даних або вебслужбу, яка насправді потрібна користувачеві.

Що Restart=on-failure не відстежує

Прочитайте встановлений unit, перш ніж додавати перевизначення. Restart=on-failure реагує на задокументовані умови відмови процесу, що не є тим самим, що й стеження за станом з’єднання. Він не спрацьовує через те, що почалося внутрішнє повторне підключення, і чистий вихід має іншу семантику, ніж аварійне завершення.

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

Встановіть RestartSec і обмеження запусків навмисно, інакше цикл аварійних завершень буде бити шлюз і ховати справжню помилку під повідомленнями про перезапуск. Спрацьоване обмеження перезапусків залишає unit у стані відмови, що видно, тоді як необмежений цикл — ні.

ping-restart і ping-exit не взаємозамінні

ping-restart запускає внутрішній перезапуск OpenVPN і зберігає процес. ping-exit завершує процес за такого самого тайм-ауту, що передає рішення менеджеру служб. Вони взаємовиключні, і вибір другого змінює, хто володіє відновленням. Різниця в тому, хто вирішує спробувати знову і скільки стану переживе спробу.

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

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

Перевіряйте кожну відмову як окремий випадок

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

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