Distinguere gli accessi al portale Wi-Fi da quelli VPN
Due sistemi diversi chiedono un accesso: il Wi-Fi del locale e il gateway VPN. Sullo schermo si somigliano e autorizzano cose del tutto diverse. Chiedete a ogni finestra: chi può davvero verificare questo segreto?
Due sistemi diversi vi chiedono di accedere prima di raggiungere qualcosa di utile su una rete pubblica: il Wi-Fi del locale e il gateway VPN. Sullo schermo si somigliano e autorizzano cose del tutto diverse. Il portale decide se questo dispositivo può usare la rete locale; il VPN decide se potete raggiungere una rete privata altrove. Li tengo separati ponendo a ogni finestra una domanda: chi può davvero verificare questo segreto? Quella che segue è la lista di controllo che applico in hotel, aeroporti e centri congressi, compresi i punti in cui smetto di digitare.
Associate ogni accesso al servizio che lo controlla
Una singola connessione d’albergo può comportare quattro controlli separati, e solo alcuni vogliono un vostro input. Metteteli prima in ordine, perché lo schermo raramente dice a quale stadio appartiene.
| 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 |
Le reti 802.1X, comuni in uffici e università, confondono le prime due righe. Lì l’accesso Wi-Fi è esso stesso un controllo d’identità verso un server RADIUS, e il client può presentare un’identità di instradamento mentre l’account reale viaggia dentro lo scambio cifrato. Anche allora il controllo riguarda l’adesione alla rete; non autorizza il tunnel, e il gateway VPN non lo accetta come prova di nulla.
L’ordine conta più delle etichette. I portali captive esistono perché l’accesso può essere concesso dopo l’associazione, ed è per questo che un locale può affidare la pagina a un fornitore specializzato. Il RFC 8952 dell’IETF considera il portale una componente a sé, quindi un dominio sconosciuto è un motivo per verificare, non una prova di frode di per sé. Confrontate il dominio con le istruzioni scritte del locale e i campi con la tabella.
Verificate cosa può chiedere un portale
I campi del portale riguardano il diritto d’accesso, non l’identità: numero di camera, cognome della prenotazione, codice del buono, il codice stampato sulla custodia della chiave, un’email per un permesso temporaneo, l’accettazione dei termini. Il locale sa già chi ha prenotato la camera, quindi può incrociare quei dati senza apprendere nulla che gli permetterebbe di agire come voi altrove.
Qualunque cosa oltre quell’elenco merita una pausa. Una pagina di hotspot non può verificare la vostra password di dominio, e non può verificare nemmeno il vostro codice monouso del VPN, un codice di recupero o una chiave privata, e non ha motivo di volerli. L’unica eccezione legittima è una rete gestita da un’organizzazione: un SSID ospiti d’ufficio o un Wi-Fi di conferenza possono indirizzarvi al provider d’identità che già usate per il lavoro. Resta distinguibile: l’host di accesso è quello quotidiano, la schermata di consenso nomina il vostro tenant e il flusso si apre in una scheda visibile del browser.
L’email di marketing è a parte: un alias di viaggio soddisfa il campo senza consegnare la vostra identità lavorativa.
Verificate che il client VPN voglia le proprie credenziali
Il client chiede esattamente ciò per cui è configurato il suo profilo, quindi la finestra attesa è una proprietà del profilo e non della rete su cui vi trovate. I profili con certificato di solito mostrano una scelta di profilo e poi si connettono in silenzio. I profili nome utente e password chiedono entrambi, spesso con un codice monouso. I profili SSO aprono il browser verso il provider d’identità e tornano con un token. WireGuard è ancora diverso: autentica i dispositivi con chiave pubblica e non ha un accesso utente, quindi una finestra che offre nome utente e password di WireGuard non descrive WireGuard.
Leggete il profilo prima di partire. In OpenVPN, auth-user-pass vi dice che è attesa una richiesta di password, mentre cert, key o pkcs12 significa che dovrebbe essere un certificato a fare il lavoro. Se un profilo che di solito si connette senza richiesta chiede improvvisamente una password, sospettate un profilo che non è riuscito a caricare il certificato o è ripiegato su un altro metodo. Una richiesta non è un invito a digitare la password di lavoro in qualunque finestra compaia.
Nessun client VPN legittimo chiede il numero di camera, il buono del portale o la passphrase del Wi-Fi come input di autenticazione. Quando accade, o il client non è ciò che dichiara di essere, o un portale captive intercetta il traffico prima che si formi il tunnel e state leggendo una pagina HTML impostata come un accesso.
Fermatevi a queste cinque condizioni
Questi sono i punti in cui mi fermo invece di proseguire con un aggiramento plausibile. Ognuno costa poco da controllare e molto da sbagliare.
- Compare un avviso di certificato o TLS sul portale o sulla pagina SSO. Non superatelo cliccando per raggiungere la rete.
- La pagina chiede un segreto che solo il gateway VPN o il provider d'identità possono verificare: password di dominio, codice monouso, codice di recupero, chiave privata.
- Il dominio non corrisponde alle istruzioni stampate del locale né all'host di accesso che la vostra organizzazione documenta per i propri servizi.
- Vi chiedono di installare un certificato radice, un profilo di configurazione o un'applicazione ausiliaria che non proviene dalla gestione dei vostri dispositivi.
- Arriva un'approvazione MFA che non avete avviato, o il client VPN chiede credenziali dell'hotel.
L’alternativa non è un’altra password. Usate un hotspot del telefono, chiedete alla reception il nome esatto della rete e il metodo di accesso, e segnalate la pagina a chi gestisce la rete o al vostro servizio IT. Nulla di tutto ciò richiede di provare una credenziale contro una pagina che non potete attribuire.
Attribuite un guasto allo stadio giusto
Una volta superati entrambi gli stadi, i guasti capitano ancora, e l’errore di solito nomina lo stadio se lo si legge in ordine: associazione, assegnazione dell’indirizzo, autorizzazione del portale, instaurazione del tunnel, poi la risorsa interna. Cambiare una password VPN perché un codice del portale è scaduto fa perdere tempo e lascia il problema reale al suo posto.
Poche prove separano gli stadi. Dopo l’accesso al portale, richiedete una normale pagina HTTPS pubblica. Se invece torna il portale, l’autorizzazione non si è mai completata a quel livello. Se il client VPN segnala che non raggiunge il gateway, il problema sta sotto il tunnel: la sessione del portale, la risoluzione dei nomi o una rete che blocca la porta. Se il tunnel sale e un nome host interno fallisce, la risoluzione dei nomi o la policy dentro la rete privata è il sospetto migliore.
Anche le sessioni del portale scadono indipendentemente dal tunnel. Quando il locale revoca l’accesso, una connessione VPN stabilita cade anche se le sue credenziali non sono mai state sbagliate. Riautorizzate il portale, poi riconnettete il VPN e lasciate che rinegozi. Ruotare la password VPN a quel punto non risolve nulla e può bloccarvi fuori.
Date ogni segreto solo al sistema che può verificarlo, e trattate una richiesta che non corrisponde alla tabella come un segnale di stop e non come un passo da aggirare. Se entrambi gli stadi passano e il tunnel rifiuta ancora, catturate l’errore esatto del client prima di cambiare qualsiasi credenziale.