Відокремте входи на 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 тоді нічого не виправляє і може замкнути вас ззовні.
Давайте кожен секрет лише тій системі, яка може його перевірити, і вважайте запит, що не відповідає таблиці, знаком зупинки, а не кроком, який треба обійти. Якщо обидва етапи пройдено, а тунель усе ще відмовляє, зафіксуйте точну помилку клієнта, перш ніж змінювати будь-які облікові дані.