WireGuard постоянно переподключается: где искать проблему

Коротко: переподключение WireGuard: в большинстве случаев проблема кроется в отсутствующем или некорректном параметре PersistentKeepalive, несовпадении ключей либо блокировке пакетов рукопожатия (handshake) межсетевым экраном. Убедитесь, что на обоих концах туннеля задано значение keepalive ≥ 25 секунд, публичные ключи совпадают, а порт сервера открыт в сети. Если разрыв происходит каждые 2–3 минуты, вероятно, NAT на пути удаляет состояние через минуту после последнего пакета.

Постоянное переподключение WireGuard — одна из частых проблем при настройке VPN-туннелей. Соединение может обрываться каждые 120–180 секунд, нарушая работу удалённых сервисов. Чтобы устранить сбой, нужно методично проверить конфигурацию клиента и сервера, параметры таймаутов и сетевые факторы.

Что понадобится

• Доступ к конфигурационным файлам клиента и сервера WireGuard
• Права на просмотр системных логов (journalctl, dmesg, логи платформы)
• Возможность временно изменять правила межсетевого экрана для диагностики

Симптомы постоянного переподключения

Типичная картина: туннель устанавливается, данные передаются несколько минут, затем соединение пропадает. Команда wg show показывает, что время последнего рукопожатия (latest handshake) превышает 2–3 минуты, а количество переданных байт замирает. В логах появляются записи о повторных инициализациях handshake, часто с сообщением «Handshake did not complete after 5 seconds».

Такое поведение может проявляться как на клиентах за NAT, так и на серверах, особенно если оба конца находятся за маршрутизаторами с преобразованием адресов. Иногда переподключения происходят только при отсутствии трафика, но в других случаях даже активные сессии рвутся.

• Цикличное исчезновение доступа к удалённой подсети
• В логах повторяются предупреждения о незавершённом рукопожатии
• Последнее рукопожатие старше 2 минут при работающем туннеле

Параметр PersistentKeepalive: почему без него не обойтись

UDP не поддерживает состояния, поэтому промежуточные NAT-устройства запоминают привязку портов только на время активного обмена. Как только наступает пауза (обычно 30–120 с), состояние удаляется, и сервер больше не может доставить пакеты клиенту. В результате клиент вынужден заново инициировать рукопожатие.

Параметр PersistentKeepalive заставляет сторону отправлять пустой пакет каждые N секунд, постоянно обновляя запись в таблице NAT. Задаётся в секции [Peer] на той стороне, которая расположена за NAT и должна быть доступна для входящих соединений.

• Рекомендуемое значение: 25 секунд (успевает обновить состояние до истечения большинства таймеров)
• Если сервер тоже за NAT — задайте keepalive на обеих сторонах
• Формат: PersistentKeepalive = 25 в конфигурационном файле интерфейса

1. Откройте файл /etc/wireguard/wg0.conf (или аналогичный)
2. Найдите секцию [Peer] сервера (на клиенте) и добавьте строку PersistentKeepalive = 25
3. Сохраните файл и перезапустите интерфейс: wg-quick down wg0 && wg-quick up wg0
4. Проверьте командой wg show, что keepalive появился в выводе

Важно: Не ставьте слишком маленькое значение (менее 10), чтобы не создавать излишнюю нагрузку на сеть.

Проверка совпадения ключей и допустимых адресов

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

Кроме того, параметр AllowedIPs на сервере определяет, какие адреса разрешены для клиента. Если IP клиента изменился или не попадает в этот диапазон, пакеты отбрасываются. На клиенте AllowedIPs обычно равен 0.0.0.0/0 для маршрутизации всего трафика через туннель, но можно указать конкретные подсети.

• Сверьте вывод wg show public key на клиенте с ключом в секции [Peer] на сервере
• Убедитесь, что в параметре AllowedIPs перечислены реальные адреса клиента/сервера (например, 10.0.0.2/32)
• Ключи чувствительны к регистру и не должны содержать лишних пробелов

1. На клиенте выполните wg show wg0 public-key (имя интерфейса может быть другим)
2. На сервере откройте конфигурационный файл и найдите запись PublicKey для этого клиента
3. Убедитесь, что значения совпадают побайтно; при необходимости скопируйте ключ заново
4. Проверьте AllowedIPs на обоих концах — IP-адреса не должны пересекаться с другими интерфейсами

Важно: Никогда не переносите приватные ключи между системами — публичный ключ генерируется автоматически из приватного командой wg genkey | tee privatekey | wg pubkey.

Диагностика блокировки пакетов рукопожатия

Даже правильные ключи не помогут, если брандмауэр или провайдер фильтрует UDP-порт. Необходимо убедиться, что инициирующие пакеты от клиента доходят до сервера, а ответный handshake возвращается клиенту. Используйте tcpdump, чтобы посмотреть входящий и исходящий трафик на порту WireGuard (обычно 51820).

На стороне сервера в цепочке INPUT должны быть разрешены входящие UDP-пакеты на порт 51820. Если сервер находится за NAT, проброс портов также должен быть настроен корректно. Иногда проблема вызвана симметричным NAT на стороне клиента — тогда помогает смена порта или перенос соединения на сторону с менее строгим NAT.

1. На сервере запустите tcpdump -i any udp port 51820
2. На клиенте перезапустите туннель и наблюдайте за выводом tcpdump
3. Если на сервере видны только входящие пакеты от клиента, но нет ответных — проверьте межсетевой экран сервера
4. Временно отключите iptables/nftables: iptables -P INPUT ACCEPT; iptables -P OUTPUT ACCEPT (или эквивалент)
5. Если после этого туннель заработал, настройте разрешающие правила для порта 51820

Важно: Не забывайте возвращать политики брандмауэра после диагностики.

Влияние NAT и тайм-аутов сессий

Даже при настроенном keepalive может наблюдаться периодический разрыв, если на промежуточном роутере тайм-аут UDP очень короткий (15–30 секунд). В таких случаях интервал keepalive должен быть ещё меньше, например 10–15 секунд. Однако слишком частые пакеты увеличивают нагрузку, поэтому сначала попробуйте увеличить keepalive, а если не поможет — уменьшите.

В корпоративных сетях и сетях мобильных операторов иногда применяется агрессивная очистка состояния NAT. Альтернативой может служить использование TCP-обёрток (например, через udp2raw или WireGuard поверх TCP), но это уже выходит за рамки стандартной настройки.

• Если после добавления keepalive = 25 проблема сохраняется, попробуйте 15 или 10
• Проверьте настройки NAT на вашем роутере — иногда можно увеличить тайм-ауты UDP
• Убедитесь, что на клиенте нет конкурирующих VPN и правил, сбрасывающих состояние

Важно: На мобильных клиентах (Android/iOS) параметр PersistentKeepalive может называться «постоянный keepalive» и настраивается в интерфейсе приложения.

Особенности диагностики на MikroTik RouterOS

На устройствах MikroTik конфигурация WireGuard управляется через раздел /interface wireguard. Для контроля состояния удобно использовать команду /interface wireguard peers print detail, где отображается current-endpoint-address, last-handshake и состояние рукопожатия. Если endpoint-address показывает 0.0.0.0, значит, удалённый пир не отвечает или адрес не определён.

Частая ошибка — неверно заданный параметр allowed-address в настройках пира. На маршрутизаторе он должен строго соответствовать адресу клиента (например, 10.0.0.2/32). Также проверьте, что в /ip firewall filter не блокируются входящие пакеты на UDP-порт, а в /ip firewall nat не выполняется srcnat для трафика в туннель, если он не нужен.

• Команда /interface wireguard peers print detail покажет время последнего рукопожатия

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

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