Perché il portale captive blocca la tua VPN e come accedere di nuovo

Su una rete aperta il tuo punto di accesso non consegna semplicemente i pacchetti a internet. Un punto di policy a monte controlla se il tuo dispositivo è già autorizzato, e finché non lo è, quasi tutto viene scartato. Il tuo client VPN legge quel silenzio come un server morto. Lo dice raramente: WireGuard ripete una stretta di mano nel vuoto, OpenVPN segnala un timeout di connessione e IKEv2 torna con l'errore 809 su un server remoto che non risponde.

Cosa controlla davvero il portale

Un portale captive è due cose incollate insieme: un punto di decisione della policy e un reindirizzatore. Quando il tuo dispositivo si associa e prende un lease DHCP, la rete ti mette in uno stato pre-autorizzazione.

Quello stato è un insieme di regole del firewall. Di solito consente DNS e consente HTTP o HTTPS verso una breve lista di host del portale, e scarta tutto il resto. La lista consentita è il giardino recintato, e quasi mai include un endpoint VPN.

Nessuno di questi scarti è gentile. I pacchetti diretti a un server VPN vengono scartati invece che rifiutati, così il client non riceve né ICMP unreachable né TCP reset, solo l'assenza di risposta. A seconda del fornitore, il reindirizzatore può rispondere sulla porta 80 con un reindirizzamento alla pagina di accesso mentre la porta 443 viene scartata o intercettata. I reindirizzamenti sono facili da notare perché trasportano una risposta HTTP semplice; l'intercettazione sulla 443 richiede un certificato di cui il tuo browser si rifiuterà di fidarsi.

L'autorizzazione stessa è di solito legata all'indirizzo MAC del dispositivo, a volte all'IP concesso in lease, e vive in una tabella delle sessioni con un timer. L'accesso crea una voce. La regola del firewall che lascia passare il tuo traffico esiste solo finché esiste quella voce, ed è per questo che l'intero problema torna più tardi senza che nulla cambi dalla tua parte.

Perché la stretta di mano della VPN muore prima di iniziare

Ogni protocollo ha il proprio trasporto, e il firewall pre-autorizzazione rompe ciascuno in modo diverso. IKEv2 su Windows e iOS viaggia su UDP 500 e UDP 4500; uno scarto su quelle porte si manifesta come 809, o come un guasto in stile risoluzione dei nomi sui client che riportano le fasi separatamente. OpenVPN su UDP 1194 resta nello stato di connessione finché non scade il suo timeout. OpenVPN su TCP 443 è il caso interessante, perché il portale può completare la stretta di mano TCP e poi rispondere con la sua pagina di reindirizzamento, così vedi un errore TLS invece di un timeout.

WireGuard mostra il meccanismo nel modo più chiaro. È solo UDP per progetto, senza fallback TCP, quindi un firewall che scarta l'UDP sconosciuto elimina del tutto il trasporto. Il client continua a inviare inizi di stretta di mano con un backoff crescente e segnala una stretta di mano che non si completa mai. Nulla in quel messaggio menziona il Wi-Fi, e nulla suggerisce che dovresti aprire un browser.

Le piattaforme cercano di notare lo stato prima della tua VPN. Windows recupera un URL noto per decidere se mostrare la notifica di accesso, Android richiede un endpoint che dovrebbe rispondere 204 No Content, e i dispositivi Apple aprono una piccola finestra di rete captive. Quelle sonde funzionano perché il portale risponde con un reindirizzamento invece del corpo atteso. Lo stesso comportamento spiega come un portale possa sembrare perfettamente sano mentre il tuo tunnel è morto: la sonda e il tunnel vengono giudicati con regole diverse.

Cosa azzera davvero una scadenza di sessione

I locali fanno scadere le sessioni per motivi estranei al tuo account VPN: un timeout di inattività, una durata massima di sessione, un nuovo lease DHCP o una riassociazione a un altro punto di accesso. Quando il timer scatta, la voce della tabella delle sessioni sparisce e l'insieme di regole pre-autorizzazione torna esattamente com'era al check-in.

Un tunnel stabilito spesso sopravvive abbastanza a lungo da sembrare sano. I messaggi di keepalive continuano a uscire, e se il client se ne accorge dipende da come tratta il traffico senza risposta, quindi la spia di stato può restare verde per un po' dopo che il percorso è sparito. Poi il tunnel cade e ogni tentativo di riconnessione fallisce sulle stesse porte bloccate.

A quel punto l'errore del client ti dice a che fase sei, se lo leggi con attenzione:

Un dettaglio inganna le persone: quando la sessione è legata a un indirizzo MAC, ricaricare la pagina di accesso potrebbe non aiutare. Devi lasciare l'associazione e unirti di nuovo, così il portale vede un nuovo tentativo di autorizzazione invece di uno scaduto.

Prima accedi, poi alza il tunnel

L'ordine che funziona è: autorizza il dispositivo, dimostra il percorso, avvia la VPN, dimostra il tunnel, poi ripristina il tuo blocco abituale. Quell'ultimo passaggio conta perché lo stato temporaneo che ti serve per raggiungere il portale è esattamente lo stato che un kill switch esiste per impedire.

Un client desktop con l'opzione di bloccare fuori dal tunnel deve essere messo in pausa perché la pagina del portale si carichi, e dovresti tenere chiuse le applicazioni sensibili durante quella finestra fuori dal tunnel; è l'unico intervallo in cui il traffico locale esce senza protezione. Un dispositivo gestito sempre attivo dovrebbe usare la procedura pubblicata dal suo proprietario invece che rimuovere tu la policy. Se il portale mostra un avviso di certificato, fermati: accettarlo instrada la tua sessione attraverso il proxy di intercettazione del locale, e quel proxy può leggere tutto ciò che invii. Su Android il blocco con VPN sempre attiva blocca il traffico prima che il tunnel sia alzato, e alcune build non riescono a esentare il flusso del portale; se la tua non può, usa l'accesso alternativo del locale o un altro dispositivo invece di lasciare il blocco disattivato. Le regole Apple on-demand possono essere scritte per rifiutare il tunnel finché una sonda non riesce, ed è il comportamento che vuoi sulle reti alberghiere.

Verifica in ordine con gli strumenti che hai già. Prima del tunnel, esegui la sonda con intestazioni e corpo entrambi visibili, e osserva se il tuo trasporto VPN riceve qualche risposta:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Prima dell'autorizzazione, un portale normale dà una di due risposte: un 302 il cui Location punta alla pagina di accesso, oppure un 200 con un corpo HTML che è la pagina del portale. Annota quale hai ricevuto. Un reindirizzamento non è un guasto prima dell'accesso; è il portale che ti dice dove andare. Dopo che il portale segnala il successo, ripeti il comando e attenditi un 200 il cui corpo sia la parola letterale Success. È quella stringa a rendere significativa la sonda. Se l'host risponde normalmente prima che tu abbia mai effettuato l'accesso, su questa rete non c'è alcun portale di intercettazione. Nella cattura, uno scarto pre-autorizzazione è costituito da pacchetti in uscita da cui non torna nulla, mentre un percorso che funziona mostra una risposta allo stesso flusso entro circa un secondo. Connettiti, poi ripeti la cattura.

Se il tunnel continua a fallire dopo che il portale dice sì

Il successo dell'accesso non è la stessa cosa di un trasporto consentito. Molti locali consentono il portale e la navigazione ordinaria bloccando del tutto l'UDP, il che lascia WireGuard e OpenVPN su UDP rotti e TCP 443 funzionante. Se TCP 443 passa e UDP no, è la policy del locale e non un client che hai configurato male, quindi cambia trasporto o accetta il limite e vai avanti. Se una riconnessione fallisce ancora dopo, conserva l'errore esatto; nomina la fase in cui sei bloccato.

Altri guasti vivono nel dispositivo. Una sessione ancora legata a un vecchio MAC, un secondo adattatore Wi-Fi con il proprio lease, o un client che ha memorizzato l'eccezione di certificato del portale possono ciascuno continuare a fallire dopo una riautorizzazione pulita. Lascia l'associazione, riautorizza e riprova una volta prima di toccare le impostazioni del client. RFC 8952 vale la lettura se vuoi l'architettura dietro i componenti che stai osservando.

Se il portale stesso rifiuta di autorizzare, il problema è nell'account o nell'assegnazione del dispositivo e nessuna impostazione VPN lo risolverà. Cambiare il paese di uscita della VPN non azzera lo stato di accesso locale del locale; quella tabella è legata al tuo dispositivo, non al server che scegli. Chiedi al gestore del locale e dagli tempo, perché la tabella delle sessioni è ciò che guarderà.

Prima del tuo prossimo viaggio, annota tre cose: la pagina del portale come passo zero, il passo di pausa del blocco per ogni dispositivo che porti, e un trasporto di riserva che hai davvero provato. Quando un tunnel che funzionava dieci minuti fa si ferma di nuovo, trattalo come un'autorizzazione scaduta e ricontrolla il portale prima di toccare il profilo VPN.