Коротко: нестабильность WireGuard LTE: нестабильность чаще всего вызвана малым MTU, Carrier-Grade NAT, блокировкой UDP-трафика оператором или отсутствием постоянного keepalive. Проверьте MTU (рекомендуемые значения 1280–1300), включите PersistentKeepalive = 25 и по возможности используйте сервер с публичным IP. Эти шаги решают большинство проблем без замены VPN-решения.
Нестабильность WireGuard LTE — распространённая проблема: через домашний Wi-Fi туннель держится часами, а при переключении на мобильную сеть 4G или 5G начинаются обрывы, высокий пинг и постоянные переподключения. В этой статье разберём, почему сотовые сети создают столько трудностей для протокола, и покажем, какие параметры нужно проверить, чтобы WireGuard работал стабильно в любых условиях.
Почему Wi-Fi и мобильный интернет ведут себя по-разному
Домашний Wi-Fi обычно подключён к провайдеру с публичным или «белым» IP-адресом, а маршрутизатор легко настраивается на проброс портов. МТU на кабельном или оптоволоконном соединении редко падает ниже 1500 байт, и потеря пакетов минимальна. В сотовых сетях ситуация иная: оператор массово использует NAT, часто Carrier-Grade, выдаёт адреса из приватных диапазонов и не позволяет входящие соединения. Кроме того, радиоканал подвержен помехам, а базовые станции могут агрессивно управлять очередями, что увеличивает джиттер и потери.
С точки зрения WireGuard эти различия критичны: протокол работает поверх UDP, не имеет встроенного механизма восстановления потерянных пакетов и полагается на стабильный двусторонний обмен. Когда одна из сторон «прячется» за многоуровневым NAT или канал начинает резать крупные пакеты, handshake не проходит, а установленный туннель разрушается.
Особенности WireGuard, критичные для сотовых сетей
WireGuard принципиально работает только через UDP. Он не умеет переключаться на TCP и не эмулирует надёжную доставку — потеря handshake-пакета или keepalive сразу обрывает сессию. В мобильной сети UDP может намеренно шейпиться или блокироваться на уровне файрвола оператора либо на промежуточных роутерах, особенно если используется нестандартный порт.
Протокол полагается на статическую конфигурацию endpoint'ов. Если мобильный клиент выходит в интернет через CGNAT, его внешний IP и порт могут меняться при каждой смене соты или после бездействия. Сервер должен получить новый адрес, чтобы возобновить отправку данных. Без постоянного keepalive интервал между сменами endpoint'а может оказаться слишком долгим, и соединение «залипает» на устаревшем адресе.
Проблема MTU и как её решить
Самая частая причина обрывов — неправильный Maximum Transmission Unit. В проводных сетях типичен MTU 1500, но LTE и 5G добавляют служебные заголовки (GTP-туннели, инкапсуляцию), уменьшая полезную нагрузку. Если пакет превышает допустимый размер, а флаг DF (Don't Fragment) установлен, маршрутизатор просто отбрасывает его. WireGuard по умолчанию выставляет интерфейсу MTU 1420, однако реальный «прозрачный» MTU на мобильном подключении часто не превышает 1300–1350 байт.
Решение — уменьшить MTU на интерфейсе wg-клиента (и сервера) до безопасного значения. Экспериментально оно подбирается командой ping с указанием размера и флагом запрета фрагментации. На практике стабильно работают значения 1280–1300; в особо жёстких условиях допустимо опустить до 1200. После изменения MTU перезагружать интерфейс не нужно, но иногда помогает перезапуск wg-quick.
- На Linux: ping -M do -s
- На Windows: ping -f -l
- Начинайте с 1300 и уменьшайте шагами по 20, пока не исчезнут потери.
Важно: Не забывайте синхронизировать MTU на обоих концах туннеля; расхождение может вызывать странные прерывания даже при небольшой разнице.
Carrier-Grade NAT и его влияние на пиринги
Большинство мобильных операторов выдают клиенту адрес из диапазона 100.64.0.0/10 (RFC 6598). Это значит, что ваш телефон или модем находится за двумя и более уровнями NAT. Сервер WireGuard с публичным IP может принять первый пакет от клиента и запомнить сочетание адрес:порт, однако через минуты бездействия состояние на NAT-шлюзе оператора может очиститься, и сервер будет слать пакеты на уже неактивный порт.
Проблема решается PersistentKeepalive. Периодическая отправка пустого keepalive-пакета (рекомендуемый интервал 25 секунд) заставляет операторский NAT удерживать запись о сессии. Это также помогает клиенту быстро обновить endpoint после смены соты. Если сервер тоже находится за NAT, ситуация усложняется — тогда потребуется перенаправление портов (port forwarding) или координация через внешний STUN-сервер, что выходит за рамки стандартного WireGuard.
- Keepalive = 25 сек обычно достаточно и не создаёт заметной нагрузки
- Оба пира за NAT без проброса портов работать не будут
Ограничения операторов и блокировка протоколов
Некоторые операторы активно управляют трафиком: блокируют нестандартные порты, режут UDP в часы пик или полностью запрещают протоколы VPN. Особенно это заметно в публичных APN и на тарифах с ограничениями. Прямых доказательств блокировки может не быть в логах — пакеты просто не доходят.
Для диагностики стоит сменить порт WireGuard на 443 (HTTPS) или 53 (DNS), так как они чаще остаются открытыми. Иногда помогает переход на IPv6, если оператор предоставляет глобальный IPv6-адрес, а IPv4 выдаёт только через CGNAT. Однако если провайдер использует DPI и блокирует сам протокол WireGuard по сигнатурам, поможет только обходной канал (например, обёртка в TCP или использование Shadowsocks перед туннелем).
Важно: Смена порта не гарантирует обход DPI, но устраняет простейшие ограничения по номеру порта.
Диагностика: как понять, что именно мешает
Перед правкой конфигурации важно локализовать источник нестабильности. Первый шаг — проверка базовой достижимости: можно ли достучаться до сервера по ICMP и UDP. Запустите tcpdump на сервере и посмотрите, приходят ли handshake-пакеты от клиента. Если на сервере пакеты не появляются — проблема на стороне оператора или маршрутизации.
Если handshake периодически виден, но трафик не идёт, виноват MTU. Проверьте потерю пакетов увеличенного размера ping-тестом с DF. Также обратите внимание на время между обрывами: если туннель падает ровно через 30–60 секунд неактивности — скорее всего сбрасывается NAT-сессия, и нужен keepalive.
Настройки WireGuard для стабильной работы в LTE и 5G
Собрав информацию, можно настроить клиентский конфигурационный файл. Основные параметры: уменьшенный MTU (добавьте строку MTU = 1300 в раздел [Interface]), PersistentKeepalive = 25 в разделе [Peer], и, возможно, смена порта на сервере на 443. Если оператор выдаёт публичный IPv6, добавьте endpoint с IPv6-адресом сервера и укажите AllowedIPs, включающий IPv6-маршруты.
Пример конфигурации для клиента (с заменой ключей и адресов на реальные): [Interface] PrivateKey = … Address = 10.7.0.2/24 MTU = 1300 [Peer] PublicKey = … Endpoint = server.example.com:443 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 25. На серверной стороне также желательно выставить MTU = 1300 на интерфейсе WireGuard, чтобы обе стороны не фрагментировали по-разному.
Важно: После изменения конфигурации обязательно проверьте handshake командой wg show; статус должен показывать успешный обмен ключами и актуальный endpoint.
Проверка результата
- Проверьте текущий MTU туннеля: ip link show или в свойствах адаптера WireGuard в Windows
- Выполните ping -M do -s 1300 с клиента через мобильную сеть; если есть потери, уменьшайте размер
- На сервере выполните tcpdump -i udp port и проверьте, приходят ли handshake-пакеты от клиента
- Посмотрите вывод wg show: есть ли latest handshake и соответствует ли endpoint публичному адресу клиента
- Временно переключите порт сервера на 443 и повторите тест — если соединение становится стабильным, проблема в блокировке порта
Частые ошибки и нюансы
- Оставлять MTU по умолчанию 1420 в мобильной сети, не проверив реальную пропускную способность по большим пакетам
- Указывать endpoint вида 10.0.0.1 или 192.168.1.1, который никогда не будет доступен извне
- Забывать про PersistentKeepalive при использовании CGNAT на клиентской стороне
- Использовать слишком частый keepalive (менее 5 сек) — это не решает проблем глубже и создаёт лишний трафик
- Игнорировать возможность IPv6, если оператор выдаёт публичный IPv6, а IPv4 жёстко NAT'ирован
Проверить проблему WireGuard
Введите ошибку, симптом или часть конфигурации: handshake, AllowedIPs, DNS, MTU, Endpoint.
FAQ
Почему на Wi-Fi всё работает, а на LTE/5G WireGuard отваливается?
Сотовые сети используют более низкий MTU, массовый Carrier-Grade NAT и могут ограничивать UDP-трафик. Wi-Fi обычно подключён к проводному провайдеру с «белым» IP и стандартным MTU 1500, где таких проблем нет.
Какой MTU выставить для WireGuard через мобильную сеть?
Надёжнее всего начать с 1280. Подбирайте значение с помощью ping с флагом DF: уменьшайте пакет от 1300 до тех пор, пока не исчезнут потери. Практически всегда рабочими оказываются 1280 или 1300.
Обязательно ли включать PersistentKeepalive?
Да, если клиент находится за NAT (особенно CGNAT). Интервал 25 секунд поддерживает сессию в таблице NAT и позволяет быстро обновить endpoint при смене соты. Без keepalive туннель разрывается через несколько десятков секунд неактивности.
Может ли оператор блокировать WireGuard?
Да. Некоторые операторы блокируют нестандартные порты, ограничивают UDP или применяют DPI для распознавания и блокировки VPN-протоколов. Смена порта на 443 или 53 помогает в простых случаях, но против DPI понадобится дополнительная обёртка.
Поможет ли смена порта на 443 или 53?
Частично. Эти порты часто не фильтруются даже в мобильных сетях, так как нужны для HTTPS и DNS. Если проблема была только в блокировке порта — соединение станет стабильным. Но если оператор анализирует содержимое пакетов, смена порта не решит проблему.
Итог
Нестабильность WireGuard в мобильных сетях почти всегда связана с сочетанием низкого MTU, Carrier-grade NAT и политики оператора в отношении UDP. Настройка MTU вручную, включение PersistentKeepalive и грамотный выбор порта решают проблему в большинстве случаев без замены протокола. Если стабильности добиться не удаётся, стоит рассмотреть вариант форсирования IPv6 или использование промежуточного сервера с публичным IP, который способен принимать соединения и держать стабильный NAT-биндинг.