Новый клиент хотспота, зависший на получении IP, — не сбой VPN

Телефон подключается к хотспоту, остаётся на «Получение IP-адреса» и в конце концов сдаётся. Естественный вывод — что VPN телефона мешает DNS, и люди начинают править резолверы и добавленные правила. Это не тот этап. Клиент так и не получил локальный адрес, а без него у него нет ни шлюза, ни резолвера, ни того, что можно переслать дальше, поэтому никакая настройка VPN на телефоне-хосте не объясняет сбой. Подключение, назначение локального адреса и дальнейшая пересылка — три отдельных этапа, и только последний касается туннеля.

Три этапа и на каком вы находитесь

Сначала идёт подключение: клиент присоединяется к беспроводной сети хотспота. Неверный пароль, несоответствие WPA3 или проблема совместимости радио отказывают здесь, и клиент обычно так и пишет. Второй — назначение адреса: для IPv4 клиент запрашивает аренду и получает адрес плюс локальные настройки шлюза, тогда как IPv6 обычно использует объявления маршрутизатора вместо DHCP, как описывает документация AOSP по tethering. Третий — дальнейший доступ: телефон-хост пересылает разрешённый трафик на выбранный им вышестоящий путь, который может быть его туннелем, а может и не быть.

Формулировка на клиенте сообщает этап. Зависание на получении адреса — второй этап, до того как в интернет уйдёт хотя бы один пакет. Подключено, адрес есть, но ничего не грузится — третий этап, где важны и маршрутизация, и имена, и покрытие туннеля. Диагностировать третий этап, пока клиент застрял на втором, — это способ превратить пятиминутную проблему аренды в вечер правки DNS.

Миф: маршрутизируемый VPN превращает локальный DHCP в удалённый запрос

Маршрутизируемый туннель переносит IP-пакеты для тех назначений, которые он выбирает. Обнаружение DHCP — это широковещательный запрос в собственном сегменте хотспота, и служба tethering на телефоне отвечает на него локально, поэтому клиент может получить адрес, пока туннель поднят. Только намеренно мостовое или ретранслирующее решение отправляет этот обмен куда-то ещё, и это другая схема с другой сигнатурой сбоя.

Так что «сервер VPN не отвечает на DHCP» — не диагноз, а ошибка модели. Локальный посредник находится на телефоне. Если он перестаёт отвечать, причины локальны: служба tethering, лимит клиентов, пул аренды или клиент, который так и не завершил подключение как следует. Ничто из этого не живёт на дальней стороне туннеля.

Что на самом деле доказывает работающий существующий клиент

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

Пока вы там, стоит проверить два локальных ограничения. Хотспот обслуживает конечный пул аренды и настраиваемый лимит клиентов, поэтому устройство, которое подключилось и уснуло, может держать адрес, пока новое ждёт. А клиент, который помнит статическую конфигурацию из другой сети, вовсе не будет запрашивать аренду, что снаружи выглядит одинаково и исправляется на клиенте, а не на телефоне.

Держите сравнение локальным и обратимым

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

Устойчивый сбой аренды, зависящий от туннеля, — полезное свидетельство о локальной политике или о взаимодействии реализаций. Это не лицензия вычищать все правила пересылки и NAT на устройстве. Эти правила защищают посторонний трафик, и широкое разрешение пересылки не объясняет, почему локальная служба DHCP перестала отвечать.

Не замазывайте отсутствующую аренду придуманным статическим адресом. Намеренная статическая конфигурация требует настоящей подсети, шлюза, плана распределения и проверки конфликтов. Смена DNS на клиенте не даёт ничего из этого и оставляет следующее устройство с тем же сбоем.

Чего аренда не доказывает

Получение адреса доказывает допуск в локальную сеть, а не защиту туннелем телефона. Когда у клиента есть аренда, оцените нисходящий путь отдельно: действительно ли трафик клиента идёт через телефон, разрешаются ли запросы там, где вы ожидаете, и совпадает ли внешний адрес с задуманным выходом? Это вопросы третьего этапа, и они заслуживают отдельного теста, а не сворачивания в подключение.

Проходите этапы по порядку, и сбой перестаёт перемещаться. Клиент, зависший на получении адреса, — локальный вопрос tethering; клиент с адресом и без страниц — вопрос пересылки или имён; клиент со страницами и неверным выходом — вопрос покрытия туннеля. Разделять их — большая часть отладки.