Почему портал авторизации блокирует ваш VPN и как снова войти

В открытой сети точка доступа не просто передаёт пакеты в интернет. Точка политики выше проверяет, авторизовано ли устройство, и до этого почти всё отбрасывается. Ваш VPN-клиент читает эту тишину как мёртвый сервер. Он редко говорит это прямо: WireGuard повторяет рукопожатие в пустоту, OpenVPN сообщает об истечении времени соединения, а IKEv2 возвращается ошибкой 809 о удалённом сервере, который не отвечает.

Что портал действительно контролирует

Портал авторизации — это две склеенные вещи: точка принятия политики и перенаправляющий компонент. Когда устройство подключается и получает аренду DHCP, сеть ставит вас в состояние до авторизации.

Это состояние — набор правил брандмауэра. Обычно он пропускает DNS и разрешает HTTP или HTTPS к короткому списку хостов портала, а всё остальное отбрасывает. Разрешённый список — это огороженный сад, и VPN-эндпоинт в него почти никогда не входит.

Ни одно из этих отбрасываний не вежливо. Пакеты к VPN-серверу отбрасываются, а не отклоняются, поэтому клиент не получает ни ICMP unreachable, ни TCP reset, только отсутствие ответа. В зависимости от производителя перенаправляющий компонент может ответить на порт 80 перенаправлением на страницу входа, тогда как порт 443 отбрасывается или перехватывается. Перенаправления легко заметить, потому что они несут обычный ответ HTTP; перехват на 443 требует сертификата, которому ваш браузер откажется доверять.

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

Почему рукопожатие VPN умирает, не начавшись

У каждого протокола свой транспорт, и брандмауэр до авторизации ломает каждый по-своему. IKEv2 в Windows и iOS идёт по UDP 500 и UDP 4500; отбрасывание на этих портах проявляется как 809 или как сбой вроде разрешения имён у клиентов, которые сообщают о фазах отдельно. OpenVPN по UDP 1194 остаётся в состоянии подключения, пока не истечёт его время. OpenVPN по TCP 443 — интересный случай, потому что портал может завершить рукопожатие TCP и затем ответить своей страницей перенаправления, так что вы видите ошибку TLS вместо тайм-аута.

WireGuard показывает механизм яснее всего. Он по замыслу только UDP, без резерва TCP, поэтому брандмауэр, отбрасывающий неизвестный UDP, полностью убирает транспорт. Клиент продолжает отправлять инициации рукопожатия с растущей паузой и сообщает о рукопожатии, которое никогда не завершается. В этом сообщении нигде не упоминается Wi-Fi и ничто не намекает, что нужно открыть браузер.

Платформы пытаются заметить состояние раньше вашего VPN. Windows запрашивает известный URL, чтобы решить, показывать ли уведомление о входе, Android запрашивает эндпоинт, который должен ответить 204 No Content, а устройства Apple открывают небольшое окно сети с авторизацией. Эти пробы работают потому, что портал отвечает перенаправлением вместо ожидаемого тела. То же поведение объясняет, почему портал может выглядеть совершенно здоровым, пока туннель мёртв: проба и туннель оцениваются по разным правилам.

Что на самом деле сбрасывает истечение сеанса

Заведения завершают сеансы по причинам, не связанным с вашей учётной записью VPN: тайм-аут бездействия, максимальная длина сеанса, новая аренда DHCP или повторное подключение к другой точке доступа. Когда таймер срабатывает, запись в таблице сеансов исчезает, и набор правил до авторизации возвращается точно таким, каким был при регистрации.

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

В этот момент ошибка клиента говорит, на каком этапе вы находитесь, если прочитать её внимательно:

Одна деталь вводит людей в заблуждение: когда сеанс привязан к MAC-адресу, перезагрузка страницы входа может не помочь. Нужно разорвать связь и подключиться заново, чтобы портал увидел новую попытку авторизации вместо истёкшей.

Сначала войдите, потом поднимайте туннель

Работающий порядок такой: авторизуйте устройство, докажите путь, запустите VPN, докажите туннель, а затем восстановите свою обычную блокировку. Последний шаг важен, потому что временное состояние, нужное для доступа к порталу, — это ровно то состояние, которое предохранительный выключатель существует, чтобы не допустить.

Клиент для настольного компьютера с опцией блокировки вне туннеля нужно приостановить, чтобы страница портала загрузилась, а чувствительные приложения стоит держать закрытыми в этом окне вне туннеля; это единственный интервал, когда локальный трафик выходит без защиты. Управляемое постоянно включённое устройство должно использовать процедуру, опубликованную владельцем, а не то, что вы снимаете политику. Если портал показывает предупреждение о сертификате, остановитесь: его принятие направит сеанс через перехватывающий прокси заведения, а этот прокси сможет прочитать всё, что вы отправляете. На Android блокировка под постоянно включённым VPN останавливает трафик до того, как туннель поднимется, и некоторые сборки не умеют исключать поток портала; если ваша не умеет, используйте альтернативный доступ заведения или другое устройство, а не оставляйте блокировку выключенной. Правила on-demand от Apple можно написать так, чтобы туннель отклонялся до успешной пробы, и это то поведение, которое нужно в гостиничных сетях.

Проверьте по порядку теми инструментами, что уже есть. До туннеля запустите пробу так, чтобы были видны и заголовки, и тело, и посмотрите, получает ли транспорт VPN хоть какой-то ответ:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

До авторизации обычный портал даёт один из двух ответов: 302, чей Location указывает на страницу входа, или 200 с телом HTML, которое является страницей портала. Запишите, какой получили. Перенаправление до входа — не сбой; портал говорит, куда идти. После того как портал сообщит об успехе, повторите команду и ожидайте 200, тело которого — буквально слово Success. Именно эта строка делает пробу осмысленной. Если хост отвечает обычно ещё до того, как вы когда-либо вошли, в этой сети нет перехватывающего портала. В записи отбрасывание до авторизации — это исходящие пакеты, из которых ничего не возвращается, тогда как работающий путь показывает ответ на тот же поток примерно за секунду. Подключитесь и затем повторите запись.

Если туннель всё равно не работает после того, как портал сказал да

Успешный вход — это не то же самое, что разрешённый транспорт. Многие заведения разрешают портал и обычный просмотр, но полностью блокируют UDP, из-за чего WireGuard и OpenVPN по UDP ломаются, а TCP 443 работает. Если TCP 443 проходит, а UDP нет, это политика заведения, а не неправильно настроенный клиент, поэтому смените транспорт или примите ограничение и двигайтесь дальше. Если переподключение всё равно не удаётся, сохраните точную ошибку; она называет этап, на котором вы застряли.

Другие сбои живут на устройстве. Сеанс, всё ещё привязанный к старому MAC, второй адаптер Wi-Fi со своей арендой или клиент, сохранивший исключение сертификата портала, могут продолжать сбоить и после чистой повторной авторизации. Разорвите связь, авторизуйтесь заново и попробуйте один раз, прежде чем трогать настройки клиента. RFC 8952 стоит прочитать, если нужна архитектура за наблюдаемыми компонентами.

Если сам портал отказывает в авторизации, проблема в учётной записи или в распределении устройств, и никакая настройка VPN этого не исправит. Смена страны выхода VPN не сбрасывает локальное состояние доступа заведения; эта таблица привязана к вашему устройству, а не к выбранному серверу. Спросите оператора заведения и дайте ему время, потому что он будет смотреть на таблицу сеансов.

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