Atskirkite „Wi-Fi“ portalo ir VPN prisijungimus
Dvi skirtingos sistemos prašo prisijungti: vietos „Wi-Fi“ ir jūsų VPN šliuzas. Ekrane jos atrodo vienodai, bet leidžia visiškai skirtingus dalykus. Kiekviename lange klauskite: kas iš tikrųjų gali patikrinti šią paslaptį?
Dvi skirtingos sistemos prašo jūsų prisijungti, kol dar nepasiekėte nieko naudingo viešajame tinkle: vietos „Wi-Fi“ ir jūsų VPN šliuzas. Ekrane jos atrodo vienodai ir leidžia visiškai skirtingus dalykus. Portalas sprendžia, ar šis įrenginys gali naudotis vietiniu tinklu; VPN sprendžia, ar galite pasiekti privatų tinklą kitur. Aš jas skiriu kiekviename lange užduodamas vieną klausimą: kas iš tikrųjų gali patikrinti šią paslaptį? Toliau pateikiamas kontrolinis sąrašas, kurį naudoju viešbučiuose, oro uostuose ir konferencijų vietose, įskaitant taškus, kur nustoju rašyti.
Susiekite kiekvieną prisijungimą su jį tikrinančia paslauga
Vienas viešbučio ryšys gali apimti keturis atskirus patikrinimus, ir tik kai kurie prašo jūsų įvesties. Pirmiausia sudėliokite juos eilės tvarka, nes ekranas retai pasako, kuriam etapui jis priklauso.
| 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 tinklai, paplitę biuruose ir universitetuose, sulieja pirmąsias dvi eilutes. Ten „Wi-Fi“ prisijungimas pats yra tapatybės patikrinimas RADIUS serveryje, o klientas gali pateikti maršrutizavimo tapatybę, kol tikroji paskyra keliauja šifruotame pasikeitime. Net tada patikrinimas susijęs su prisijungimu prie tinklo; jis neįgalioja tunelio, o VPN šliuzas jo nelaiko nieko įrodymu.
Tvarka svarbesnė už etiketes. „Captive“ portalai egzistuoja todėl, kad prieigą galima suteikti po prisijungimo, todėl vieta gali perduoti puslapį specializuotam teikėjui. IETF RFC 8952 laiko portalą atskiru komponentu, tad nepažįstamas domenas yra priežastis patikrinti, o ne savaiminis sukčiavimo įrodymas. Palyginkite domeną su rašytinėmis vietos instrukcijomis, o laukus – su lentele.
Patikrinkite, ko portalas gali prašyti
Portalo laukai susiję su teise, ne su tapatybe: kambario numeris, rezervacijos pavardė, kupono kodas, kodas, atspausdintas ant raktų dėklo, elektroninis paštas laikinam leidimui, sąlygų priėmimas. Vieta jau žino, kas užsakė kambarį, todėl gali suderinti šiuos faktus, nesužinodama nieko, kas leistų jai veikti kaip jums kitur.
Viskas, kas viršija šį sąrašą, vertas pauzės. Hotspot puslapis negali patikrinti jūsų domeno slaptažodžio, ir jis taip pat negali patikrinti jūsų vienkartinio VPN kodo, atkūrimo kodo ar privataus rakto, ir neturi priežasties jų norėti. Vienintelė teisėta išimtis – organizacijos valdomas tinklas: biuro svečių SSID ar konferencijos „Wi-Fi“ gali nukreipti jus pas tapatybės teikėją, kurį jau naudojate darbui. Jį vis tiek galima atskirti: prisijungimo hostas yra jūsų kasdienis, sutikimo ekranas įvardija jūsų nuomininką, o srautas atsidaro matomame naršyklės skirtuke.
Rinkodaros elektroninis paštas yra atskirai: kelionės slapyvardis patenkina lauką neperduodamas jūsų darbo tapatybės.
Patikrinkite, ar VPN klientas nori savo duomenų
Klientas prašo būtent to, kam sukonfigūruotas jo profilis, todėl laukiamas langas yra profilio savybė, o ne tinklo, kuriame atsidūrėte. Sertifikato profiliai dažniausiai parodo profilio pasirinkimą ir tada prisijungia tyliai. Vartotojo vardo ir slaptažodžio profiliai prašo abiejų, dažnai su vienkartiniu kodu. SSO profiliai atidaro naršyklę tapatybės teikėjo puslapyje ir grįžta su žetonu. „WireGuard“ vėl kitoks: įrenginius autentifikuoja viešuoju raktu ir neturi vartotojo prisijungimo, tad langas, siūlantis „WireGuard“ vartotojo vardą ir slaptažodį, neaprašo „WireGuard“.
Prieš kelionę perskaitykite profilį. OpenVPN auth-user-pass nurodo, kad tikimasi slaptažodžio užklausos, o cert, key ar pkcs12 reiškia, kad darbą turėtų atlikti sertifikatas. Jei profilis, kuris paprastai prisijungia be užklausos, staiga prašo slaptažodžio, įtarkite profilį, kuris nesugebėjo įkelti sertifikato arba perėjo prie kito metodo. Užklausa nėra kvietimas įvesti darbo slaptažodį į bet kurį pasirodžiusį langą.
Nė vienas teisėtas VPN klientas neprašo kambario numerio, portalo kupono ar „Wi-Fi“ slaptafrazės kaip autentifikavimo įvesties. Kai taip nutinka, arba klientas nėra tai, kuo prisistato, arba „captive“ portalas perima srautą prieš susiformuojant tuneliui, ir jūs skaitote HTML puslapį, suformuotą kaip prisijungimas.
Sustokite ties šiomis penkiomis sąlygomis
Tai taškai, kuriuose aš sustoju, o ne tęsiu su tikėtinu apėjimo keliu. Kiekvieną pigu patikrinti ir brangu suklysti.
- Sertifikato ar TLS įspėjimas pasirodo portale arba SSO puslapyje. Nepereikite jo paspaudę, kad patektumėte į tinklą.
- Puslapis prašo paslapties, kurią gali patikrinti tik VPN šliuzas arba tapatybės teikėjas: domeno slaptažodis, vienkartinis kodas, atkūrimo kodas, privatus raktas.
- Domenas neatitinka spausdintų vietos instrukcijų arba prisijungimo hosto, kurį jūsų organizacija dokumentuoja savo paslaugoms.
- Jūsų prašoma įdiegti šakninį sertifikatą, konfigūracijos profilį ar pagalbinę programą, kuri negaunama iš jūsų įrenginių valdymo.
- Ateina MFA patvirtinimas, kurio nepradėjote, arba VPN klientas prašo viešbučio duomenų.
Alternatyva nėra kitas slaptažodis. Naudokite telefono hotspotą, reception paklauskite tikslaus tinklo pavadinimo ir prisijungimo metodo, o apie puslapį praneškite tinklo valdytojui arba savo IT tarnybai. Niekas iš to nereikalauja tikrinti prisijungimo duomenų puslapyje, kurio negalite priskirti.
Priskirkite gedimą tinkamam etapui
Kai abu etapai praeiti, gedimai vis tiek nutinka, ir klaida dažniausiai įvardija etapą, jei skaitote iš eilės: prisijungimas, adreso suteikimas, portalo autorizacija, tunelio sukūrimas, tada vidinis išteklius. VPN slaptažodžio keitimas dėl pasibaigusio portalo kodo gaišina laiką ir palieka tikrąją problemą vietoje.
Keli bandymai atskiria etapus. Po prisijungimo prie portalo paprašykite įprasto viešo HTTPS puslapio. Jei vietoj jo grįžta portalas, autorizacija tame sluoksnyje niekada nebuvo baigta. Jei VPN klientas praneša, kad negali pasiekti šliuzo, problema yra žemiau tunelio: portalo sesija, vardų sprendimas ar tinklas, blokuojantis prievadą. Jei tunelis pakyla ir vienas vidinis hosto vardas nepavyksta, vardų sprendimas ar politika privačiame tinkle yra geresnis įtariamasis.
Portalo sesijos taip pat baigiasi nepriklausomai nuo tunelio. Kai vieta atšaukia prieigą, užmegztas VPN ryšys nutrūksta, nors jo duomenys niekada nebuvo neteisingi. Iš naujo autorizuokite portalą, tada vėl prijunkite VPN ir leiskite jam iš naujo derėtis. Tada VPN slaptažodžio keitimas nieko netaiso ir gali jus užrakinti.
Kiekvieną paslaptį duokite tik tai sistemai, kuri gali ją patikrinti, o užklausą, kuri neatitinka lentelės, laikykite stop ženklu, o ne apeinamu žingsniu. Jei abu etapai praeiti, o tunelis vis tiek atsisako, užfiksuokite tikslią kliento klaidą prieš keisdami bet kokius prisijungimo duomenis.