Adskil Wi-Fi-portalens logins fra VPN-logins
To forskellige systemer beder om det samme: et login. Portalen styrer lokal adgang, VPN styrer adgangen til et privat netværk. Spørg ved hvert vindue, hvem der reelt kan verificere hemmeligheden.
To forskellige systemer beder dig logge ind, før du kan nå noget nyttigt på et offentligt netværk: stedets Wi-Fi og din VPN-gateway. De ser ens ud på skærmen og autoriserer helt forskellige ting. Portalen afgør, om denne enhed må bruge det lokale netværk; VPN'en afgør, om du må nå et privat netværk et andet sted. Jeg holder dem adskilt ved at stille hvert vindue ét spørgsmål: hvem kan reelt verificere denne hemmelighed? Det følgende er den tjekliste, jeg kører på hoteller, i lufthavne og til konferencer, inklusive de punkter, hvor jeg stopper med at skrive.
Knyt hvert login til den tjeneste, der kontrollerer det
En enkelt hotelforbindelse kan omfatte fire separate kontroller, og kun nogle af dem vil have dit input. Sæt dem i rækkefølge først, fordi skærmen sjældent siger, hvilken fase den hører til.
| 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-netværk, almindelige på kontorer og universiteter, slører de to første rækker. Der er Wi-Fi-loginet selv en identitetskontrol mod en RADIUS-server, og klienten kan fremvise en routing-identitet, mens den rigtige konto rejser inde i den krypterede udveksling. Selv da handler kontrollen om at komme på netværket; den autoriserer ikke tunnelen, og VPN-gatewayen accepterer den ikke som bevis på noget.
Rækkefølgen betyder mere end etiketterne. Captive-portaler findes, fordi adgang kan gives efter tilkobling, og derfor kan et sted overlade siden til en specialiseret udbyder. RFC 8952 fra IETF behandler portalen som sin egen komponent, så et ukendt domæne er en grund til at kontrollere, ikke i sig selv bevis på svindel. Kontroller domænet mod stedets skriftlige instruktioner og felterne mod tabellen.
Kontroller, hvad en portal må spørge om
Portalfelter handler om berettigelse, ikke identitet: værelsesnummer, efternavn fra bookingen, værdikode, koden trykt på nøglehylstret, en e-mail til et tidsbegrænset pas, accept af vilkår. Stedet ved allerede, hvem der bookede værelset, så det kan matche disse oplysninger uden at lære noget, der ville lade det handle som dig andre steder.
Alt ud over den liste fortjener en pause. En hotspotside kan ikke verificere din domæneadgangskode, og den kan heller ikke verificere din engangskode til VPN, en gendannelseskode eller en privat nøgle, og den har ingen grund til at ville have dem. Den ene legitime undtagelse er et organisationsdrevet netværk: et gæste-SSID på kontoret eller konference-Wi-Fi kan sende dig videre til den identitetsudbyder, du allerede bruger på arbejdet. Det er stadig til at kende: login-værten er din daglige, samtykkeskærmen nævner din tenant, og flowet åbnes i en synlig browservane.
Marketing-e-mail er separat: et rejsealias opfylder feltet uden at udlevere din arbejdsidentitet.
Kontroller, at VPN-klienten vil have sine egne legitimationsoplysninger
Klienten beder om præcis det, dens profil er konfigureret til, så det forventede vindue er en egenskab ved profilen og ikke ved det netværk, du tilfældigvis er på. Certifikatprofiler viser normalt et profilvalg og forbinder derefter lydløst. Brugernavn- og adgangskodeprofiler beder om begge, ofte med en engangskode. SSO-profiler åbner din browser mod identitetsudbyderen og vender tilbage med et token. WireGuard er igen anderledes: det autentificerer enheder med en offentlig nøgle og har intet brugerlogin, så et vindue, der tilbyder WireGuard-brugernavn og -adgangskode, beskriver ikke WireGuard.
Læs profilen, før du rejser. I OpenVPN fortæller auth-user-pass dig, at en adgangskodeanmodning forventes, mens cert, key eller pkcs12 betyder, at et certifikat bør gøre arbejdet. Hvis en profil, der normalt forbinder uden en anmodning, pludselig beder om en adgangskode, så mistænk en profil, der ikke kunne indlæse sit certifikat eller faldt tilbage til en anden metode. En anmodning er ikke en invitation til at skrive din arbejdsadgangskode i hvilket som helst vindue, der dukkede op.
Ingen legitim VPN-klient beder om værelsesnummeret, portalværdien eller Wi-Fi-adgangsfrasen som input til godkendelse. Når det sker, er klienten enten ikke det, den udgiver sig for, eller en captive-portal opfanger trafik, før tunnelen dannes, og du læser en HTML-side, der er stylet som et login.
Stop ved disse fem betingelser
Det er de punkter, hvor jeg stopper i stedet for at fortsætte med en plausibel omvej. Hvert af dem er billigt at kontrollere og dyrt at tage fejl af.
- En certifikat- eller TLS-advarsel vises på portalen eller på SSO-siden. Klik ikke igennem den for at nå netværket.
- Siden beder om en hemmelighed, som kun VPN-gatewayen eller identitetsudbyderen kan verificere: domæneadgangskode, engangskode, gendannelseskode, privat nøgle.
- Domænet matcher ikke stedets trykte instruktioner eller den login-vært, din organisation dokumenterer til sine egne tjenester.
- Du bliver bedt om at installere et rodcertifikat, en konfigurationsprofil eller et hjælpeprogram, der ikke kommer fra din enhedsstyring.
- En MFA-godkendelse ankommer, som du ikke selv startede, eller VPN-klienten beder om hoteloplysninger.
Fallbacken er ikke en anden adgangskode. Brug et telefon-hotspot, spørg receptionen om det præcise netværksnavn og adgangsmetoden, og rapportér siden til den, der driver netværket, eller din IT-afdeling. Intet af det kræver at teste en legitimationsoplysning mod en side, du ikke kan henføre.
Henfør en fejl til det rigtige trin
Når begge trin er bestået, sker der stadig fejl, og fejlen nævner normalt trinnet, hvis du læser den i rækkefølge: tilkobling, adressetildeling, portalautorisation, tunneletablering og derefter den interne ressource. At ændre en VPN-adgangskode, fordi en portal-kode er udløbet, spilder tid og lader det egentlige problem blive.
Et par prøver adskiller trinnene. Efter portal-login, anmod om en almindelig offentlig HTTPS-side. Hvis portalen kommer tilbage i stedet, blev autorisationen aldrig fuldført på det lag. Hvis VPN-klienten rapporterer, at den ikke kan nå gatewayen, ligger problemet under tunnelen: portal-sessionen, navneopløsningen eller et netværk, der blokerer porten. Hvis tunnelen kommer op, og ét internt værtsnavn fejler, er navneopløsning eller politik inde i det private netværk den bedre mistænkte.
Portal-sessioner udløber også uafhængigt af tunnelen. Når stedet tilbagekalder adgang, falder en etableret VPN-forbindelse, selv om dens legitimationsoplysninger aldrig var forkerte. Autoriser portalen igen, genopret derefter VPN-forbindelsen, og lad den forhandle igen. At rotere VPN-adgangskoden så retter ingenting og kan låse dig ude.
Giv hver hemmelighed kun til det system, der kan verificere den, og behandl en anmodning, der ikke passer til tabellen, som et stopskilt i stedet for et trin, der skal omgås. Hvis begge trin består, og tunnelen stadig afviser, så fang den præcise klientfejl, før du ændrer nogen legitimationsoplysning.