WireGuard: обрывается соединение — причины и решение

MAATRIX

Туннель работает, но время от времени связь пропадает: WireGuard обрывается соединение. То всё стабильно, то на минуту пропадает интернет, то соединение «засыпает» после паузы. В отличие от полного отказа, это плавающая проблема, и причина обычно в одной из трёх вещей: отсутствие keepalive за NAT, неверный MTU или нестабильный канал. Разберём, как поймать причину и сделать туннель стабильным.

Первое действие: понаблюдайте за handshake

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

watch -n 2 wg show

Обращайте внимание на поле latest handshake. В норме оно обновляется как минимум каждые пару минут при активности. Если handshake стареет до нескольких минут и связь в этот момент пропадает, а потом при новой активности восстанавливается — это классический признак проблемы с keepalive за NAT. Если же обрывы совпадают с ростом трафика или крупными пакетами — подозревайте MTU и фрагментацию. Если handshake скачет хаотично — нестабилен сам канал. Наблюдение за рукопожатием сразу подсказывает, в какую сторону копать, потому что его поведение прямо отражает, почему рвётся связь.

Причина 1: нет PersistentKeepalive за NAT

Самая частая причина периодических обрывов — клиент за NAT (домашний роутер, мобильная сеть), и при простое NAT-таблица на промежуточном оборудовании «забывает» о соединении. WireGuard по умолчанию молчит, когда нет трафика, и после паузы путь для входящих пакетов закрывается — связь пропадает до следующей активности с вашей стороны. Решение — периодически слать «пустой» пакет, чтобы держать NAT открытым. Добавьте в секцию [Peer] на стороне клиента:

PersistentKeepalive = 25

Значение в секундах: каждые 25 секунд WireGuard отправит keepalive-пакет, поддерживая соединение живым через NAT. Это стандартное и почти обязательное решение для клиентов за NAT, и оно снимает большинство жалоб на «засыпание» туннеля после паузы. 25 секунд — проверенное значение, укладывающееся в типичные тайм-ауты NAT. Если обрывы происходили именно после периодов бездействия, а при активном трафике связь держалась — PersistentKeepalive почти наверняка вас вылечит. Пропишите его на пиру, который находится за NAT (обычно это клиент, обращающийся к серверу).

Причина 2: неверный MTU и фрагментация

Вторая частая причина — проблема с MTU. WireGuard добавляет свои заголовки, и если MTU туннеля не согласован с сетью, крупные пакеты фрагментируются или теряются. Симптом характерный: мелкие действия (пинг, лёгкие страницы) работают, а тяжёлые (загрузка файлов, некоторые сайты, видео) виснут или рвутся. Особенно это проявляется на мобильных сетях и некоторых провайдерах. Задайте MTU интерфейса явно, немного снизив его. В секции [Interface]:

MTU = 1420

Стандартное значение для WireGuard — около 1420, но при проблемах его иногда снижают ещё (1400, 1380), особенно на каналах с меньшим MTU или PPPoE. Подбирайте опытным путём: если после снижения тяжёлый трафик пошёл стабильно — дело было в MTU. Проверить, проходят ли пакеты нужного размера без фрагментации, можно пингом с запретом фрагментации:

ping -M do -s 1372 -c2 10.0.0.1

Если пакеты такого размера не проходят, а меньшего — проходят, MTU надо снижать. Проблема MTU коварна тем, что выглядит как «случайные» обрывы на части трафика, и PersistentKeepalive тут не помогает — лечит именно правильный MTU.

Причина 3: нестабильный или меняющийся канал клиента

Иногда обрывы вызваны не настройками, а самим каналом: мобильный интернет с плохим сигналом, переключение между Wi-Fi и сотовой сетью, смена IP у клиента (роуминг). WireGuard хорошо переживает смену адреса клиента — он привязывается к ключам, а не к IP, — но при полной потере связи или частой смене сети возможны короткие разрывы. Проверьте, стабилен ли вообще базовый канал клиента без VPN, и не совпадают ли обрывы со сменой сети.

Если проблема в канале, помогает опять же PersistentKeepalive (быстрее восстанавливает путь после смены сети) и, на стороне сервера, отсутствие жёстких тайм-аутов. Со стороны сервера убедитесь, что он сам стабилен и доступен: смотрите его аптайм, нагрузку, не перезапускается ли сервис. Если сервер перегружен или периодически недоступен, обрывы будут у всех клиентов сразу — это уже вопрос ресурсов и стабильности сервера, а не конфига WireGuard. Различайте проблему на стороне одного нестабильного клиента и общую проблему сервера: в первом случае лечим keepalive и канал клиента, во втором — стабильность и ресурсы сервера.

Причина 4: сервер или сервис нестабилен

Если соединение рвётся у всех клиентов одновременно и регулярно, дело, скорее всего, в сервере: перезапуски сервиса WireGuard, нехватка ресурсов, проблемы сети дата-центра, срабатывание файрвола или fail2ban по ошибке. Проверьте, не рестартует ли сервис и стабилен ли сервер:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 --no-pager | tail -n 20

Если в логах видны перезапуски или ошибки — разбирайтесь с их причиной. Убедитесь, что порт WireGuard не блокируется периодически файрволом и что fail2ban или подобный инструмент не банит адреса клиентов по ошибке. Проверьте общую стабильность сервера: аптайм, нагрузку, свободную память. Нестабильный или перегруженный сервер даёт обрывы, которые никакими клиентскими настройками не лечатся. Здесь помогает надёжный VPS со стабильной сетью и достаточными ресурсами. Отличить эту причину просто: если рвётся у всех и совпадает с событиями на сервере — корень на сервере, а не в конфиге отдельного клиента.

Как убедиться, что связь стала стабильной

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

ping -c 100 10.0.0.1

Стабильный низкий процент потерь и отсутствие длинных провалов означают, что туннель держится. Дополнительно погоняйте тяжёлый трафик (загрузку файла) — если после настройки MTU он идёт без обрывов, проблема фрагментации решена. Понаблюдайте за wg show: handshake должен регулярно обновляться, а не стареть до минут во время простоя, — это подтверждает, что keepalive работает. Проверка и в покое, и под нагрузкой важна, потому что разные причины проявляются в разных условиях: keepalive — после пауз, MTU — на крупных пакетах. Пройдя оба сценария без обрывов, вы убеждаетесь, что стабильность достигнута.

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

Чтобы WireGuard держался стабильно, заложите правильные настройки сразу. Для любого клиента за NAT — а это почти все домашние и мобильные — прописывайте PersistentKeepalive = 25: это снимает главную причину «засыпающих» туннелей. Задавайте разумный MTU (около 1420, при проблемах ниже) и проверяйте прохождение крупных пакетов, особенно если клиенты на мобильных сетях. Держите на клиенте и сервере актуальные версии WireGuard.

Со стороны сервера обеспечьте стабильную основу: надёжный VPS со стабильной сетью, достаточными ресурсами и корректно настроенным файрволом, который не режет порт WireGuard и не банит клиентов по ошибке. Включите автозапуск туннеля, чтобы он восстанавливался после перезагрузки сервера. Мониторьте доступность сервера — если обрывы у всех сразу, причина обычно там. Сочетание правильного keepalive, согласованного MTU и стабильного сервера даёт туннель, который держится сутками без вмешательства, и «обрывается соединение» перестаёт быть темой для беспокойства.

Частые вопросы