Keepalive — це не перепідключення: обирайте за наявною несправністю

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

Коли проблема в зіставленні

Тунель, який умирає лише після хвилин тиші, зазвичай втрачає запис трансляції, а не партнера. Опція PersistentKeepalive у WireGuard існує для стану NAT і міжмережевого екрана, і власні нотатки проєкту описують її саме так, а не як перевірку працездатності. Інтервал у кілька десятків секунд тримає запис теплим, тоді як пакет щосекунди — це рішення про батарею, а не про надійність. OpenVPN приходить до того самого через ping і ping-restart , які спершу помічають тишу, а потім діють за нею.

Ці налаштування також не взаємозамінні між протоколами. Політика мертвого партнера в IKEv2, таймер ping в OpenVPN і keepalive у WireGuard відповідають на одне питання трьома різними синтаксисами і трьома різними типовими значеннями, тому копіювання числа між ними — здогад у вбранні налаштування.

Коли зв'язок зник

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

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

Чого не доводить жодне з них

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

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

Блокування прямого трафіку — окреме рішення

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

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

Напишіть політику, а не лише число

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

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