Keepalive — это не переподключение: выбирайте по имеющейся неисправности

Keepalive и переподключение настраивают одним духом, но решают разные задачи, поэтому настройка одного редко исправляет другое. Keepalive отправляет небольшой трафик, чтобы держать запись состояния живой или замечать, что партнёр перестал отвечать. Переподключение сносит сломанное и заново строит связь, включая ключи, адреса и маршруты. Выбирайте механизм, соответствующий неисправности, а не тот, чью ручку вы уже знаете. Это решают два вопроса: путь мёртв или что-то между партнёрами его забывает?

Когда проблема в сопоставлении

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

Эти настройки также не взаимозаменяемы между протоколами. Политика мёртвого партнёра в IKEv2, таймер ping в OpenVPN и keepalive в WireGuard отвечают на один вопрос тремя разными синтаксисами и тремя разными значениями по умолчанию, поэтому копирование числа между ними — догадка в одежде настройки.

Когда связь исчезла

Если партнёр меняет адрес, учётные данные истекают или дальняя сторона перезапускается, маленькие пакеты не являются ремонтом. Переподключение должно заново построить состояние : получить адрес, заново установить маршруты, заново согласовать ключи и в некоторых развёртываниях заново аутентифицировать пользователя.

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

Чего не доказывает ни то ни другое

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

Поэтому тест заканчивается реальным запросом. Отправьте что-нибудь через туннель после интересующего вас интервала, затем отдельно вызовите неисправность, под которую проектировали: период простоя для случая сопоставления, перезапуск или смену адреса для случая переподключения.

Блокировка прямого трафика — отдельное решение

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

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

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

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

Заметки WireGuard об ограничениях — полезное напоминание, что keepalive есть обходное решение для промежуточных устройств, а не общий проект живучести. Прочитайте это ограничение, прежде чем повышать частоту в ответ на проблему, которую оно не может решить.