Skei portaal- en VPN-aanmeldings van mekaar
Twee verskillende stelsels vra dieselfde ding: ’n aanmelding. Die portaal beheer plaaslike toegang, die VPN toegang tot ’n private netwerk. Vra by elke venster wie die geheim werklik kan verifieer.
Twee verskillende stelsels vra jou om aan te meld voordat jy enigiets nuttigs op ’n publieke netwerk kan bereik: die lokaal se Wi-Fi en jou VPN-gateway. Hulle lyk dieselfde op die skerm en magtig heeltemal verskillende dinge. Die portaal besluit of hierdie toestel die plaaslike netwerk mag gebruik; die VPN besluit of jy ’n private netwerk elders mag bereik. Ek hou hulle apart deur by elke venster een vraag te vra: wie kan hierdie geheim werklik verifieer? Wat volg, is die kontrolelys wat ek by hotelle, lughawens en konferensiesale afloop, insluitend die punte waar ek ophou tik.
Karteer elke aanmelding na die diens wat dit nagaan
Een hotelverbinding kan vier aparte kontroles behels, en net sommige vra jou insette. Plaas hulle eers in volgorde, want die skerm sê selde by watter stadium dit hoort.
| 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-netwerke, algemeen in kantore en universiteite, vervaag die eerste twee rye. Daar is die Wi-Fi-aanmelding self ’n identiteitskontrole teen ’n RADIUS-bediener, en die kliënt kan ’n roeteringsidentiteit voorhou terwyl die werklike rekening binne die versleutelde uitruiling reis. Selfs dan gaan die kontrole oor aansluiting by die netwerk; dit magtig nie die tonnel nie, en die VPN-gateway aanvaar dit nie as bewys van enigiets nie.
Volgorde maak meer saak as etikette. Captive portals bestaan omdat toegang ná assosiasie verleen kan word, en daarom kan ’n lokaal die bladsy aan ’n gespesialiseerde verskaffer gee. Die IETF se RFC 8952 behandel die portaal as sy eie komponent, so ’n onbekende domein is ’n rede om te verifieer, nie op sigself bewys van bedrog nie. Kontroleer die domein teen die lokaal se geskrewe instruksies, en die velde teen die tabel.
Kyk waarvoor ’n portaal mag vra
Portaalvelde gaan oor geregtigheid, nie identiteit nie: kamernommer, besprekingsvan, koeponnommer, die kode wat op ’n sleutelhouer gedruk is, ’n e-pos vir ’n tydelike pas, aanvaarding van voorwaardes. Die lokaal weet reeds wie die kamer bespreek het, so dit kan daardie feite pas sonder om iets te leer wat hom elders as jy sou laat optree.
Enigiets verby daardie lys verdien ’n pouse. ’n Hotspot-bladsy kan nie jou domeinwagwoord verifieer nie, en dit kan ook nie jou VPN-eenmalige kode, ’n herstelkode of ’n private sleutel verifieer nie; dit het geen rede om hulle te wil hê nie. Die een wettige uitsondering is ’n netwerk wat deur ’n organisasie bedryf word: ’n kantoor-gas-SSID of ’n konferensie-Wi-Fi kan jou na die identiteitsverskaffer stuur wat jy reeds vir werk gebruik. Dit bly steeds onderskeibaar: die aanmeldhost is jou daaglikse een, die toestemmingskerm noem jou tenant, en die vloei open in ’n sigbare blaaier-oortjie.
Bemarkings-e-pos is apart: ’n reis-alias bevredig die veld sonder om jou werkidentiteit oor te gee.
Kontroleer dat die VPN-kliënt sy eie geloofsbriewe wil hê
Die kliënt vra presies wat sy profiel gekonfigureer is om te gebruik, so die verwagte venster is ’n eienskap van die profiel en nie van die netwerk waarop jy toevallig is nie. Sertifikaatprofiele wys gewoonlik ’n profielkeuse en verbind dan stilweg. Gebruikersnaam-en-wagwoordprofiele vra albei, dikwels met ’n eenmalige kode. SSO-profiele open jou blaaier na die identiteitsverskaffer en keer met ’n token terug. WireGuard is weer anders: dit verifieer toestelle met ’n publieke sleutel en het geen gebruikeraanmelding nie, so ’n venster wat ’n WireGuard-gebruikersnaam en -wagwoord bied, beskryf nie WireGuard nie.
Lees die profiel voordat jy reis. In OpenVPN, auth-user-pass sê vir jou dat ’n wagwoordvenster verwag word, terwyl cert, key of pkcs12 beteken ’n sertifikaat behoort die werk te doen. As ’n profiel wat gewoonlik sonder ’n venster verbind, skielik ’n wagwoord vra, vermoed ’n profiel wat nie sy sertifikaat kon laai nie of na ’n ander metode teruggeval het. ’n Venster is nie ’n uitnodiging om jou werkwagwoord in enige venster wat verskyn het te tik nie.
Geen wettige VPN-kliënt vra die kamernommer, die portaalkoepon of die Wi-Fi-wagfrase as ’n verifikasie-inset nie. Wanneer dit gebeur, is die kliënt óf nie wat hy voorgee te wees nie, óf ’n captive portal onderskep verkeer voordat die tonnel gevorm word en jy lees ’n HTML-bladsy wat soos ’n aanmelding laat lyk.
Stop by hierdie vyf toestande
Dit is die punte waar ek stop eerder as om met ’n waarskynlike ompad voort te gaan. Elkeen is goedkoop om na te gaan en duur om verkeerd te kry.
- ’n Sertifikaat- of TLS-waarskuwing verskyn op die portaal of op die SSO-bladsy. Moenie daarop klik om die netwerk te bereik nie.
- Die bladsy vra ’n geheim wat net die VPN-gateway of identiteitsverskaffer kan verifieer: domeinwagwoord, eenmalige kode, herstelkode, private sleutel.
- Die domein stem nie ooreen met die lokaal se gedrukte instruksies of die aanmeldhost wat jou organisasie vir sy eie dienste dokumenteer nie.
- Jy word gevra om ’n wortelsertifikaat, ’n konfigurasieprofiel of ’n hulpprogram te installeer wat nie van jou toestelbestuur kom nie.
- ’n MFA-goedkeuring kom in wat jy nie begin het nie, of die VPN-kliënt vra hotel-geloofsbriewe.
Die terugval is nie ’n ander wagwoord nie. Gebruik ’n selfoon-hotspot, vra die frontlessenaar vir die presiese netwerknaam en toegangsmetode, en rapporteer die bladsy aan wie die netwerk of jou IT-lessenaar bestuur. Niks daarvan vereis om ’n geloofsbrief teen ’n bladsy te toets wat jy nie kan toeskryf nie.
Ken ’n mislukking aan die regte stadium toe
Sodra albei stadiums geslaag het, gebeur mislukkings steeds, en die fout noem gewoonlik die stadium as jy dit in volgorde lees: assosiasie, adrestoewysing, portaalgoedkeuring, tonnelvestiging, dan die interne hulpbron. Om ’n VPN-wagwoord te verander omdat ’n portaal-kode verval het, mors tyd en laat die werklike probleem staan.
’n Paar toetse skei die stadiums. Ná portaal-aanmelding, versoek ’n gewone publieke HTTPS-bladsy. As die portaal eerder terugkeer, het goedkeuring nooit op daardie laag voltooi nie. As die VPN-kliënt rapporteer dat hy nie die gateway kan bereik nie, sit die probleem onder die tonnel: die portaal-sessie, naamresolusie, of ’n netwerk wat die poort blokkeer. As die tonnel opkom en een interne gasheernaam misluk, is naamresolusie of beleid binne die private netwerk die beter vermoede.
Portaal-sessies verval ook onafhanklik van die tonnel. Wanneer die lokaal toegang herroep, val ’n gevestigde VPN-verbinding weg, al was sy geloofsbriewe nooit verkeerd nie. Herverifieer die portaal, herverbind dan die VPN en laat dit heronderhandel. Om dan die VPN-wagwoord te roteer, maak niks reg nie en kan jou uitsluit.
Gee elke geheim net aan die stelsel wat dit kan verifieer, en beskou ’n venster wat nie by die tabel pas nie as ’n stopteken eerder as ’n stap om te omseil. As albei stadiums slaag en die tonnel weier steeds, vang die presiese kliëntfout op voordat jy enige geloofsbrief verander.