Skill Wi-Fi-portalinnlogginger fra VPN-innlogginger
To forskjellige systemer ber om det samme: en innlogging. Portalen styrer lokal tilgang, VPN-en styrer tilgangen til et privat nettverk. Spør ved hvert vindu hvem som egentlig kan verifisere hemmeligheten.
To forskjellige systemer ber deg logge inn før du når noe nyttig på et offentlig nettverk: stedets Wi-Fi og VPN-gatewayen din. De ser like ut på skjermen og autoriserer helt forskjellige ting. Portalen avgjør om denne enheten kan bruke det lokale nettverket; VPN-en avgjør om du kan nå et privat nettverk et annet sted. Jeg holder dem fra hverandre ved å stille hvert vindu ett spørsmål: hvem kan egentlig verifisere denne hemmeligheten? Det som følger er sjekklisten jeg bruker på hoteller, flyplasser og konferansesteder, inkludert punktene der jeg slutter å skrive.
Knytt hver innlogging til tjenesten som kontrollerer den
Én hotellforbindelse kan innebære fire separate kontroller, og bare noen av dem vil ha innspill fra deg. Sett dem i rekkefølge først, fordi skjermen sjelden sier hvilket trinn 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-nettverk, vanlige på kontorer og universiteter, slører de to første radene. Der er Wi-Fi-innloggingen selv en identitetskontroll mot en RADIUS-server, og klienten kan presentere en rutingidentitet mens den virkelige kontoen reiser inne i den krypterte utvekslingen. Selv da handler kontrollen om å bli med i nettverket; den autoriserer ikke tunnelen, og VPN-gatewayen godtar den ikke som bevis på noe.
Rekkefølgen betyr mer enn etikettene. Captive-portaler finnes fordi tilgang kan gis etter tilkobling, og derfor kan et sted overlate siden til en spesialisert leverandør. RFC 8952 fra IETF behandler portalen som sin egen komponent, så et ukjent domene er grunn til å kontrollere, ikke bevis på svindel i seg selv. Sammenlign domenet med stedets skriftlige instruksjoner, og feltene med tabellen.
Sjekk hva en portal har lov til å spørre om
Portalfelter handler om berettigelse, ikke identitet: romnummer, etternavn fra bestillingen, verdikode, koden trykt på nøkkelholderen, en e-post for et tidsbegrenset pass, aksept av vilkår. Stedet vet allerede hvem som bestilte rommet, så det kan matche disse opplysningene uten å lære noe som ville la det handle som deg andre steder.
Alt utover den listen fortjener en pause. En hotspotside kan ikke verifisere domenepassordet ditt, og den kan heller ikke verifisere engangskoden din for VPN, en gjenopprettingskode eller en privat nøkkel, og den har ingen grunn til å ville ha dem. Det eneste legitime unntaket er et organisasjonsdrevet nettverk: et gjeste-SSID på kontoret eller konferanse-Wi-Fi kan sende deg videre til identitetsleverandøren du allerede bruker på jobben. Det er fortsatt gjenkjennelig: innloggingsverten er din daglige, samtykkeskjermen navngir tenanten din, og flyten åpnes i en synlig nettleserfane.
Markedsførings-e-post er separat: et reisealias oppfyller feltet uten å gi fra deg arbeidsidentiteten.
Sjekk at VPN-klienten vil ha egne påloggingsdata
Klienten ber om nøyaktig det profilen er konfigurert for, så det forventede vinduet er en egenskap ved profilen og ikke ved nettverket du tilfeldigvis er på. Sertifikatprofiler viser vanligvis et profilvalg og kobler deretter til i det stille. Brukernavn- og passordprofiler ber om begge, ofte med engangskode. SSO-profiler åpner nettleseren mot identitetsleverandøren og kommer tilbake med et token. WireGuard er annerledes igjen: det autentiserer enheter med offentlig nøkkel og har ingen brukerinnlogging, så et vindu som tilbyr WireGuard-brukernavn og -passord beskriver ikke WireGuard.
Les profilen før du reiser. I OpenVPN forteller auth-user-pass deg at en passordforespørsel forventes, mens cert, key eller pkcs12 betyr at et sertifikat skal gjøre jobben. Hvis en profil som vanligvis kobler til uten forespørsel plutselig ber om passord, mistenke en profil som ikke fikk lastet sertifikatet eller falt tilbake til en annen metode. En forespørsel er ikke en invitasjon til å skrive arbeidspassordet i hvilket som helst vindu som dukket opp.
Ingen legitim VPN-klient ber om romnummeret, portalverdien eller Wi-Fi-passfrasen som autentiseringsinput. Når det skjer, er klienten enten ikke det den utgir seg for, eller en captive-portal fanger trafikk før tunnelen dannes, og du leser en HTML-side stilet som en innlogging.
Stopp ved disse fem vilkårene
Dette er punktene der jeg stopper i stedet for å fortsette med en plausibel omvei. Hvert av dem er billig å kontrollere og dyrt å ta feil av.
- En sertifikat- eller TLS-advarsel vises på portalen eller på SSO-siden. Ikke klikk deg gjennom den for å nå nettverket.
- Siden ber om en hemmelighet som bare VPN-gatewayen eller identitetsleverandøren kan verifisere: domenepassord, engangskode, gjenopprettingskode, privat nøkkel.
- Domenet samsvarer ikke med stedets trykte instruksjoner eller med innloggingsverten organisasjonen din dokumenterer for sine egne tjenester.
- Du blir bedt om å installere et rotsertifikat, en konfigurasjonsprofil eller et hjelpeprogram som ikke kommer fra enhetsadministrasjonen din.
- En MFA-godkjenning ankommer som du ikke startet, eller VPN-klienten ber om hotellpåloggingsdata.
Fallbacken er ikke et annet passord. Bruk et telefon-hotspot, spør resepsjonen om det nøyaktige nettverksnavnet og tilgangsmetoden, og rapporter siden til den som driver nettverket, eller IT-avdelingen din. Ingenting av dette krever å teste en påloggingsdetalj mot en side du ikke kan tilordne.
Henfør en feil til riktig trinn
Når begge trinnene er bestått, skjer feil fortsatt, og feilen navngir vanligvis trinnet hvis du leser den i rekkefølge: tilkobling, adressetildeling, portalautorisasjon, tunneletablering, deretter den interne ressursen. Å endre et VPN-passord fordi en portalkode utløp, kaster bort tid og lar det egentlige problemet bli.
Noen få tester skiller trinnene. Etter portalinnlogging, be om en vanlig offentlig HTTPS-side. Hvis portalen kommer tilbake i stedet, ble autorisasjonen aldri fullført på det laget. Hvis VPN-klienten rapporterer at den ikke når gatewayen, ligger problemet under tunnelen: portalsesjonen, navneoppslag eller et nettverk som blokkerer porten. Hvis tunnelen kommer opp og ett internt vertsnavn feiler, er navneoppslag eller policy inne i det private nettverket den bedre mistenkte.
Portalsesjoner utløper også uavhengig av tunnelen. Når stedet trekker tilbake tilgang, faller en etablert VPN-forbindelse selv om påloggingsdetaljene aldri var feil. Autoriser portalen på nytt, koble deretter til VPN-en igjen og la den forhandle på nytt. Å rotere VPN-passordet da retter ingenting og kan låse deg ute.
Gi hver hemmelighet bare til systemet som kan verifisere den, og behandle en forespørsel som ikke passer med tabellen som et stoppskilt i stedet for et trinn som skal omgås. Hvis begge trinnene består og tunnelen fortsatt nekter, fange den nøyaktige klientfeilen før du endrer noen påloggingsdetalj.