Oddziel logowania do portalu Wi-Fi od logowań VPN
Dwa różne systemy proszą o to samo: logowanie. Portal kontroluje dostęp lokalny, VPN dostęp do sieci prywatnej. Pytaj przy każdym oknie, kto naprawdę może zweryfikować ten sekret.
Dwa różne systemy proszą o zalogowanie, zanim dotrzesz do czegokolwiek użytecznego w sieci publicznej: Wi-Fi miejsca i brama VPN. Na ekranie wyglądają tak samo, a autoryzują zupełnie różne rzeczy. Portal decyduje, czy to urządzenie może korzystać z sieci lokalnej; VPN decyduje, czy możesz dotrzeć do sieci prywatnej gdzie indziej. Rozdzielam je, zadając w każdym oknie jedno pytanie: kto naprawdę może zweryfikować ten sekret? Poniżej lista kontrolna, którą stosuję w hotelach, na lotniskach i w centrach konferencyjnych, łącznie z miejscami, w których przestaję pisać.
Przypisz każde logowanie do usługi, która je sprawdza
Jedno połączenie hotelowe może obejmować cztery osobne kontrole, a tylko niektóre proszą o Twoje dane. Najpierw ustaw je w kolejności, bo ekran rzadko mówi, do którego etapu należy.
| 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 |
Sieci 802.1X, częste w biurach i na uczelniach, rozmywają pierwsze dwa wiersze. Tam logowanie do Wi-Fi samo jest kontrolą tożsamości wobec serwera RADIUS, a klient może przedstawić tożsamość routingu, podczas gdy prawdziwe konto podróżuje wewnątrz zaszyfrowanej wymiany. Nawet wtedy kontrola dotyczy dołączenia do sieci; nie autoryzuje tunelu, a brama VPN nie przyjmuje jej jako dowodu czegokolwiek.
Kolejność jest ważniejsza niż etykiety. Portale przechwytujące istnieją, bo dostęp można przyznać po połączeniu, dlatego miejsce może przekazać stronę wyspecjalizowanemu dostawcy. RFC 8952 IETF traktuje portal jako własny komponent, więc nieznana domena jest powodem do sprawdzenia, a nie dowodem oszustwa samym w sobie. Porównaj domenę z pisemnymi instrukcjami miejsca, a pola z tabelą.
Sprawdź, o co portal może prosić
Pola portalu dotyczą uprawnienia, nie tożsamości: numer pokoju, nazwisko z rezerwacji, kod vouchera, kod wydrukowany na osłonce klucza, e-mail do tymczasowego przepustki, akceptacja warunków. Miejsce już wie, kto zarezerwował pokój, więc może dopasować te fakty, nie dowiadując się niczego, co pozwoliłoby mu działać jako Ty gdzie indziej.
Wszystko poza tą listą wymaga pauzy. Strona hotspotu nie może zweryfikować Twojego hasła domenowego, a także nie może zweryfikować Twojego jednorazowego kodu VPN, kodu odzyskiwania ani klucza prywatnego, i nie ma powodu ich chcieć. Jedynym uzasadnionym wyjątkiem jest sieć prowadzona przez organizację: gościnny SSID w biurze albo Wi-Fi konferencji mogą skierować Cię do dostawcy tożsamości, którego już używasz w pracy. Wciąż da się to odróżnić: host logowania jest Twój codzienny, ekran zgody wymienia Twojego tenanta, a przepływ otwiera się w widocznej karcie przeglądarki.
E-mail marketingowy jest osobno: alias podróżny spełnia pole, nie oddając Twojej tożsamości służbowej.
Sprawdź, czy klient VPN chce własnych danych logowania
Klient prosi dokładnie o to, do czego skonfigurowany jest jego profil, więc oczekiwane okno jest właściwością profilu, a nie sieci, w której akurat jesteś. Profile certyfikatów zwykle pokazują wybór profilu, a potem łączą się cicho. Profile z nazwą użytkownika i hasłem proszą o oba, często z kodem jednorazowym. Profile SSO otwierają przeglądarkę u dostawcy tożsamości i wracają z tokenem. WireGuard jest znów inny: uwierzytelnia urządzenia kluczem publicznym i nie ma logowania użytkownika, więc okno proponujące nazwę użytkownika i hasło WireGuard nie opisuje WireGuard.
Przeczytaj profil przed podróżą. W OpenVPN auth-user-pass mówi, że oczekiwane jest pytanie o hasło, a cert, key lub pkcs12 oznacza, że pracę powinien wykonać certyfikat. Jeśli profil, który zwykle łączy się bez pytania, nagle prosi o hasło, podejrzewaj profil, któremu nie udało się wczytać certyfikatu albo który przeszedł na inną metodę. Pytanie nie jest zaproszeniem do wpisania hasła służbowego w jakimkolwiek oknie, które się pojawiło.
Żaden legalny klient VPN nie prosi o numer pokoju, voucher portalu ani frazę hasła Wi-Fi jako dane uwierzytelniające. Kiedy to następuje, albo klient nie jest tym, za co się podaje, albo portal przechwytujący przechwytuje ruch, zanim powstanie tunel, i czytasz stronę HTML stylizowaną na logowanie.
Zatrzymaj się na tych pięciu warunkach
To miejsca, w których się zatrzymuję, zamiast iść dalej z prawdopodobnym obejściem. Każde jest tanie do sprawdzenia i drogie w razie pomyłki.
- Na portalu lub stronie SSO pojawia się ostrzeżenie o certyfikacie lub TLS. Nie przechodź przez nie klikając, aby dostać się do sieci.
- Strona prosi o sekret, który może zweryfikować tylko brama VPN lub dostawca tożsamości: hasło domenowe, kod jednorazowy, kod odzyskiwania, klucz prywatny.
- Domena nie odpowiada wydrukowanym instrukcjom miejsca ani hostowi logowania, który Twoja organizacja dokumentuje dla własnych usług.
- Proszony jesteś o zainstalowanie certyfikatu głównego, profilu konfiguracyjnego lub aplikacji pomocniczej, która nie pochodzi z zarządzania Twoimi urządzeniami.
- Przychodzi zatwierdzenie MFA, którego nie rozpocząłeś, albo klient VPN prosi o dane hotelowe.
Alternatywą nie jest inne hasło. Użyj hotspotu z telefonu, zapytaj w recepcji o dokładną nazwę sieci i metodę dostępu, i zgłoś stronę temu, kto zarządza siecią, albo swojemu działowi IT. Nic z tego nie wymaga testowania danych logowania na stronie, której nie możesz przypisać.
Przypisz awarię do właściwego etapu
Gdy oba etapy przejdą, awarie nadal się zdarzają, a błąd zwykle nazywa etap, jeśli czytasz po kolei: połączenie, przydział adresu, autoryzacja portalu, zestawienie tunelu, potem zasób wewnętrzny. Zmiana hasła VPN, bo wygasł kod portalu, traci czas i zostawia prawdziwy problem na miejscu.
Kilka prób rozdziela etapy. Po zalogowaniu do portalu poproś o zwykłą publiczną stronę HTTPS. Jeśli zamiast niej wróci portal, autoryzacja nigdy nie została ukończona na tej warstwie. Jeśli klient VPN zgłasza, że nie osiąga bramy, problem leży pod tunelem: sesja portalu, rozwiązywanie nazw albo sieć blokująca port. Jeśli tunel wstanie i jedna wewnętrzna nazwa hosta zawiedzie, rozwiązywanie nazw lub polityka w sieci prywatnej jest lepszym podejrzanym.
Sesje portalu wygasają też niezależnie od tunelu. Gdy miejsce odbierze dostęp, ustanowione połączenie VPN spada, choć jego dane nigdy nie były błędne. Autoryzuj portal ponownie, potem połącz VPN od nowa i pozwól mu ponownie wynegocjować. Rotacja hasła VPN wtedy niczego nie naprawia i może Cię zablokować.
Każdy sekret dawaj tylko systemowi, który może go zweryfikować, a prośbę niezgodną z tabelą traktuj jako znak stopu, a nie krok do obejścia. Jeśli oba etapy przejdą, a tunel nadal odmawia, zapisz dokładny błąd klienta, zanim zmienisz jakiekolwiek dane logowania.