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

WireGuard — современный и быстрый VPN, но у него есть особенность: он не держит постоянное соединение. Туннель активируется только при передаче данных. Поэтому внезапные «отвалы» — частая жалоба. В этой статье разберём, почему WireGuard отключается сам по себе, и как это исправить. Диагностику начнём с самых распространённых причин.

1. Не настроен PersistentKeepalive — главный виновник

Из-за особенности WireGuard, если нет трафика, рукопожатие (handshake) происходит только через определённое время. Однако NAT на роутере или файрволе закрывает порт для неактивного соединения. Когда сервер попытается отправить пакет, он не сможет пробиться через NAT, и туннель «засыпает».

Решение — включить постоянный keepalive в конфигурации клиента (и, возможно, сервера). В файле конфигурации у пира нужно указать:

[Peer]
PersistentKeepalive = 25

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

Проверьте для своей версии: в некоторых ранних версиях WireGuard PersistentKeepalive поддерживался только в конфигурации клиента, на сервере его можно не задавать.

2. Проверьте интерфейс, рукопожатие и маршруты

Если keepalive уже настроен, но обрывы продолжаются, нужно убедиться, что интерфейс жив. Выполните на клиенте и сервере:

sudo wg show

Обратите внимание на поле latest handshake (последнее рукопожатие). Если оно постоянно увеличивается — туннель работает. Если рукопожатие «застыло», значит, соединение потеряно.

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

ip route show default

В выводе должен быть dev wg0. Если маршрут пропал, причина может быть в перезапуске сетевого менеджера или dhclient. В таких случаях помогут настройки AllowedIPs = 0.0.0.0/0 в конфигурации пира (клиента) и явное указание таблицы маршрутизации в wg-quick.

Иногда обрывает маршрут при смене сети (например, переключении с Wi-Fi на мобильный интернет). Это нормально, но правильная конфигурация должна автоматически пересоздавать маршруты.

3. Файрволы и DPI-фильтры

Следующая по частоте причина — блокировка на сетевом уровне. Антивирус, межсетевой экран или DPI (глубокий анализ пакетов) может прерывать UDP-соединение. WireGuard по умолчанию использует порт 51820/udp — этот порт легко вычислить и заблокировать.

Что делать:

• Попробуйте сменить порт на нестандартный, например, 443 или 53 (UDP). Однако учтите, что некоторые провайдеры блокируют и их для VPN-трафика.
• Проверьте, не блокирует ли ваш собственный файрвол. На сервере и клиенте убедитесь, что правило разрешает исходящий и входящий трафик на выбранном UDP-порту.
• Если используете антивирус с функцией VPN-детекта, добавьте свой трафик в исключения.

Обратите внимание: при смене порта нужно заново открыть его в файрволе и не забыть про NAT на роутере. Проверьте для своего региона — в некоторых странах стандартные VPN-порты блокируются на государственном уровне, но мы не можем давать рекомендации по обходу.

4. Энергосбережение и сон системы

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

Исправление:

• В Windows: «Диспетчер устройств» → сетевой адаптер → «Свойства» → «Управление питанием» → снимите галочку «Разрешить отключение этого устройства для экономии энергии».
• В Linux: проверьте настройки NetworkManager и команду power save для беспроводного адаптера. Отключите агрессивную экономию через iw dev wlan0 set power_save off.
• В Android и iOS: в настройках приложения WireGuard разрешите «Фоновую активность» и отключите оптимизацию батареи для этого приложения.

Также полезно настроить keepalive (см. п.1), чтобы система быстрее замечала разрыв и восстанавливала соединение.

5. Проверка логов и времени

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

journalctl -u wg-quick@wg0

ищите строки об ошибках handshake, перезапуске интерфейса или сбоях сокета. На клиенте смотрите системный журнал (например, dmesg или журнал приложения WireGuard).

Ещё одна возможная причина — рассинхронизация системного времени. WireGuard основан на криптографии, и если разница во времени между сервером и клиентом превышает примерно 3 минуты, рукопожатие отклоняется. Настройте синхронизацию времени через NTP на обоих устройствах.

6. MTU и фрагментация пакетов

Иногда туннель отключается только при работе с большими объёмами данных (например, при загрузке файлов). Это признак проблем с MTU. Стандартный MTU для Ethernet — 1500, но при добавлении WireGuard-заголовка пакет увеличивается. Если на пути встречается устройство с MTU меньше, происходит фрагментация, а некоторые провайдеры блокируют фрагментированные UDP-пакеты.

Решение — установить MTU ниже стандартного, например 1280 (гарантированный минимум для IPv6). В файле конфигурации интерфейса укажите:

[Interface]
MTU = 1280

Проверьте, стабильна ли работа после этого. Также можно проверить MTU командой ping -M do -s 1472 1.1.1.1, меняя размер пакета, чтобы найти максимальное значение.

Если ни одна из проверок не помогла, повторите диагностику сначала — возможно, вы пропустили тонкость. Запишите, когда именно отключается туннель (через 10 минут? при запуске приложения?), и используйте полученные данные для поиска в официальных рассылках WireGuard.

Важно: все команды и настройки даны для типовых конфигураций. Проверьте актуальный синтаксис для вашей версии WireGuard и операционной системы — они могут незначительно отличаться.