Типичная картина выглядит странно. Телефон подключён к домашнему Wi-Fi, VPN запускается за секунду и спокойно передаёт трафик. Выключаю Wi-Fi, появляется LTE или 5G, тот же клиент с тем же сервером либо бесконечно подключается, либо показывает активный туннель, но сайты перестают открываться.
Причина обычно не в самом VPN. Для VPN домашний Wi-Fi и мобильная сеть представляют собой два разных транспорта. Меняются IP-адреса, IPv4 и IPv6, NAT, DNS, MTU, правила фильтрации пакетов и поведение UDP. Поэтому рабочий VPN через Wi-Fi доказывает только одно, клиент и сервер в принципе способны установить соединение. Мобильный маршрут приходится проверять отдельно.
Ниже я разбираю диагностику VPN для защиты соединения, корпоративного доступа и других законных сценариев. Настройки сети не стоит использовать для доступа к запрещённым ресурсам или сокрытия противоправной активности. При изменении APN лучше использовать параметры мобильного оператора, а не случайные настройки из интернета.
Что реально меняется после перехода с Wi-Fi на LTE или 5G
VPN строит зашифрованный туннель поверх уже существующего интернет-соединения. На Android механизм VpnService создаёт виртуальный сетевой интерфейс, но пакеты до VPN-сервера всё равно приходится передавать через физическую сеть. Сегодня такой сетью может быть Wi-Fi, через минуту LTE или 5G.
| Параметр | Домашний Wi-Fi | LTE или 5G |
|---|---|---|
| IP | Часто IPv4 или dual stack | Нередко IPv6 или IPv4/IPv6 |
| NAT | Обычно домашний роутер | Часто операторский CGNAT или NAT64 |
| DNS | Роутер или домашний провайдер | DNS мобильного оператора или системный Private DNS |
| MTU | Часто предсказуемый | Маршрут может требовать меньших пакетов |
| UDP | Обычно стабильная NAT-сессия | Возможны другие тайм-ауты и правила фильтрации |
| Настройки | DHCP и параметры роутера | APN и конфигурация оператора |
| Смена сети | Редкая | Переходы между сотами и изменение маршрута |
IPv6 и NAT64 часто оказываются главным отличием
Домашняя сеть может выдавать телефону обычный IPv4, а мобильный оператор использовать IPv6 как основной транспорт. Для совместимости с IPv4 существуют NAT64 и 464XLAT. Такая архитектура давно применяется именно в мобильных сетях и подробно описана в RFC 8683.
Современные приложения обычно переживают такую схему без проблем. Старый VPN-клиент, самописное приложение или неудачная серверная конфигурация могут предполагать, что под туннелем обязательно находится IPv4. Через домашний роутер предположение случайно работает, а через IPv6-сеть оператора соединение ломается.
Отдельная ловушка возникает, когда VPN-сервер доступен по имени, а клиент или DNS неправильно обрабатывает сочетание IPv6, DNS64 и IPv4. В результате сервер прекрасно доступен из домашней сети, но мобильный клиент даже не начинает нормальное рукопожатие.
CGNAT подозревают слишком часто
CGNAT действительно широко используют провайдеры, поскольку один публичный IPv4 можно разделить между множеством абонентов. Но обычному исходящему VPN CGNAT сам по себе обычно не мешает. Клиент первым открывает соединение к серверу, NAT создаёт соответствующее состояние и пропускает обратные пакеты.
Проблемы появляются в более узких случаях. Оператор может быстрее удалять неактивные UDP-состояния, менять внешний адрес или иначе обрабатывать длительные UDP-сессии. Тогда VPN подключается, работает некоторое время, а потом замирает. Для одноранговых схем, где телефон должен принимать входящие подключения, CGNAT создаёт намного больше ограничений.
UDP может проходить по-разному
Многие современные туннели предпочитают UDP. IKEv2/IPsec тоже использует UDP, включая NAT Traversal. Домашний роутер и мобильная сеть могут обращаться с таким трафиком совершенно по-разному.
Поэтому ситуация «обычные сайты через LTE работают, а VPN нет» не доказывает, что мобильная сеть полностью исправна. HTTPS-сайт обычно открывается через TCP или QUIC на стандартных портах, а VPN может обращаться к совсем другому адресу и порту.
Если VPN-клиент поддерживает несколько штатных транспортных режимов, я временно переключаю UDP на TCP и повторяю тест. Если соединение внезапно оживает, круг подозреваемых резко сужается до UDP, NAT, маршрута и сетевой фильтрации. Оставлять TCP только ради самого факта подключения необязательно. Для некоторых VPN TCP поверх TCP заметно ухудшает работу при потерях пакетов.
MTU ломает соединение особенно неочевидно
VPN добавляет к исходному пакету собственные заголовки. Полезного пространства становится меньше. Если размер пакета превышает возможности какого-либо участка маршрута, пакет приходится фрагментировать либо отбрасывать.
Проблемы с MTU и MSS выглядят почти мистически. VPN подключился, мессенджер отправляет текст, но тяжёлый сайт зависает. Поиск работает, а загрузка файла останавливается. Один сервер открывается, другой бесконечно ждёт ответа.
Для проверки я временно уменьшаю MTU туннеля. Если клиент позволяет задать значение вручную, разумный диагностический тест начинается с 1280. Если связь становится стабильной, MTU можно постепенно увеличить и найти максимальное рабочее значение. Слепо прописывать 1280 навсегда не стоит, слишком маленький MTU увеличивает накладные расходы.
Как я ищу причину за десять минут
Начинать с переустановки приложения бессмысленно. Намного быстрее пройти цепочку от мобильной сети к серверу.
- Выключаю VPN и Wi-Fi. Проверяю, открываются ли сайты через LTE или 5G без туннеля. Если мобильный интернет уже нестабилен, VPN здесь вторичен.
- Включаю VPN и смотрю на симптом. «Не подключается вообще» и «подключился, но интернет пропал» указывают на разные проблемы.
- Пробую другой сервер того же VPN. Если другой узел работает через мобильную сеть, телефон и мобильный интернет почти наверняка исправны, искать нужно маршрут до конкретного сервера.
- Переключаю штатный транспорт. Если клиент предлагает UDP и TCP, временно сравниваю оба режима.
- Проверяю IPv6 и APN. Особенно если сбой возникает только через SIM-карту.
- Возвращаю Private DNS в автоматический режим. Конфликт DNS иногда выглядит как полный отказ VPN.
- Проверяю MTU. Такой тест особенно полезен, если VPN формально подключён, но часть сайтов не работает.
- Отключаю второй сетевой фильтр. Локальный блокировщик рекламы, другой VPN, корпоративный агент или сетевой антивирус могут конкурировать за один и тот же виртуальный интерфейс.
По поведению соединения часто можно сразу определить направление поиска.
| Симптом | Что проверять первым |
|---|---|
| VPN вообще не подключается | Адрес сервера, IPv4/IPv6, UDP, порт, APN |
| VPN подключён, интернета нет | Маршруты, DNS, kill switch, IPv6 |
| Работают только некоторые сайты | MTU, IPv6, DNS |
| VPN работает несколько минут и зависает | UDP, NAT timeout, keepalive, смена мобильного адреса |
| Через LTE работает, в роуминге нет | APN roaming protocol и политика оператора |
| После Wi-Fi VPN не переходит на LTE | Обработка смены underlying network самим клиентом |
Что проверить на Android
На Android мобильное подключение определяется настройками APN. Система поддерживает варианты IP, IPV6 и IPV4V6, что видно даже в официальном описании ApnSetting.
Названия меню зависят от производителя, но путь обычно выглядит примерно так: «Настройки» → «Сеть и интернет» → «SIM-карта» → «Точки доступа APN». Менять адрес APN наугад я не советую. Сначала сравниваю поля «Протокол APN» и «Протокол APN в роуминге» с параметрами оператора. При сомнениях безопаснее сбросить точки доступа к значениям по умолчанию.
Следом проверяю «Частный DNS». На время диагностики ставлю режим «Автоматически». Жёстко заданный DNS-over-TLS может конфликтовать с конкретной мобильной сетью или VPN. Подробно причины таких конфликтов я уже разбирал в материале про утечки DNS.
Есть ещё одна неприятная комбинация. Android настроен на постоянный VPN и одновременно включает «Блокировать подключения без VPN». Если туннель через LTE не установился, система честно блокирует весь остальной интернет. Пользователь видит мёртвую мобильную сеть и решает, что оператор отключил передачу данных, хотя блокировку включил сам телефон.
Для технической диагностики через ADB можно посмотреть, какие сети Android считает активными:
adb shell dumpsys connectivity | grep -A 20 -E 'TRANSPORT_CELLULAR|TRANSPORT_VPN'Названия интерфейсов в прошивках различаются, поэтому полезно посмотреть всю сетевую конфигурацию:
adb shell ip addr
adb shell ip routeЕсли мобильный интерфейс получает только IPv6, а Wi-Fi выдаёт IPv4, я бы сразу проверял поддержку IPv6 на внешней стороне VPN-клиента и сервера.
Если VPN-сервер ваш, диагноз ставится намного быстрее
На собственном сервере можно увидеть, доходят ли пакеты от телефона вообще. Во время попытки подключения через LTE или 5G запускаю:
sudo tcpdump -ni any udp port <PORT>Для VPN поверх TCP:
sudo tcpdump -ni any tcp port <PORT>Если пакеты через Wi-Fi появляются, а через мобильный интернет сервер не видит ничего, проблема находится до VPN-приложения на сервере. Под подозрением мобильный маршрут, адрес сервера, IP-версия, DNS, порт или фильтрация.
Если пакеты доходят в обоих случаях, но сервер отвечает только домашнему клиенту, смотрю журналы VPN и обратный маршрут. Для UDP также проверяю, действительно ли процесс слушает нужный сокет:
sudo ss -lunpТакой тест намного полезнее бесконечной смены настроек телефона. Появление первого пакета на сервере сразу отсекает половину возможных причин.
Почему совет «оператор блокирует VPN» слишком удобный
Оператор действительно может применять правила, из-за которых определённый транспорт, адрес или порт работает иначе. Но я не начинаю диагностику с вывода о блокировке. Точно такой же симптом дают сломанный IPv6, неправильный APN, DNS, MTU, зависшее UDP-состояние или старый VPN-клиент.
Популярный миф про CGNAT тоже мешает диагностике. CGNAT не означает автоматический запрет VPN. Ещё один миф звучит как «5G быстрее Wi-Fi, значит VPN должен работать лучше». Радиоскорость никак не гарантирует одинаковые маршруты и сетевые политики.
Наконец, смена DNS не является универсальным ремонтом VPN. DNS влияет на преобразование имени сервера в IP и на разрешение доменов внутри туннеля. Если мобильная сеть отбрасывает UDP-пакеты или ломается Path MTU Discovery, другой DNS проблему не исправит.
Я бы проверял причины именно в таком порядке: сначала обычный мобильный интернет, затем другой сервер и транспорт, потом IPv4/IPv6 и APN, после них DNS и MTU. Такой порядок почти всегда быстрее случайной перестановки галочек. Если VPN работает по Wi-Fi, но не по LTE или 5G, главное помнить простую вещь: сервер остался прежним, а вся дорога до него поменялась.
FAQ
Может ли мобильный оператор мешать работе VPN?
Может, поскольку мобильная сеть управляет маршрутизацией и обработкой пакетов. Но одинаковый симптом дают IPv6, APN, DNS, MTU и проблемы UDP, поэтому по одному факту отказа VPN нельзя определить причину.
Почему VPN пишет «Подключено», а через LTE сайты не открываются?
Чаще всего я проверяю DNS, маршруты IPv6, MTU и функцию блокировки соединений вне VPN. Сам факт созданного туннеля ещё не гарантирует правильную передачу пользовательского трафика.
CGNAT блокирует VPN?
Обычно нет. Исходящий VPN нормально работает через CGNAT. Проблемы вероятнее возникают с входящими соединениями, короткими тайм-аутами UDP или специфической реализацией NAT.
Поможет ли переключение LTE на 5G или наоборот?
Иногда помогает как диагностический тест. LTE и 5G могут использовать разные сетевые маршруты и параметры оператора. Если VPN стабильно работает только в одном режиме, проблема вряд ли находится исключительно на VPN-сервере.
Какой MTU поставить для мобильного VPN?
Универсального значения нет. Для диагностики можно временно попробовать 1280, затем постепенно повышать MTU. Постоянное значение лучше подбирать под конкретный туннель и маршрут.
Почему VPN ломается при переходе с Wi-Fi на мобильную сеть?
Меняется базовый сетевой интерфейс и часто внешний IP. VPN-клиент должен заметить смену транспорта и восстановить соединение. Старый или плохо реализованный клиент может продолжать пытаться передавать пакеты через уже исчезнувший Wi-Fi-маршрут.
Почему проблема появляется только в роуминге?
В роуминге могут измениться маршрут до интернета, IP-версия, NAT и параметры APN. Android отдельно поддерживает «Протокол APN в роуминге», поэтому домашнее и роуминговое подключение не всегда получают одинаковую сетевую конфигурацию.
