Skilj Wi-Fi-portalens inloggningar från VPN-inloggningar
Två olika system ber om samma sak: en inloggning. Portalen styr lokal åtkomst, VPN:n åtkomsten till ett privat nätverk. Fråga vid varje fönster vem som egentligen kan verifiera hemligheten.
Två olika system ber dig logga in innan du når något användbart på ett offentligt nätverk: platsens Wi-Fi och din VPN-gateway. De ser likadana ut på skärmen och auktoriserar helt olika saker. Portalen avgör om den här enheten får använda det lokala nätverket; VPN:n avgör om du når ett privat nätverk någon annanstans. Jag håller dem åtskilda genom att ställa en fråga till varje fönster: vem kan egentligen verifiera den här hemligheten? Det som följer är checklistan jag använder på hotell, flygplatser och konferensanläggningar, inklusive punkterna där jag slutar skriva.
Koppla varje inloggning till tjänsten som kontrollerar den
En enda hotellanslutning kan omfatta fyra separata kontroller, och bara några av dem vill ha din inmatning. Sätt dem i ordning först, eftersom skärmen sällan säger vilket steg den hör till.
| 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-nätverk, vanliga på kontor och universitet, suddar ut de två första raderna. Där är Wi-Fi-inloggningen i sig en identitetskontroll mot en RADIUS-server, och klienten kan presentera en routingidentitet medan det riktiga kontot reser inuti det krypterade utbytet. Även då handlar kontrollen om att ansluta till nätverket; den auktoriserar inte tunneln, och VPN-gatewayen accepterar den inte som bevis för något.
Ordningen spelar större roll än etiketterna. Captive-portaler finns eftersom åtkomst kan beviljas efter anslutningen, och därför kan en plats lämna sidan till en specialiserad leverantör. RFC 8952 från IETF behandlar portalen som en egen komponent, så en okänd domän är skäl att kontrollera, inte i sig bevis på bedrägeri. Jämför domänen med platsens skriftliga instruktioner och fälten med tabellen.
Kontrollera vad en portal får fråga om
Portalfält handlar om rättighet, inte identitet: rumsnummer, efternamn från bokningen, värdekod, koden tryckt på nyckelholken, en e-postadress för ett tidsbegränsat pass, godkännande av villkor. Platsen vet redan vem som bokade rummet, så den kan matcha dessa uppgifter utan att lära sig något som skulle låta den agera som du någon annanstans.
Allt utöver den listan förtjänar en paus. En hotspotsida kan inte verifiera ditt domänlösenord, och den kan inte heller verifiera din engångskod för VPN, en återställningskod eller en privat nyckel, och den har ingen anledning att vilja ha dem. Det enda legitima undantaget är ett organisationsdrivet nätverk: ett gäst-SSID på kontoret eller konferens-Wi-Fi kan skicka dig vidare till identitetsleverantören du redan använder för jobbet. Det går fortfarande att känna igen: inloggningsvärden är din dagliga, samtyckesskärmen namnger din tenant, och flödet öppnas i en synlig webbläsarflik.
Marknadsföringsmejl är separat: ett resealias fyller fältet utan att lämna ut din arbetsidentitet.
Kontrollera att VPN-klienten vill ha egna inloggningsuppgifter
Klienten begär exakt det som dess profil är konfigurerad för, så det förväntade fönstret är en egenskap hos profilen och inte hos nätverket du råkar vara på. Certifikatprofiler visar vanligtvis ett profilval och ansluter sedan tyst. Användarnamns- och lösenordsprofiler ber om båda, ofta med en engångskod. SSO-profiler öppnar webbläsaren mot identitetsleverantören och återvänder med en token. WireGuard är annorlunda igen: det autentiserar enheter med publik nyckel och har ingen användarinloggning, så ett fönster som erbjuder WireGuard-användarnamn och lösenord beskriver inte WireGuard.
Läs profilen innan du reser. I OpenVPN berättar auth-user-pass att en lösenordsförfrågan förväntas, medan cert, key eller pkcs12 betyder att ett certifikat ska göra jobbet. Om en profil som vanligtvis ansluter utan förfrågan plötsligt ber om ett lösenord, misstänk en profil som inte kunde läsa in sitt certifikat eller föll tillbaka på en annan metod. En förfrågan är inte en inbjudan att skriva arbetslösenordet i vilket fönster som helst som dykt upp.
Ingen legitim VPN-klient ber om rumsnumret, portalförmånen eller Wi-Fi-lösenfrasen som autentiseringsinmatning. När det händer är klienten antingen inte vad den utger sig för att vara, eller så fångar en captive-portal trafik innan tunneln bildas och du läser en HTML-sida formgiven som en inloggning.
Stanna vid dessa fem villkor
Det här är punkterna där jag stannar i stället för att fortsätta med en trovärdig omväg. Var och en är billig att kontrollera och dyr att missa.
- En certifikat- eller TLS-varning visas på portalen eller på SSO-sidan. Klicka inte igenom den för att nå nätverket.
- Sidan ber om en hemlighet som bara VPN-gatewayen eller identitetsleverantören kan verifiera: domänlösenord, engångskod, återställningskod, privat nyckel.
- Domänen stämmer inte med platsens tryckta instruktioner eller med inloggningsvärden som din organisation dokumenterar för sina egna tjänster.
- Du ombeds installera ett rotcertifikat, en konfigurationsprofil eller ett hjälpprogram som inte kommer från din enhetshantering.
- Ett MFA-godkännande anländer som du inte startade, eller VPN-klienten ber om hotelluppgifter.
Alternativet är inte ett annat lösenord. Använd en telefonhotspot, fråga receptionen om det exakta nätverksnamnet och åtkomstmetoden, och rapportera sidan till den som driver nätverket eller till din IT-avdelning. Inget av det kräver att testa en inloggningsuppgift mot en sida du inte kan tillskriva.
Hänför ett fel till rätt steg
När båda stegen har passerat händer fortfarande fel, och felet namnger vanligtvis steget om du läser det i ordning: anslutning, adresstilldelning, portalauktorisering, tunnelupprättande, sedan den interna resursen. Att byta VPN-lösenord för att en portalkod gått ut slösar tid och lämnar det verkliga problemet kvar.
Några tester skiljer stegen. Efter portal-inloggningen, begär en vanlig offentlig HTTPS-sida. Om portalen kommer tillbaka i stället fullbordades aldrig auktoriseringen på det lagret. Om VPN-klienten rapporterar att den inte når gatewayen ligger problemet under tunneln: portalsessionen, namnutslagningen eller ett nätverk som blockerar porten. Om tunneln kommer upp och ett internt värdnamn misslyckas är namnutslagning eller policy inne i det privata nätverket den bättre misstänkte.
Portalsessionerna löper också ut oberoende av tunneln. När platsen återkallar åtkomst faller en etablerad VPN-anslutning trots att dess inloggningsuppgifter aldrig var fel. Auktorisera portalen igen, anslut sedan VPN:en igen och låt den förhandla om. Att rotera VPN-lösenordet då lagar ingenting och kan låsa ut dig.
Ge varje hemlighet bara till systemet som kan verifiera den, och behandla en förfrågan som inte passar tabellen som en stoppskylt i stället för ett steg att kringgå. Om båda stegen passerar och tunneln fortfarande vägrar, fånga det exakta klientfelet innan du ändrar några inloggningsuppgifter.