Perché un profilo OpenVPN funziona a casa ma fallisce in hotel

Il Wi-Fi dell'ufficio e una camera d'albergo possono dare allo stesso portatile due reti molto diverse, e il profilo in mezzo non ne sa nulla. Ciò che funziona a casa presuppone un collegamento in uscita permissivo, una risoluzione dei nomi funzionante e una sottorete locale che non entri in collisione con nulla di ciò che trasporta il tunnel. Ognuno di questi presupposti può fallire separatamente.

Il modo utile di fare debug è trattare la rete come quattro fatti separati, poi verificarli in ordine. Indovinare il profilo per primo di solito produce una modifica che non risolve nulla e oscura le prove.

Quattro fatti di rete cambiano da un luogo all'altro

Il primo fatto è se la rete locale ti fa uscire del tutto. Un portale captivo ammette un dispositivo a una pagina di accesso e blocca tutto il resto finché quella pagina non è completata, il che significa che il tunnel non può partire, per quanto il profilo sia corretto.

Il secondo è la risoluzione dei nomi. Un portale che intercetta il DNS risponde a ogni richiesta con il proprio indirizzo, così il nome host della VPN si risolve nel portale e il client tenta di costruire un tunnel verso una pagina web.

Il terzo è il filtraggio del trasporto. Le reti che vogliono consentire solo la navigazione lasciano passare TCP 443 verso destinazioni arbitrarie e scartano quasi tutto il resto, incluso UDP.

Il quarto è l'indirizzamento. La sottorete locale può sovrapporsi a una rete dietro il tunnel, oppure il collegamento in uscita può non offrire alcun percorso IPv4 utilizzabile.

Risoluzione dei nomi e portale captivo

Sostituisci il nome host nel profilo con l'indirizzo numerico del server e riprova. Se l'IP si connette e il nome no, la colpa è della risoluzione, e il profilo stesso va bene.

Apri un browser e prova una normale pagina HTTP prima di toccare la VPN. Un reindirizzamento a una pagina di accesso significa che il portale è ancora in sospeso; completalo, poi riconnettiti. Molti hotel fanno anche scadere la sessione dopo qualche ora, il che sembra una disconnessione a metà giornata più che un problema di accesso.

Se anche l'indirizzo numerico fallisce, la risoluzione non è la spiegazione, quindi passa al trasporto. Conserva l'indirizzo che hai provato, perché dice al controllo successivo se i pacchetti hanno lasciato la macchina.

Filtraggio del trasporto: prima UDP, TCP 443 come ripiego

Un flusso OpenVPN su UDP 1194 non assomiglia a nulla che un firewall d'albergo riconosca, quindi viene scartato senza errore. Il client riprova finché il suo timeout scade, e l'utente vede una connessione che non si stabilisce mai invece di un rifiuto. I firewall che si comportano così raramente registrano lo scarto in un posto visibile. L'assenza di un rifiuto è essa stessa l'indizio.

TCP 443 è il ripiego affidabile perché la rete non può distinguerlo da un normale HTTPS. Usa il profilo TCP dell'operatore quando esiste, dato che anche il server deve ascoltare su quel trasporto e quella porta; cambiare solo il client produce un altro tipo di guasto. Se non esiste alcun profilo TCP, chiedi all'operatore invece di inventarne uno modificando la porta. Il lato server deve essere d'accordo, e una discrepanza sembra di nuovo un problema di firewall.

Aspettati un costo in prestazioni. TCP dentro TCP amplifica le ritrasmissioni su un collegamento con perdite, quindi un tunnel TCP che funziona può comunque sembrare lento su una rete d'albergo congestionata. È uno scambio per la raggiungibilità, non un difetto da inseguire.

Collisioni di indirizzi e collegamenti senza IPv4

Un tunnel può stabilirsi e non trasportare nulla. Quando la LAN locale e una rete remota condividono un prefisso come 192.168.1.0/24, il client considera l'host remoto direttamente connesso e invia il pacchetto al collegamento locale invece che al tunnel. Il sintomo è una connessione riuscita con una sottorete irraggiungibile, che è facile leggere male come un problema di rotta lato server.

La correzione permanente è spostare la LAN remota su un intervallo privato poco comune. Scegliere un intervallo che nessuno usa a casa, come 10.42.0.0/24, previene il problema per ogni luogo futuro invece che per uno solo. Il raggiro locale è evitare quell'hotel, hotspot o router, il che non è affatto una correzione.

I collegamenti mobili aggiungono due varianti. Il NAT di livello operatore significa che le connessioni in entrata non arrivano, cosa che conta se ospiti un server ma non per un client in uscita. Un APN configurato solo IPv6 con traduzione NAT64 può far fallire un client che esige un percorso IPv4 reale, e il rimedio abituale è cambiare il protocollo dell'APN in IPv4 o doppio stack.

Sintomi dopo che il tunnel è attivo

Un tunnel che si connette e poi tace è di solito un problema di keepalive o MTU, non una porta bloccata. Una connessione che cade dopo un numero fisso di minuti indica un timer di keepalive o di rinegoziazione. Configura il client per sondare il suo pari e riavviarsi quando le risposte si fermano, e prova un MTU del tunnel più piccolo se i ping passano mentre i trasferimenti grandi si bloccano.

Prima di chiedere aiuto, annota tre cose: l'indirizzo provato e se ha risposto, il trasporto e la porta usati, e la sottorete locale della rete che ha fallito. Insieme separano la risoluzione dei nomi dal filtraggio del trasporto e da una collisione di indirizzi, che sono le cause che sopravvivono al contatto con le prove.