Отделете входовете през Wi-Fi портала от тези за VPN
Две различни системи искат от вас вход: Wi-Fi на мястото и вашият 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 на конференция може да ви предаде на доставчика на самоличност, който вече ползвате за работа. Тя пак е различима: хостът за вход е вашият ежедневен, екранът за съгласие посочва вашия tenant, а потокът се отваря във видим раздел на браузъра.
Маркетинговият имейл е отделно: туристически псевдоним удовлетворява полето, без да предава работната ви самоличност.
Проверете дали 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 паролата тогава не поправя нищо и може да ви заключи.
Давайте всяка тайна само на системата, която може да я провери, и третирайте подкана, която не пасва на таблицата, като знак за спиране, а не като стъпка за заобикаляне. Ако и двата етапа минат, а тунелът все още отказва, запишете точната грешка на клиента, преди да промените каквито и да е данни за вход.