Separați autentificările portalului Wi-Fi de cele VPN
Două sisteme diferite cer același lucru: o autentificare. Portalul controlează accesul local, VPN-ul accesul la o rețea privată. Întrebați la fiecare fereastră cine poate verifica într-adevăr acest secret.
Două sisteme diferite vă cer să vă autentificați înainte de a ajunge la ceva util într-o rețea publică: Wi-Fi-ul locului și gateway-ul VPN. Arată la fel pe ecran și autorizează lucruri complet diferite. Portalul decide dacă acest dispozitiv poate folosi rețeaua locală; VPN-ul decide dacă puteți ajunge la o rețea privată în altă parte. Le țin separate punând fiecărei ferestre o întrebare: cine poate verifica într-adevăr acest secret? Urmează lista de verificare pe care o aplic în hoteluri, aeroporturi și centre de conferințe, inclusiv punctele în care mă opresc din tastat.
Asociați fiecare autentificare cu serviciul care o verifică
O singură conexiune de hotel poate implica patru verificări separate, iar doar unele cer intervenția dumneavoastră. Puneți-le mai întâi în ordine, pentru că ecranul spune rar la ce etapă aparține.
| 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 |
Rețelele 802.1X, frecvente în birouri și universități, estompează primele două rânduri. Acolo autentificarea Wi-Fi este ea însăși o verificare de identitate față de un server RADIUS, iar clientul poate prezenta o identitate de rutare în timp ce contul real călătorește în interiorul schimbului criptat. Chiar și atunci verificarea privește alăturarea la rețea; nu autorizează tunelul, iar gateway-ul VPN nu o acceptă ca dovadă a nimic.
Ordinea contează mai mult decât etichetele. Portalurile captive există pentru că accesul poate fi acordat după asociere, de aceea un loc poate încredința pagina unui furnizor specializat. RFC 8952 de la IETF tratează portalul ca pe o componentă proprie, așa că un domeniu necunoscut este un motiv de verificare, nu o dovadă de fraudă în sine. Comparați domeniul cu instrucțiunile scrise ale locului și câmpurile cu tabelul.
Verificați ce are voie să ceară un portal
Câmpurile portalului țin de drept, nu de identitate: numărul camerei, numele de familie din rezervare, codul voucherului, codul tipărit pe husa cheii, un e-mail pentru un permis temporar, acceptarea termenilor. Locul știe deja cine a rezervat camera, așa că poate potrivi aceste fapte fără să afle ceva care i-ar permite să acționeze ca dumneavoastră în altă parte.
Orice dincolo de acea listă merită o pauză. O pagină de hotspot nu poate verifica parola dumneavoastră de domeniu, și ea nu poate verifica nici codul dumneavoastră de unică folosință pentru VPN, nici un cod de recuperare, nici o cheie privată, și nu are niciun motiv să le dorească. Singura excepție legitimă este o rețea administrată de o organizație: un SSID de oaspeți de birou sau un Wi-Fi de conferință vă pot trimite la furnizorul de identitate pe care îl folosiți deja la muncă. Rămâne distingibil: gazda de autentificare este cea zilnică, ecranul de consimțământ vă numește chiriașul, iar fluxul se deschide într-un tab vizibil al browserului.
E-mailul de marketing este separat: un alias de călătorie satisface câmpul fără a preda identitatea dumneavoastră profesională.
Verificați dacă clientul VPN vrea propriile credențiale
Clientul cere exact ceea ce este configurat profilul său, așa că fereastra așteptată este o proprietate a profilului, nu a rețelei pe care vă aflați. Profilele cu certificat arată de obicei o alegere de profil și apoi se conectează în tăcere. Profilele cu nume de utilizator și parolă le cer pe amândouă, adesea cu un cod de unică folosință. Profilele SSO deschid browserul la furnizorul de identitate și revin cu un token. WireGuard este din nou diferit: autentifică dispozitivele cu cheie publică și nu are autentificare de utilizator, așa că o fereastră care oferă nume de utilizator și parolă WireGuard nu descrie WireGuard.
Citiți profilul înainte de a călători. În OpenVPN, auth-user-pass vă spune că se așteaptă o cerere de parolă, în timp ce cert, key sau pkcs12 înseamnă că un certificat ar trebui să facă treaba. Dacă un profil care de obicei se conectează fără cerere cere brusc o parolă, suspectați un profil care nu a putut încărca certificatul sau a revenit la altă metodă. O cerere nu este o invitație de a tasta parola de serviciu în orice fereastră care a apărut.
Niciun client VPN legitim nu cere numărul camerei, voucherul portalului sau fraza de acces Wi-Fi ca intrare pentru autentificare. Când se întâmplă asta, fie clientul nu este ceea ce pretinde, fie un portal captiv interceptează traficul înainte de formarea tunelului și citiți o pagină HTML stilizată ca o autentificare.
Opriți-vă la aceste cinci condiții
Acestea sunt punctele în care mă opresc în loc să continui cu o soluție ocolitoare plauzibilă. Fiecare este ieftin de verificat și scump de greșit.
- Apare un avertisment de certificat sau TLS pe portal sau pe pagina SSO. Nu îl treceți prin clic pentru a ajunge la rețea.
- Pagina cere un secret pe care doar gateway-ul VPN sau furnizorul de identitate îl pot verifica: parolă de domeniu, cod de unică folosință, cod de recuperare, cheie privată.
- Domeniul nu corespunde instrucțiunilor tipărite ale locului sau gazdei de autentificare pe care organizația dumneavoastră o documentează pentru propriile servicii.
- Vi se cere să instalați un certificat rădăcină, un profil de configurare sau o aplicație auxiliară care nu provine din administrarea dispozitivelor dumneavoastră
- Sosește o aprobare MFA pe care nu ați inițiat-o, sau clientul VPN cere credențiale de hotel.
Alternativa nu este o altă parolă. Folosiți un hotspot de telefon, întrebați la recepție numele exact al rețelei și metoda de acces, și raportați pagina celui care administrează rețeaua sau serviciului dumneavoastră IT. Nimic din toate acestea nu cere testarea unei credențiale împotriva unei pagini pe care nu o puteți atribui.
Atribuiți o defecțiune etapei corecte
După ce ambele etape trec, defecțiunile apar în continuare, iar eroarea numește de obicei etapa dacă o citiți în ordine: asociere, atribuire de adresă, autorizare portal, stabilire tunel, apoi resursa internă. Schimbarea unei parole VPN pentru că a expirat un cod al portalului pierde timp și lasă problema reală pe loc.
Câteva teste separă etapele. După autentificarea la portal, cereți o pagină HTTPS publică obișnuită. Dacă în schimb revine portalul, autorizarea nu s-a finalizat niciodată la acel nivel. Dacă clientul VPN raportează că nu poate ajunge la gateway, problema este sub tunel: sesiunea portalului, rezolvarea numelor sau o rețea care blochează portul. Dacă tunelul se ridică și un nume de gazdă intern eșuează, rezolvarea numelor sau politica din rețeaua privată este suspectul mai bun.
Sesiunile portalului expiră și independent de tunel. Când locul revocă accesul, o conexiune VPN stabilită cade chiar dacă credențialele ei nu au fost niciodată greșite. Reautorizați portalul, apoi reconectați VPN-ul și lăsați-l să renegocieze. Rotirea parolei VPN atunci nu repară nimic și vă poate bloca afară.
Dați fiecare secret numai sistemului care îl poate verifica și tratați o cerere care nu se potrivește cu tabelul ca pe un semn de oprire, nu ca pe un pas de ocolit. Dacă ambele etape trec și tunelul refuză în continuare, capturați eroarea exactă a clientului înainte de a schimba orice credențială.