Wi-Fi dell'hotel: la VPN fallisce prima di raggiungere il server

Il client VPN gira, poi segnala che non riesce a raggiungere il server, e tutti concludono che l'hotel blocca le VPN. Di solito non è successo nulla di così drammatico: la rete non ti ha ancora lasciato uscire. Un portale captive trattiene ogni connessione finché non accedi, e un tunnel non può completarsi mentre una pagina di accesso intercetta i suoi pacchetti. Completa l'accesso prima di dare la colpa al tunnel.

Il mito: l'hotel blocca le VPN

La maggior parte delle reti alberghiere non filtra i tunnel in modo specifico. Intercetta il traffico web finché l'ospite non si autentica, e può anche limitare i dispositivi, far scadere le sessioni o ridurre la velocità. Ognuno di questi casi produce un guasto che dall'interno di un client VPN sembra un blocco.

Il tunnel qui è una cattiva diagnostica, perché è l'unica applicazione che fallisce di sicuro finché il portale non è autenticato. L'accesso web normale è l'indicatore migliore, perché può mostrarti la pagina di accesso stessa.

Quest'ordine conta anche per un altro motivo: un client con kill switch o modalità sempre attiva rifiuterà di caricare il portale, e l'utente concluderà che la rete è guasta, non l'impostazione. Entrambi i fatti sono veri insieme, e solo uno può essere cambiato in hotel. Disattiva la protezione dal controllo del client, accedi e riattivala. Qualsiasi altra cosa è un aggiramento che nasconde la sequenza reale.

Completa prima il portale, poi prova l'HTTPS normale

Chiedi al personale il nome ufficiale della rete e il metodo di accesso. Un SSID convincente non è prova di proprietà, e una seconda rete con nome simile è un trucco comune nei luoghi pubblici. Usa la richiesta di accesso del sistema operativo dove disponibile, o la pagina documentata dell'hotel.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

La prima richiesta interroga un endpoint noto di rilevamento portale captive su HTTP semplice; un reindirizzamento o un corpo inatteso significa che sei ancora dietro al portale. La seconda prova un normale sito HTTPS. Se la prima mostra intercettazione e la seconda fallisce, l'accesso è incompleto e la VPN non c'entra.

Su un dispositivo personale può essere necessario disattivare il kill switch o la VPN sempre attiva tramite il controllo supportato del client perché il portale possa caricarsi. Chiudi le applicazioni sensibili in quella finestra e riattiva subito dopo la protezione. Su un dispositivo gestito, segui la procedura approvata dall'amministratore invece di rimuovere tu una policy.

Non aggirare mai un avviso di certificato e non installare certificati sconosciuti o applicazioni ausiliarie per andare online. Se il portale chiede qualcosa di inatteso, confermalo con il personale, e con l'amministratore se il dispositivo è di un datore di lavoro.

Conserva il profilo originale e il suo errore

Quando l'accesso normale funziona, collega il profilo originale e annota l'errore esatto. Un rifiuto di autenticazione è un problema di account, un timeout durante la negoziazione è un problema di percorso, e un tunnel che si stabilisce ma non trasporta nulla è un problema di routing o di policy.

Questi tre richiedono passi successivi diversi, e uno screenshot dell'errore vale più di una descrizione. Annota anche l'ora, perché i limiti di sessione dell'hotel possono scadere entro un'ora e produrre un guasto che sembra casuale. Se il client offre un log, conserva la sezione attorno al primo guasto e non l'intero file. Quell'estratto di solito basta a chi possiede il profilo per identificare la fase.

Se l'accesso normale funziona e la negoziazione scade ancora, chiedi all'hotel se supporta quel traffico, e confronta con un hotspot affidabile tenendo dispositivo e profilo costanti. Lavorare sull'hotspot restringe l'attenzione al percorso dell'hotel senza dimostrare nulla sul profilo.

Usa solo le alternative fornite dall'operatore

Un profilo TCP corrispondente può riuscire dove il percorso UDP offerto non funziona, ma solo se il server ascolta davvero su quel trasporto e quella porta. La porta TCP 443 non è trattata automaticamente come HTTPS normale, e non è garanzia di passaggio attraverso una rete restrittiva.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Eseguire il profilo fornito con maggiore verbosità mantiene visibile il primo errore utile invece di comprimerlo in una finestra di guasto generica. Usa il file fornito dall'operatore invece di modificare tu porte o protocolli, perché una modifica locale non può creare un listener corrispondente dall'altra parte.

Se il tunnel si reimposta ripetutamente, annota se il portale riappare o se il segnale locale cala, e segui i controlli di stabilità invece di cambiare più protocolli insieme. Poi prova l'applicazione che ti serve davvero e ripristina i normali controlli di privacy. Una connessione che trasporta un sito ma non un altro è una questione di routing o di policy, non di portale.

Infine, verifica il recupero dopo la sospensione del portatile. L'autorizzazione del portale può scadere indipendentemente dal tunnel, quindi un dispositivo che si riconnette da solo può tornare su una rete che lo ha già dimenticato. Riaprire la pagina del portale è un passo normale, non un segno che la VPN sia guasta.