Разделите входы на Wi-Fi-портал и входы в VPN
Две разные системы просят об одном: войти. Портал управляет локальным доступом, VPN — доступом к частной сети. Спрашивайте у каждого окна, кто действительно может проверить этот секрет.
Две разные системы просят вас войти, прежде чем вы доберётесь до чего-то полезного в публичной сети: Wi-Fi места и ваш VPN-шлюз. На экране они выглядят одинаково и разрешают совершенно разное. Портал решает, может ли это устройство использовать локальную сеть; VPN решает, можете ли вы достичь частной сети в другом месте. Я разделяю их, задавая в каждом окне один вопрос: кто на самом деле может проверить этот секрет? Ниже — контрольный список, который я применяю в отелях, аэропортах и на конференциях, включая места, где перестаю печатать.
Сопоставьте каждый вход службе, которая его проверяет
Одно гостиничное подключение может включать четыре отдельные проверки, и только некоторые из них хотят вашего ввода. Сначала упорядочите их, потому что экран редко сообщает, к какому этапу он относится.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
Сети 802.1X, распространённые в офисах и университетах, размывают первые две строки. Там вход в Wi-Fi сам по себе является проверкой личности на сервере RADIUS, и клиент может предъявить маршрутизирующую личность, пока настоящая учётная запись путешествует внутри зашифрованного обмена. Даже тогда проверка касается присоединения к сети; она не авторизует туннель, и VPN-шлюз не принимает её как доказательство чего-либо.
Порядок важнее ярлыков. Порталы перехвата существуют потому, что доступ можно предоставить после подключения, поэтому место может передать страницу специализированному провайдеру. RFC 8952 IETF рассматривает портал как отдельный компонент, поэтому незнакомый домен — повод проверить, а не само по себе доказательство мошенничества. Сравните домен с письменными инструкциями места, а поля — с таблицей.
Проверьте, что порталу разрешено запрашивать
Поля портала касаются права, а не личности: номер комнаты, фамилия брони, код ваучера, код, напечатанный на чехле ключа, почта для временного пропуска, принятие условий. Место уже знает, кто забронировал комнату, поэтому может сопоставить эти факты, не узнав ничего, что позволило бы ему действовать от вашего имени в другом месте.
Всё, что выходит за этот список, заслуживает паузы. Страница хотспота не может проверить ваш доменный пароль, и она тоже не может проверить ваш одноразовый код VPN, код восстановления или закрытый ключ, и у неё нет причин их хотеть. Единственное законное исключение — сеть под управлением организации: гостевой SSID офиса или Wi-Fi конференции могут передать вас поставщику идентичности, которого вы уже используете для работы. Это всё ещё различимо: хост входа — ваш повседневный, экран согласия называет вашего арендатора, а поток открывается в видимой вкладке браузера.
Маркетинговая почта — отдельно: дорожный псевдоним закрывает поле, не выдавая вашу рабочую личность.
Проверьте, что клиент VPN хочет собственные учётные данные
Клиент запрашивает ровно то, для чего настроен его профиль, поэтому ожидаемое окно — свойство профиля, а не сети, в которой вы случайно оказались. Профили с сертификатом обычно показывают выбор профиля и затем подключаются молча. Профили с именем пользователя и паролем запрашивают и то и другое, часто с одноразовым кодом. Профили SSO открывают браузер у поставщика идентичности и возвращаются с токеном. WireGuard снова другой: он аутентифицирует устройства открытым ключом и не имеет пользовательского входа, поэтому окно, предлагающее имя пользователя и пароль WireGuard, не описывает WireGuard.
Прочитайте профиль перед поездкой. В OpenVPN auth-user-pass сообщает, что ожидается запрос пароля, а cert, key или pkcs12 означает, что работу должен выполнить сертификат. Если профиль, который обычно подключается без запроса, вдруг просит пароль, заподозрите профиль, не сумевший загрузить сертификат или перешедший на другой метод. Запрос — не приглашение ввести рабочий пароль в любое появившееся окно.
Ни один законный клиент VPN не запрашивает номер комнаты, ваучер портала или парольную фразу Wi-Fi как ввод для аутентификации. Когда это случается, либо клиент не тот, за кого себя выдаёт, либо портал перехвата перехватывает трафик до образования туннеля, и вы читаете HTML-страницу, оформленную как вход.
Остановитесь на этих пяти условиях
Это точки, где я останавливаюсь вместо продолжения с правдоподобным обходным путём. Каждую дёшево проверить и дорого ошибиться.
- На портале или на странице SSO появляется предупреждение о сертификате или TLS. Не переходите через него щелчком, чтобы попасть в сеть.
- Страница запрашивает секрет, который может проверить только VPN-шлюз или поставщик идентичности: доменный пароль, одноразовый код, код восстановления, закрытый ключ.
- Домен не совпадает с печатными инструкциями места или с хостом входа, который ваша организация документирует для собственных служб.
- У вас просят установить корневой сертификат, профиль конфигурации или вспомогательное приложение, которое приходит не из управления вашими устройствами.
- Приходит подтверждение MFA, которое вы не начинали, или клиент VPN запрашивает гостиничные учётные данные.
Альтернатива — не другой пароль. Используйте хотспот телефона, спросите на стойке регистрации точное имя сети и способ доступа и сообщите о странице тому, кто управляет сетью, или в вашу ИТ-службу. Ничего из этого не требует проверять учётные данные на странице, которую вы не можете отнести к источнику.
Отнесите сбой к правильному этапу
После прохождения обоих этапов сбои всё равно случаются, и ошибка обычно называет этап, если читать по порядку: присоединение, выдача адреса, авторизация портала, установление туннеля, затем внутренний ресурс. Смена пароля VPN из-за истёкшего кода портала тратит время и оставляет настоящую проблему на месте.
Несколько проб разделяют этапы. После входа на портал запросите обычную публичную страницу HTTPS. Если вместо неё возвращается портал, авторизация на этом уровне так и не завершилась. Если клиент VPN сообщает, что не может достичь шлюза, проблема ниже туннеля: сессия портала, разрешение имён или сеть, блокирующая порт. Если туннель поднимается и одно внутреннее имя хоста не работает, разрешение имён или политика внутри частной сети — более вероятный подозреваемый.
Сессии портала также истекают независимо от туннеля. Когда место отзывает доступ, установленное соединение VPN падает, хотя его учётные данные никогда не были неверными. Авторизуйте портал заново, затем переподключите VPN и дайте ему заново договориться. Ротация пароля VPN тогда ничего не исправляет и может запереть вас снаружи.
Давайте каждый секрет только той системе, которая может его проверить, и считайте запрос, не соответствующий таблице, знаком остановки, а не шагом, который нужно обойти. Если оба этапа пройдены, а туннель всё ещё отказывает, зафиксируйте точную ошибку клиента, прежде чем менять любые учётные данные.