Что такое captive portal

Captive portal — это веб-страница, которую сети Wi-Fi в отелях, аэропортах, кафе и на конференциях показывают, прежде чем пропустить тебя в открытый интернет. Подключаешься к SSID, открываешь браузер, и сеть редиректит тебя на форму логина, страницу принятия условий или платный шлюз. Пока не отправишь — сеть не форвардит твои пакеты.

Техника свободно описана в RFC 8908 и RFC 8910, которые стандартизуют, как сеть может анонсировать URL портала через DHCP option 114 или IPv6 Router Advertisements. Большинство legacy-порталов до этих RFC и опираются на перехват трафика.

Как работает перехват

Распространены два механизма.

HTTP-редирект. Шлюз маршрутизирует весь TCP-трафик на порт 80 на свой веб-сервер, независимо от destination IP. Браузер запрашивает http://example.com, шлюз отвечает 302 Found на URL портала. Работает только для plain HTTP. HTTPS-сайты так редиректить нельзя без триггера предупреждения о сертификате — поэтому ОС пробуют конкретные известные HTTP-эндпоинты (Apple — captive.apple.com, Microsoft — www.msftconnecttest.com, Android — connectivitycheck.gstatic.com), чтобы детектировать портал перед открытием вкладки.

Перехват DNS. Шлюз возвращает свой IP на каждый DNS-запрос, так что любое имя резолвится в портал. Более агрессивно, ломает DNSSEC и сваливает шифрованные DNS-клиенты (DoH/DoT) в режимы отказа. Сети, перехватывающие DNS, часто также блокируют UDP/53 к upstream-резолверам.

Когда ты аутентифицируешься, шлюз добавляет твой MAC-адрес (или фингерпринт устройства) в allow-list и перестаёт перехватывать.

Почему captive portal ломает VPN

VPN-туннелю нужно дойти до сервера. Если captive portal перехватывает весь трафик, туннель не установится: шлюз портала отвечает на VPN handshake вместо его форвардинга. Любой kill switch, настроенный блокировать не-VPN трафик, заблокирует и саму страницу портала, оставив пользователя застрявшим.

Проблема "курицы и яйца": нельзя подключить VPN, пока не пройдёшь портал, но kill switch может блокировать портал, пока не подключён VPN. Большинство VPN-клиентов решают это детекцией captive-portal probe и временным ослаблением kill switch в режиме "captive portal" до успешной аутентификации.

Соображения безопасности

Сама страница портала отдаётся оператором сети, часто по plain HTTP. Это даёт оператору (или любому близко к его инфраструктуре) возможность инжектить скрипты в страницу. То же предположение о доверии распространяется на DNS-резолвер оператора, обработку сертификатов в HTTPS, который использует портал, и на слой WPA2/WPA3 ниже.

Три практических риска:

• Pre-VPN экспозиция. Любой трафик, который устройство отправляет между подключением к SSID и завершением портала, виден оператору. macOS и iOS открывают браузер портала в sandbox-вью, не делящем cookies с Safari, что ограничивает blast radius. Старая Windows и большинство версий Android используют дефолтный браузер и полную сессию.
• Поддельные порталы. Rogue access point может имитировать SSID отеля и отдавать фейковый портал, собирающий номера карт или social-логины.
• Постоянная инжекция скриптов. Часть отельных сетей инжектит рекламу или трекинг даже после аутентификации. HTTPS-only browsing это побеждает.

Практические рекомендации

Подключайся к сети. Дай ОС детектировать портал и открыть его. Заверши портал в OS-провайдером браузерной вкладке, если она есть. Затем запусти VPN. Не логинься в почту, банк или что-то чувствительное между подключением к SSID и подключением VPN. Если VPN-клиент предлагает "captive portal detected", используй именно этот flow вместо ручного отключения kill switch.