VPN зависает на Connecting в авиарежиме: найдите восходящий канал
У клиента, который в авиарежиме остаётся на Connecting, может просто не быть восходящего канала. Разделите состояние радио, ассоциацию, вход на портал и политику блокировки.
Телефон показывает значок самолёта, VPN-клиент стоит на Connecting уже две минуты, а профиль верный. Час назад всё работало в этом же здании. Ничего не сломано: VPN — это соединение, которое переносит другая сеть, а авиарежим только что убрал сеть, которая его переносила. Клиент продолжает повторять попытки, потому что без восходящего канала он делает именно это.
Сбивает с толку то, что значок самолёта не сообщает, доступен ли Wi-Fi, а Connecting не сообщает, клиент проходит аутентификацию или просто ждёт. Разделите эти два показания, и диагностика займёт минуту.
Значок самолёта — не отчёт о радио
На поддерживаемых устройствах Android Wi-Fi и Bluetooth могут оставаться включёнными в авиарежиме, и устройство помнит ваш прошлый выбор. Инструкция Google по авиарежиму на Pixel описывает именно такое поведение. Значит, значок может означать только то, что сотовые сети выключены, и ничего больше.
Проверяйте фактическое состояние, а не глиф. adb shell settings get global airplane_mode_on возвращает 0 или 1 для самого режима, а adb shell dumpsys connectivity перечисляет сети, которые устройство имеет сейчас, вместе с их статусом проверки. Эти два вывода вместе отвечают на вопрос, на который значок ответить не может.
Если Wi-Fi выключен или включён, но ни с чем не связан, пути к конечной точке VPN нет, и никакое количество переподключений его не создаст. Именно этот случай стоит исключить первым, потому что это единственный случай, когда правильное решение находится вне приложения VPN.
Что на самом деле означает Connecting
Клиент может держать сохранённый профиль, показывать его имя и крутить индикатор, ни к чему не обращаясь. Конфигурация локальна. Для построения туннеля нужны доступный сервер, завершённое рукопожатие и интерфейс для маршрутизации. Только последней части нужна работающая сеть, поэтому первые две могут выглядеть успешными при выключенном радио.
Поэтому индикатор соответствует как минимум трём разным ситуациям: восходящего канала нет вовсе, канал не достигает конечной точки, и канал достигает её, но аутентификация не проходит. На экране они выглядят одинаково, а в журнале — совершенно по-разному. Поэтому первый полезный артефакт во всех этих случаях — журнал, а не ещё одна попытка.
Собственная документация Android по VPN проводит ту же границу между установлением соединения и отдельными политиками «всегда включено» и блокировки. Именно это разделение объясняет, почему телефон может выглядеть защищённым в офлайне и при этом не иметь туннеля.
Четыре состояния, которые стоит различать
Четыре состояния ниже — это те, которые стоит назвать, потому что экран показывает их одинаково.
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
Третья строка ловит большинство людей в отелях и аэропортах. Ассоциация — ещё не допуск: портал, который не пропустил телефон, охотно примет пароль Wi-Fi и затем откажется пропускать трафик к конечной точке VPN. Сначала войти через браузер, пока туннель выключен, обычно единственный путь.
Почему блокировка делает картину хуже
Если постоянно включённый VPN и блокировка соединений без VPN активны одновременно, каждое охваченное приложение блокируется всякий раз, когда туннель не поднят. Это работающая функция, а не вторая неисправность. Симптом меняется с отказа одного приложения на отказ всего, что читается как гораздо более крупная проблема.
Это же объясняет последовательность, которую люди читают неправильно: авиарежим включён, восходящего канала нет, приложения заблокированы, VPN говорит connecting. Блокировка была политикой, которая делала свою работу. Отключение политики ради проверки канала убирает защиту, которую вы, скорее всего, хотели, и ничему не учит.
Вместо этого проверьте охват. Какие приложения охвачены, какие исключены и профиль на пользователя или на всё устройство. Задача, которая запускает приложение VPN, как только появляется Wi-Fi, — это триггер, а не гарантия, что до её запуска не ушёл ни один пакет.
Порядок диагностики, который прекращает догадки
Работайте снизу вверх. Подтвердите режим, подтвердите, что сеть существует, что она проверена, что она достигает чего-то за пределами локальной подсети, и только затем смотрите на клиента. adb shell ping -c 3 1.1.1.1 — грубая проверка, но она отделяет отсутствующий путь от пути, который существует, пока туннель недоволен.
Если ping не проходит, пока сеть в списке, проблема выше VPN, и никакая настройка клиента её не исправит. Если ping проходит, а туннель всё равно не устанавливается, снимите журнал клиента в этот момент: ошибка различит истечение времени ожидания и отказ аутентификации, а у этих двух нет ничего общего.
Завершите восстановлением нужного состояния: Wi-Fi разрешён в авиарежиме, если это ваша обычная настройка, портал пройден, политика блокировки снова включена. Затем один раз переподключитесь и убедитесь, что туннель поднимается сам, потому что конфигурация, работающая только после ручных попыток, снова откажет при следующей загрузке.