WireGuard: интернет то работает, то нет — диагностика нестабильного туннеля

WireGuard часто работает стабильно, но в некоторых случаях пользователи замечают, что интернет «то работает, то нет». Это может проявляться как периодические обрывы, медленная загрузка или полное отсутствие связи при активном туннеле. Причины обычно кроются не в самом WireGuard, а в настройках сети, MTU, NAT или роутинге. В этой статье разберём пошаговый алгоритм диагностики, который поможет найти источник нестабильности.

Почему WireGuard может работать нестабильно

Основные причины нестабильного соединения:

• Неправильно подобранный MTU — частая проблема при подключении через PPPoE, особенно в России.
• Отсутствие PersistentKeepalive на клиенте — при NAT/Traversal соединение «засыпает».
• Конфликт подсетей — если внутренняя сеть WireGuard пересекается с локальной сетью.
• Проблемы с роутингом — когда трафик уходит не через туннель или наоборот.
• Нестабильный доступ к endpoint — особенно если endpoint находится на динамическом IP или за шатким хостингом.
• Устаревшая версия WireGuard или ограничения антивируса/файрволла.

Диагностику лучше начинать с самых вероятных причин — MTU и NAT, а затем переходить к более глубоким проверкам.

Пошаговая диагностика: от вероятного к редкому

Шаг 1. Проверка handshake и статистики

Запустите wg show на клиенте и сервере. Если в выводе есть latest handshake — значит, туннель поднят. Проверьте счётчики передач:

sudo wg show

Если handshake устарел (например, больше 2 минут), значит, пакеты не доходят. Проверьте связность с endpoint:

ping 10.0.0.1

Замените адрес на реальный endpoint. Если ping не отвечает, а сам сервер доступен из интернета, проблема в фаерволе или маршрутизации.

Шаг 2. Проверка MTU

Самая частая причина нестабильности — фрагментация пакетов. Уменьшите MTU на интерфейсе WireGuard. Для большинства PPPoE-подключений подходит 1280 байт. Проверьте:

ping -M do -s 1372 10.0.0.1

Если ping проходит, то MTU 1400 возможен. Если нет — установите 1280. В конфигурации клиента:

MTU = 1280

Шаг 3. Проверка NAT и Keepalive

Если клиент находится за NAT, добавьте PersistentKeepalive = 25 в секцию [Peer]. Это заставит клиент отправлять keepalive-пакеты каждые 25 секунд, предотвращая сброс трансляции адресов.

[Peer]
PersistentKeepalive = 25

Проверьте, что на сервере не включён iptables-роутинг без соответствующих правил для WireGuard.

Шаг 4. Проверка маршрутов и DNS

Убедитесь, что маршруты корректны. На клиенте выполните ip route и посмотрите, есть ли маршрут для нужной подсети через туннель. Также проверьте DNS: если используете DNS через туннель, убедитесь, что запросы уходят правильно. Проверка:

dig @1.1.1.1 example.com

Если DNS не отвечает, возможно, проблема на стороне сервера.

Шаг 5. Проверка логов и системных сообщений

Посмотрите журналы ядра или демона WireGuard:

sudo dmesg | grep wireguard
sudo journalctl -u wg-quick@wg0

Ошибки типа Packet has invalid nonce или No peer to send to укажут на проблемы с ключами или маршрутизацией.

Типовые сценарии нестабильности

Сценарий 1: Роутер с PPPoE

Если WireGuard поднят на роутере с PPPoE, MTU часто превышает допустимый. Установите MTU 1280 на интерфейсе WireGuard и настройте MSS clamping для TCP.

Сценарий 2: Android-клиент

На Android периодические обрывы могут быть связаны с энергосбережением. Разрешите приложению работать в фоне и включите PersistentKeepalive.

Сценарий 3: Динамический IP у сервера

Если endpoint сервера — динамический IP, на клиенте нужно использовать DNS-имя (DDNS) и обновлять его. WireGuard сам не отслеживает изменения IP; потребуется скрипт для перезапуска туннеля при изменении адреса.

Профилактика: как сделать туннель стабильнее

• Всегда указывайте MTU, особенно если используете PPPoE/VPN поверх.
• Включайте PersistentKeepalive на клиентах за NAT.
• Настройте мониторинг handshake и автоматический перезапуск через systemd или cron.
• Используйте последнюю версию WireGuard и проверяйте обновления для вашего дистрибутива (проверьте для своей версии).

Для автоматического перезапуска можно добавить в crontab задачу, которая проверяет wg show и перезапускает интерфейс при потере handshake.

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