Почему WireGuard работает только первые несколько минут: причины и решение

Коротко: WireGuard обрывается: в большинстве случаев причина — отсутствие PersistentKeepalive на стороне клиента за NAT, автоматическое закрытие состояний на промежуточном оборудовании или конфликт маршрутов. Обычно достаточно включить параметр PersistentKeepalive на клиенте, задать значение 25 секунд и убедиться, что правила фаервола не сбрасывают UDP-сессии.

Если ваше VPN-соединение по протоколу WireGuard обрывается уже через несколько минут после установки туннеля, проблема скорее всего кроется в настройках keepalive, брандмауэра или маршрутизации. Такое поведение особенно характерно при работе клиента за NAT без специальных мер по поддержанию канала.

Как WireGuard поддерживает туннель

WireGuard — протокол с минимальным служебным трафиком. Пока через туннель идут пакеты, соединение активно. Если трафика нет, оба пира могут считать друг друга недоступными, поскольку обмен ключами не требует постоянного keepalive. Состояние туннеля определяется по последнему полученному аутентифицированному пакету.

Если после успешного handshake туннель перестает передавать данные, а внешние NAT-устройства или брандмауэры удаляют состояние проброса, пакеты перестают доходить, и соединение разрывается. В этом отличие от VPN-протоколов с постоянной heartbeat-логикой.

• Handshake обновляет сессию каждые несколько минут только при активном трафике.
• Для idle-туннеля без keepalive UDP-проброс на NAT может быть закрыт уже через 30-120 секунд.

Настройка Persistent Keepalive

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

Добавьте в конфигурацию клиента (в секции [Peer] для удаленного сервера) опцию PersistentKeepalive = 25. Значение в секундах. Для большинства домашних сетей 25 секунд достаточно; при агрессивных таймаутах провайдера можно опуститься до 15.

1. Откройте конфигурационный файл клиента WireGuard (или интерфейс управления).
2. В секции [Peer] найдите строки, описывающие сервер.
3. Добавьте после AllowedIPs строку: PersistentKeepalive = 25.
4. Сохраните конфигурацию и перезапустите интерфейс (wg-quick down/up или через GUI).
5. Проверьте командой wg show, что handshake происходят регулярно.

Важно: Значение 0 отключает keepalive. Держите его в диапазоне 15–30 секунд — излишне частые пакеты создают ненужную нагрузку, но не ломают туннель.

Влияние брандмауэра и NAT-таймаутов

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

На серверной стороне маршрутизатор или хост-брандмауэр также должен разрешать входящий UDP на порт WireGuard (по умолчанию 51820) и сохранять сессию. Правила должны явно принимать пакеты с установленным состоянием RELATED,ESTABLISHED, а исходящие — без дополнительных ограничений.

• Убедитесь, что на клиентском роутере не включен жесткий фильтр UDP-портов.
• Проверьте серверный iptables/nftables: правило должно принимать INPUT на порт wg.
• Некоторые мобильные операторы сбрасывают UDP-сессии через 20–30 секунд — PersistentKeepalive должен быть чаще этого интервала.

Проблемы маршрутизации и AllowedIPs

Параметр AllowedIPs определяет, какие IP-адреса и подсети направляются в туннель. Если он задан слишком узко или перекрывает локальные сети, возвратный трафик может пойти не в туннель, а в основной шлюз. Это вызывает разрыв на уровне приложений: handshake проходит, но данные не могут вернуться обратно.

На стороне клиента укажите маршруты так, чтобы не было конфликта с локальной сетью. Например, если ваш локальный адрес 192.168.1.0/24, не включайте его в AllowedIPs на стороне сервера для этого клиента.

• Ошибочно указано AllowedIPs = 0.0.0.0/0, а сам клиент находится в той же сети, что и сервер — возникает петля маршрутизации.
• Сервер не имеет маршрута к IP-адресу клиента за NAT.
• На сервере отсутствует MASQUERADE или SNAT для трафика из туннеля.

Важно: При конфликте маршрутов туннель может оставаться ‘активным’ в wg show, но пинг не проходит.

Диагностика с помощью журналов и команд

Для точного определения причины используйте встроенные средства отладки. Команда wg show покажет время последнего handshake и количество переданных/принятых байт. Если handshake обновляется, но данные не идут — проблема маршрутизации. Если handshake пропадает и не восстанавливается — проблема keepalive или блокировки.

На системах Linux включите динамический лог ядра: echo 'module wireguard +p' > /sys/kernel/debug/dynamic_debug/control. Затем просматривайте syslog. На роутерах MikroTik RouterOS с поддержкой WireGuard используйте /log print, где можно отфильтровать сообщения по темам wireguard,handshake.

Проверка результата

• Проверьте наличие опции PersistentKeepalive в конфигурации клиента.
• Убедитесь, что серверный порт (UDP 51820 или другой) открыт для входящих пакетов.
• Выполните wg show и сравните время handshake с фактическими обрывами.
• Проверьте правила NAT/SNAT на сервере, если клиент работает за NAT.
• Исключите конфликт IP-адресов между туннельной и локальной сетью.

Частые ошибки и нюансы

• Добавление PersistentKeepalive на стороне сервера, а не клиента за NAT.
• Указание слишком большого интервала keepalive (например, 120 секунд), который превышает таймауты оборудования.
• Перекрытие AllowedIPs с пулом IP-адресов локальной сети клиента.
• Блокировка фрагментированных UDP-пакетов на фаерволе.
• Использование одинаковых private key на нескольких устройствах.

FAQ

Обязательно ли включать PersistentKeepalive, если у клиента белый IP?

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

Почему handshake есть, а пинг не проходит?

Такая ситуация указывает на проблему маршрутизации или фильтрации возвратного трафика. Проверьте AllowedIPs, маршруты на обоих концах и правила SNAT/MASQUERADE на сервере.

Может ли мобильный интернет влиять на разрывы?

Да, некоторые мобильные операторы сбрасывают UDP-потоки через 20–30 секунд неактивности. Установите PersistentKeepalive = 15 и убедитесь, что порт для WireGuard не блокируется на уровне оператора.

В конфигурации клиента PersistentKeepalive указан, но сессия все равно рвется. Что делать?

Проверьте таймауты на промежуточном роутере или брандмауэре. Возможно, UDP-сессия удаляется быстрее, чем отправляется keepalive. Уменьшите интервал до 10 секунд. Также проверьте, не блокирует ли исходящий фаервол сами keepalive-пакеты.

Можно ли решить проблему полностью на стороне сервера?

Сервер не может инициировать соединение к клиенту за NAT без ответного трафика. Поэтому ключевая роль — у клиента. На сервере можно только продлить таймауты состояний и настроить корректные маршруты.

Итог

Обрывы туннеля WireGuard через несколько минут после запуска почти всегда вызваны отсутствием постоянного keepalive или неправильной обработкой UDP-сессий промежуточным оборудованием. Добавление PersistentKeepalive на клиенте и проверка брандмауэров решают проблему в подавляющем большинстве случаев. Если же нестабильность сохраняется, следует детально изучить маршрутизацию и логи, чтобы исключить конфликты на сетевом уровне.

Также может быть интересно

Когда стоит переустановить WireGuard, а когда проблема не в клиентеОткрыть инструкциюПочему WireGuard расходует больше батареи на смартфоне: причины и способы уменьшить разрядОткрыть инструкциюЧто делать, если WireGuard подключён, но IP-адрес не меняетсяОткрыть инструкцию