WireGuard PersistentKeepalive: когда нужен и как настроить

Что именно делает PersistentKeepalive

WireGuard обычно молчит, пока приложению действительно нечего отправлять. Это одна из причин низкой служебной нагрузки, но для NAT такая тишина имеет побочный эффект: таблица соответствий «внутренний адрес — внешний порт» может быть удалена после периода бездействия. После этого сервер продолжает знать публичный endpoint клиента только в том виде, в котором видел его раньше, а новая входящая датаграмма может уже не попасть к peer. PersistentKeepalive заставляет выбранный peer периодически отправлять небольшой служебный пакет, чтобы состояние NAT или stateful‑firewall не протухало. Это не отдельный канал управления и не механизм контроля качества связи. Параметр задаётся на стороне, которая находится за NAT и должна оставаться доступной после простоя. Если оба peer имеют публичные стабильные адреса или клиент всегда сам инициирует обмен перед получением данных, постоянные keepalive чаще всего не дают пользы.

Совет: Keepalive поддерживает сетевое состояние, а не «держит VPN быстрее». На задержку и пропускную способность обычного трафика он почти не влияет.

Как включить PersistentKeepalive без лишних изменений

1. Определите peer, который находится за NAT, CGNAT или строгим stateful‑firewall. Обычно это ноутбук, телефон, домашний роутер или удалённый узел в мобильной сети, а не сервер с публичным IP.
2. В конфигурации нужного peer добавьте строку `PersistentKeepalive = 25`. В CLI эквивалент можно задать через параметр `persistent-keepalive` для конкретного peer.
3. Перезапустите или перечитайте конфигурацию тем способом, который использует ваша система: wg-quick, NetworkManager, приложение WireGuard или сервис маршрутизатора.
4. Проверьте `wg show`: после паузы должны появляться свежие handshakes/передача, а входящий трафик к клиенту должен снова проходить без предварительного «пинга наружу».
5. Если задача решена, не уменьшайте интервал без причины. Более частые keepalive создают больше фоновых пакетов и могут быть нежелательны на батарейном или тарифицируемом соединении.

Важно: Не включайте PersistentKeepalive на всех peer «на всякий случай». WireGuard прямо указывает, что по умолчанию он выключен и большинству конфигураций не нужен.

Когда 25 секунд уместны, а когда лучше оставить 0

• Домашний клиент за NAT, к нему нужен доступ из VPN. 25 секунд — разумная отправная точка
• Телефон в LTE/5G, нужно получать входящий трафик после простоя. Часто полезно, но следите за батареей и политикой приложения
• Peer только сам инициирует короткие подключения. Обычно оставить 0
• Оба peer имеют стабильные публичные адреса. Обычно оставить 0
• Проблема — низкая скорость или высокий ping. Keepalive не лечит это; ищите MTU, маршрут, перегрузку

Почему слишком маленький интервал не является «надёжнее»

Интервал нужно выбирать по задаче, а не по принципу «чем чаще, тем лучше». Официальная документация WireGuard приводит 25 секунд как практичное значение, совместимое с широким диапазоном фаерволов. Если поставить 5 секунд, туннель не станет криптографически сильнее и не уменьшит задержку приложений, зато появится в пять раз больше фоновых keepalive. Для стационарного роутера это обычно не критично, но на смартфоне лишняя активность может чаще будить модем и расходовать батарею. С другой стороны, очень длинный интервал может не успеть обновить NAT-состояние в сети с коротким timeout. Поэтому разумная схема — начать с 25 секунд только там, где действительно нужна входящая достижимость, проверить поведение после нескольких минут простоя и не «тюнить» параметр без измеримой причины.

Предупреждение: Если связь обрывается именно при смене Wi‑Fi на мобильную сеть, причина может быть в смене endpoint/маршрута, а не в значении keepalive.

Как тестировать результат после паузы

Тест должен воспроизводить исходную проблему. Поднимите туннель, убедитесь, что обмен работает, затем оставьте peer без пользовательского трафика на тот промежуток, после которого раньше связь пропадала. Не инициируйте соединение со стороны клиента: попробуйте достучаться к нему с другой стороны туннеля. Если с `PersistentKeepalive = 25` входящий пакет проходит сразу, а без параметра для восстановления сначала требовался исходящий пакет от клиента, гипотеза о NAT выглядит убедительно. Одновременно посмотрите время последнего handshake и счётчики передачи в `wg show`. Если проблема сохраняется даже при свежем mapping, возвращайтесь к AllowedIPs, маршрутам, firewall и доступности endpoint. Keepalive не исправляет ошибочную адресацию.

Совет: Сравнивайте режимы A/B с одной изменяемой настройкой. Если одновременно поменять маршруты, DNS и keepalive, результат невозможно интерпретировать.

Признаки, что настройка применена по делу

• Туннель изначально работает без keepalive, но входящая достижимость теряется после простоя.
• Исходящий пакет от клиента раньше временно «оживлял» связь.
• После включения 25 секунд клиент остаётся доступен без ручного исходящего трафика.
• AllowedIPs, endpoint и маршруты уже проверены и не менялись во время теста.
• Параметр включён только на нужном peer, а не на всех участниках конфигурации.

Что не исправит keepalive

PersistentKeepalive не исправляет неверный `AllowedIPs`, неправильный endpoint, закрытый UDP-порт, конфликт маршрутов или отсутствующий форвардинг на сервере. Если peer вообще не устанавливает handshake, сначала разберите базовую связность. Keepalive имеет смысл только после того, как туннель уже работает и проблема проявляется именно после периода тишины. Такой порядок экономит время и не маскирует настоящую сетевую ошибку.

Дополнительная проверка по ситуации

Ещё один полезный признак — различать проблему простоя и проблему первого подключения. Если туннель не поднимается с самого начала, PersistentKeepalive почти наверняка не является первой настройкой, которую нужно трогать. Проверьте ключи, endpoint, порт, маршруты и firewall. Если же соединение устанавливается, работает, затем после длительной тишины входящий доступ исчезает и восстанавливается после исходящего пакета клиента, сценарий хорошо совпадает с истечением NAT-состояния. Такой симптом особенно характерен для узлов без публичного адреса. После настройки оставьте остальные параметры неизменными и сравните несколько циклов простоя: устойчивое повторение результата важнее единичного удачного теста.

Что учитывать

Интервал нужно выбирать по задаче, а не по принципу «чем чаще, тем лучше». Официальная документация WireGuard приводит 25 секунд как практичное значение, совместимое с широким диапазоном фаерволов. Если поставить 5 секунд, туннель не станет криптографически сильнее и не уменьшит задержку приложений, зато появится в пять раз больше фоновых keepalive. Для стационарного роутера это обычно не критично, но на смартфоне лишняя активность может чаще будить модем и расходовать батарею. С другой…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Quick Start — NAT and Firewall Traversal Persistence). Пример и формулировки — редакция N1RO на 2026-09-21.

• Quick Start — NAT and Firewall Traversal Persistence