Портал гостиницы и VPN в тупике: кто двигается первым
Порталу гостиницы нужен трафик до появления туннеля, а VPN блокирует всё, пока туннель не поднят. Сравните два порядка и то, что каждый из них открывает в этом промежутке.
Портал гостиницы хочет увидеть браузер, прежде чем пропустить любой трафик. Ваша VPN отказывается пропускать трафик, пока её туннель не поднят. Каждая сторона ждёт другую, и обе ведут себя ровно так, как настроены. Этот тупик разрывают только два порядка действий, и они различаются тем, что открывают, пока промежуток остаётся открытым. Выберите один осознанно, вместо того чтобы переключать любую настройку, после которой загружается браузер.
Два порядка, и один из них работает
Либо сеть сначала пускает вас, а туннель поднимается вторым, либо вы открываете узкое исключение для портала, а блокировку затем возвращаете. Оба варианта законны. Незаконно отключить блокировку и забыть вернуть её обратно.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
Эти два порядка не одинаково хороши в любой ситуации. У управляемого устройства с обязательной процедурой допуска один ответ, у личного ноутбука в гостиничном Wi-Fi другой. Сравнение касается того, чем каждый вариант приходится жертвовать.
Начните с того, чтобы понять, какой из них действительно поддерживают ваш клиент и политика устройства.
Вариант A: сначала допуск в сеть, затем подключение туннеля
Убедитесь в ожидаемом имени сети, затем используйте запрос входа операционной системы или поддерживаемый клиентом сценарий captive portal. На iPhone и iPad закрытие листа входа может либо разорвать связь с сетью, либо сохранить её с предупреждением об отсутствии интернета, и это разные точки старта. Сначала завершите шаг допуска, затем поднимайте туннель. Такой порядок сохраняет блокировку нетронутой всё время, пока туннель не поднят.
Загвоздка в том, что портал, разрешающий доступ в интернет, не аутентифицировал вашу учётную запись VPN. Туннель всё равно должен подключиться после этого, и он может отказать по своим причинам. Допуск и аутентификация — это разные события, которые люди сливают в одно.
Если допуск продолжает истекать, отметьте, снова ли портал запрашивает его, обрывается ли сеть или сбоит только VPN.
Вариант B: узкое исключение для входа, затем возврат блокировки
Альтернатива — разрешить трафик портала, пока блокировка в остальном действует, войти, а затем убрать исключение. Исключение должно быть узким: одно назначение или один диапазон адресов, на время входа, с немедленным возвратом блокировки после него. Широкое временное окно — это то, как двухминутный вход превращается в целый день незащищённого трафика.
Знайте, что на самом деле реализует ваш клиент. OpenVPN Connect на macOS документирует обнаружение captive portal отдельно от своей опции, блокирующей доступ в интернет, пока VPN приостановлен или переподключается. Обнаружить портал и разрешить его трафик — связанные задачи, а не взаимозаменяемые обещания.
На управляемом устройстве следуйте настроенной процедуре допуска, а не изобретайте исключение.
Что открывает промежуток и кому
Интересное в этом тупике — не вкладка браузера перед вами, а всё остальное, что начинает использовать сеть в момент появления подключения: почта, синхронизация фото, проверка обновлений, клиент чата, переподключающийся заново, агент резервного копирования, возобновляющий работу.
Тихое окно браузера ничего об этом не говорит. Закройте или приостановите чувствительную работу перед любым разрешённым интервалом прямого доступа и проверьте, что запускается при входе. На Android постоянная VPN в режиме always-on вместе с блокировкой подключений вне VPN это и есть нужный элемент управления, и произвольное исключение в маршруте не заменяет понимания этого.
Это единственное место, где старый совет о временных окнах доступа всё ещё верен. Беспокойство было правильным, даже если механизм — нет.
Как выбрать и как это подтвердить
Выбирайте вариант A, когда устройство или клиент поддерживает настоящий сценарий с порталом, потому что он сохраняет блокировку на всём протяжении. Выбирайте вариант B, когда до портала нельзя добраться иначе, и относитесь к исключению как к временному изменению с ответственным.
Затем подтвердите последовательность, а не результат:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Завершите допуск, установите нужный профиль, верните любой временно изменённый элемент блокировки, а затем сделайте новый безобидный запрос и убедитесь, что он идёт через туннель. Запрос, который удаётся потому, что блокировка всё ещё выключена, ничего не доказывает о туннеле.
Смена выходного узла VPN не продлит истёкшую гостиничную сессию. Это разные события, и путаница с ними отправляет вас искать не там.