La VPN funziona in Wi-Fi ma non in dati mobili: perché

Iniziate con un confronto, non con una conclusione: stesso telefono, stesso profilo, due reti. Se il tunnel fallisce su una e funziona sull’altra, la differenza è da qualche parte nel percorso e non nelle credenziali. Annotate che tipo di errore ottenete, perché un rifiuto prima dell’accesso e una connessione che non trasporta nulla sono problemi diversi. Tutto quanto segue presuppone quel test, eseguito cambiando solo la rete.

Una VPN ha bisogno della connessione sottostante; non la sostituisce e non può costringere un operatore a trasportare ciò che l’operatore rifiuta di trasportare.

Tenete fermo il telefono e cambiate solo la rete

Cambiare rete e server nello stesso momento lascia due cause possibili e nessun modo di separarle. Confrontate lo stesso endpoint prima in Wi-Fi e poi in dati mobili, e annotate ogni volta il sintomo esatto. Un errore prima dell’autenticazione indica raggiungibilità, un rifiuto delle credenziali indica l’account, e un tunnel connesso che non trasporta nulla indica routing o DNS. Solo il primo riguarda davvero la rete.

Un rifiuto esplicito all’accesso rientra anch’esso nei controlli di autenticazione, anche se compare su una sola rete. Alcuni operatori e reti per gli ospiti intercettano il traffico in modi che producono errori fuorvianti.

Che cosa può vedere e addebitare la rete di accesso

L’operatore che trasporta il tunnel osserva la connessione stessa: il momento, il volume e l’indirizzo dell’endpoint VPN. Cifrare il payload non nasconde queste proprietà, e vale su un collegamento Wi-Fi domestico come sui dati mobili. Ciò che una VPN cambia è chi può vedere cosa, e la risposta è diversa a ogni salto. Annotatelo salto per salto invece di descrivere la connessione come privata in generale.

Gli addebiti sono l’altra differenza pratica. L’incapsulamento, i segnali di mantenimento e i nuovi tentativi consumano byte, e le applicazioni possono riprendere un trasferimento dopo un passaggio. Esiste anche il Wi-Fi domestico a consumo, quindi controllate i contatori del dispositivo e il piano invece di dare per scontato che una delle due reti sia illimitata.

Accessi al portale e restrizioni dell’operatore

Un portale captive deve essere soddisfatto prima che il tunnel possa raggiungere qualcosa. Riconnettere la VPN non ammetterà un dispositivo che la rete non ha autorizzato, e una politica sempre attiva può rendere il portale irraggiungibile. Completate prima l’accesso con il normale flusso del browser, poi alzate il tunnel. Se una politica gestita impedisce quest’ordine, seguite la procedura documentata dell’operatore o dell’amministratore.

Le restrizioni dell’operatore sono l’altra variabile: alcuni percorsi trasportano solo certi protocolli, altri traducono gli indirizzi in modo aggressivo e altri trattano una famiglia di indirizzi diversamente dall’altra. Il confronto riduce il guasto al percorso senza identificare quale meccanismo ne sia responsabile.

Il passaggio non è la stessa cosa di una riconnessione

Una volta che ogni rete funziona da sola, osservate un passaggio reale. Il client può rilevare il cambiamento e riconnettersi, oppure mantenere una sessione ormai morta. Le applicazioni già in uso si riprendono diversamente da quelle aperte dopo il cambio, quindi un’icona del tunnel persistente dimostra poco. Provate l’applicazione che vi interessa davvero durante la transizione e annotate se si riprende senza intervento manuale.

Se il tunnel fallisce solo dopo un periodo di inattività, un segnale di mantenimento può gestire un caso di stato NAT. Non ripara un segnale debole e non risolve ogni passaggio. Distinguete l’inattività dal movimento prima di cambiare impostazioni.

Annotate la rete, la fase del guasto e il comportamento durante un passaggio. Questi tre separano un problema di percorso da un problema di client.