Что делает PersistentKeepalive в WireGuard?

WireGuard PersistentKeepalive отправляет аутентифицированный пустой пакет, когда в течение заданного интервала локальная сторона не передавала трафик определённому пиру. У этой функции узкая задача: сохранить запись NAT или межсетевого экрана с отслеживанием состояния, чтобы находящийся за таким устройством пир оставался доступен после периода тишины. Она не проверяет исправность интернета, не восстанавливает сломанный маршрут и не гарантирует непрерывность приложения.

Полное руководство по VPN описывает весь защищённый путь. Здесь мы рассматриваем только необязательный таймер для отдельного пира, чтобы вы могли понять, действительно ли тихому соединению нужен служебный трафик.

Ключевые выводы

• PersistentKeepalive по умолчанию выключен и настраивается отдельно для каждого пира.
• После отсутствия исходящего трафика он отправляет аутентифицированный пакет без полезной нагрузки приложения.
• Его задача — обновить состояние NAT или межсетевого экрана, а не проверять работоспособность туннеля.
• 25 секунд — распространённый официальный пример, но не обязательное значение для любой сети.
• Обычно пакет отправляет пир за NAT, которому требуется входящая доступность; включение повсюду создаёт лишний трафик и пробуждения устройства.

Что такое WireGuard PersistentKeepalive?

Руководство wg(8) определяет PersistentKeepalive как необязательный интервал в секундах от 1 до 65 535. Если за этот интервал пир не получил исходящего трафика, WireGuard отправляет ему аутентифицированный пустой пакет. Ноль или off отключает поведение, и именно это является настройкой по умолчанию.［1］

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

Параметр относится к конкретному пиру, а не создаёт один глобальный пульс интерфейса. Ноутбуку могут требоваться keepalive-пакеты для одного удалённого пира, тогда как другой пир со стабильным публичным адресом в них не нуждается. Интервал задаёт отправляющая сторона; удалённый пир не командует ей применять определённую частоту.

Такое разделение согласуется с обзором протоколов VPN: WireGuard предоставляет зашифрованный UDP-туннель и состояние пиров, а у операционной системы, сети доступа и приложений есть собственные таймеры и правила отказа.

Почему неактивное состояние NAT и межсетевого экрана истекает?

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

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

В техническом описании WireGuard keepalive-пакеты названы полезными, когда пир за NAT или межсетевым экраном должен оставаться доступен во время простоя. Там же подчёркивается, что большинству пиров они не нужны: без данных WireGuard намеренно молчит.［2］ Отсутствие фонового обмена экономит канал и позволяет мобильному устройству дольше спать.

Обозначения на схеме: 1 — молчащий пир за пограничным устройством; 2 — временное отображение NAT или запись межсетевого экрана; 3 — удалённый пир, которому позже может понадобиться отправить данные первым; 4 — интервал бездействия, после которого аутентифицированная пустая UDP-дейтаграмма обновляет запись. Стрелки показывают направление дейтаграмм, а не запрос и ответ проверки работоспособности.

Почему обычного трафика часто достаточно

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

Поэтому требования «туннель передаёт данные весь день» и «неактивный пир доступен весь день» различаются. Проверяйте именно простой. Не включайте периодический пакет только потому, что название напоминает универсальный переключатель надёжности.

Почему часто выбирают 25 секунд, но значение не обязательно

И руководство, и официальный краткий пример называют 25 секунд разумным интервалом для сохранения многих отображений NAT и межсетевых экранов.［1］［2］ Он намеренно короче распространённых тайм-аутов неактивного UDP, однако документы не объявляют его константой протокола. WireGuard принимает другие ненулевые интервалы, а конкретная сеть может удалять состояние раньше или позже.

Слишком короткий интервал означает больше дейтаграмм, пробуждений радиомодуля и работы сервера. Более длинный уменьшает накладные расходы, но агрессивное промежуточное устройство может первым удалить отображение. Практичным будет наибольший интервал, который с разумным запасом остаётся меньше нужного тайм-аута. Домашние роутеры, мобильные сети, корпоративные экраны и разные версии прошивки могут вести себя неодинаково.

Не подбирайте значение по задержке ping. Время кругового пути показывает, сколько идёт пакет по работающему пути, но ничего не говорит о сроке хранения неактивного UDP-состояния. Интервал в одну секунду также не исправит путь, где UDP заблокирован или маршрут ошибочен.

Ситуация	Типичное решение	Причина
Публично доступный сервер	Обычно выключить	Он может принять новую аутентифицированную инициацию
Клиент за NAT, который только инициирует обмен	Обычно выключить	Новый исходящий трафик при необходимости создаст состояние заново
Клиент за NAT должен принимать после простоя	Часто полезно	Периодический исходящий пакет сохраняет обратное отображение
Активный туннель с частым двусторонним обменом	Часто не требуется	Существующий трафик уже обновляет состояние
UDP заблокирован на пути	Не помогает	Дополнительные UDP-пакеты не снимают блокировку

Чего PersistentKeepalive не делает

PersistentKeepalive — не echo-запрос с обязательным ответом. Отправитель не узнаёт, что путь исправен, лишь потому, что передал пакет. Время последнего рукопожатия и счётчики обмена дают полезные наблюдения, но сам keepalive не является полноценным протоколом проверки доступности. Он не проверяет DNS, системную маршрутизацию, доступ в интернет или конкретное приложение.

Функция также не выбирает удалённый адрес. Разбор Endpoint объясняет внешний IP или имя хоста и UDP-порт. Keepalive не решает, какому пиру принадлежит внутренний адрес назначения: за это отвечает AllowedIPs, а перед ним — таблица маршрутов системы.

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

Рабочий туннель WireGuard не гарантирует непрерывность каждой программы. TCP-сеансы, потоковое аудио, DNS-кэши, страницы авторизации, сон операционной системы и политика повторов приложения могут независимо реагировать на изменение внешнего пути.

Какой пир должен отправлять пакеты

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

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

Помощник wg-quick(8) может выводить системные маршруты из AllowedIPs, но эта автоматизация не связана с таймером keepalive.［3］ Маршрут может существовать при устаревшем отображении NAT; отображение может быть живым, когда система выбрала другой маршрут. Диагностируйте уровни отдельно.

Чтобы увидеть, как управляемый клиент ведёт себя после простоя, подключите AethoVPN на телефоне за тем же NAT, оставьте его без активности на интервал, при котором ломается ваш собственный пир, затем откройте страницу и отметьте, восстанавливается ли работа сразу, происходит ли переподключение или нужна ручная повторная попытка. Повторите один раз с другой локацией, чтобы один загруженный сервер не исказил результат. Продукт не документирует настройку keepalive и не обещает непрерывного соединения, поэтому записывайте фактическое поведение клиента, а не предполагайте интервал в 25 секунд. Начните бесплатный пробный период по email для проверки простоя.

Как проверить гипотезу о keepalive

Сначала сравните активное соединение с простоем. Если непрерывная передача всегда работает, но удалённый пир перестаёт достигать клиента после предсказуемой тишины, истечение состояния выглядит правдоподобно. Запишите длительность и проверьте, восстанавливает ли связь один новый пакет, инициированный клиентом.

Затем разделите доказательства:

1. Убедитесь, что пир завершает аутентифицированное рукопожатие на текущем пути.
2. Проверьте, что нужный внутренний адрес связан с правильным пиром и маршрутом.
3. Посмотрите, создают ли исходящие данные клиента новый доступный путь после простоя.
4. Испытайте консервативный ненулевой интервал короче наблюдаемого окна отказа.
5. Сопоставьте рукопожатие, счётчики и захват пакетов, не считая сам факт отправки подтверждением ответа.

Если туннель ломается даже во время постоянного обмена, причина, вероятно, не в неактивном отображении. Проверяйте достижимость Endpoint, политику UDP, ключи, время, маршруты, MTU и приложение. Узкий таймер не должен маскировать более широкий отказ.

Итоги

• PersistentKeepalive после исходящего простоя отправляет аутентифицированный пустой пакет.
• Он сохраняет состояние NAT или межсетевого экрана для пира, который должен оставаться доступным.
• По умолчанию функция выключена; активным и только инициирующим пирам она обычно не нужна.
• 25 секунд — официальный пример, а не универсально оптимальный интервал.
• Функция не проверяет работоспособность, не выбирает маршрут, не определяет личность и не гарантирует продолжение приложения.

Часто задаваемые вопросы (FAQ)

Передаёт ли PersistentKeepalive данные приложения?

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

Включён ли PersistentKeepalive по умолчанию?

Нет. Ноль или off означает отключение, и это значение по умолчанию. Ненулевой интервал для пира нужен только при конкретном требовании доступности после простоя.

Почему в примерах указано 25 секунд?

Это практичный интервал, который должен быть короче многих тайм-аутов UDP в NAT и межсетевых экранах. Он не является константой и не обещает результат в любой сети.

Нужно ли включать функцию у обоих пиров?

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

Доказывает ли keepalive, что пир в сети?

Нет. Отправка доказывает только попытку локальной системы. Для оценки доступности используйте время рукопожатия, счётчики, журналы и контролируемый обмен.

Исправит ли PersistentKeepalive блокировку UDP?

Нет. Если UDP заблокирован, Endpoint ошибочен или маршрут сломан, повторные UDP-дейтаграммы не устранят исходную причину.

Делает ли PersistentKeepalive роуминг бесшовным?

Нет. Аутентифицированные пакеты позволяют узнать Endpoint после смены адреса. Keepalive может сохранить или активировать путь, но сеансы приложений и переходы системы имеют отдельные правила.

Источники:

1. WireGuard Tools, wg(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
2. WireGuard, “WireGuard: Next Generation Kernel Network Tunnel”: https://www.wireguard.com/papers/wireguard.pdf
3. WireGuard Tools, wg-quick(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8

Sources checked 12 сентября 2026 г.

---

Рекомендуемые статьи:

• Разобрать полный путь VPN
• Сравнить основные протоколы VPN
• Проверить, почему VPN не работает после выхода из сна
• Отделить Endpoint WireGuard от маршрута туннеля