VPN bloccata su Connecting in modalità aereo: trovate il collegamento ascendente
Un client che resta su Connecting in modalità aereo forse non ha semplicemente alcun collegamento ascendente. Separate lo stato della radio, l’associazione, l’accesso al portale e la policy di blocco.
Il telefono mostra l’icona dell’aereo, il client VPN è su Connecting da due minuti e il profilo è corretto. Un’ora fa funzionava nello stesso edificio. Niente è rotto: una VPN è una connessione trasportata da un’altra rete, e la modalità aereo ha appena rimosso la rete che la trasportava. Il client continua a riprovare perché è quello che fa senza un collegamento ascendente.
La confusione nasce dal fatto che il simbolo dell’aereo non dice se il Wi-Fi è disponibile, e Connecting non dice se il client si sta autenticando o sta solo aspettando. Separate queste due letture e la diagnosi richiede un minuto.
Il simbolo dell’aereo non è un rapporto radio
Sui dispositivi Android supportati, Wi-Fi e Bluetooth possono restare attivi in modalità aereo, e il dispositivo ricorda la scelta fatta l’ultima volta. La guida di Google sulla modalità aereo su Pixel descrive esattamente questo comportamento. Quindi l’icona può significare che il cellulare è spento e nient’altro.
Controllate lo stato reale invece del glifo. adb shell settings get global airplane_mode_on restituisce 0 o 1 per la modalità stessa, e adb shell dumpsys connectivity elenca le reti che il dispositivo ha in questo momento, con il loro stato di convalida. Questi due output insieme rispondono alla domanda a cui l’icona non può.
Se il Wi-Fi è spento, o acceso ma non associato a nulla, non esiste un percorso verso l’endpoint VPN e nessuna quantità di riconnessioni ne creerà uno. È il caso che vale la pena escludere per primo, perché è l’unico in cui la correzione giusta sta fuori dall’app VPN.
Che cosa significa davvero Connecting
Un client può conservare un profilo salvato, mostrarne il nome e far girare un indicatore senza aver contattato nulla. La configurazione è locale. Stabilire un tunnel richiede un server raggiungibile, un handshake completato e un’interfaccia su cui instradare. Solo quest’ultima parte ha bisogno di una rete funzionante, ed è per questo che le prime due possono sembrare riuscite con la radio spenta.
Quindi l’indicatore è compatibile con almeno tre situazioni diverse: nessun collegamento ascendente, un collegamento ascendente che non raggiunge l’endpoint e un collegamento ascendente che lo raggiunge ma fallisce l’autenticazione. Sullo schermo sembrano identici e in un log sono completamente diversi. Per questo il primo artefatto utile in tutti questi casi è il log, non un altro tentativo.
La documentazione VPN di Android traccia la stessa linea tra la creazione della connessione e le policy separate di sempre attivo e di blocco. È questa separazione a spiegare perché un telefono possa sembrare protetto mentre è offline e comunque non avere alcun tunnel.
Quattro stati che vale la pena distinguere
I quattro stati qui sotto sono quelli che vale la pena nominare, perché lo schermo li mostra in modo identico.
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
La terza riga coglie la maggior parte delle persone in hotel e aeroporti. L’associazione non è ammissione: un portale che non ha lasciato passare il telefono accetterà volentieri la password del Wi-Fi e poi rifiuterà di far passare traffico verso l’endpoint VPN. Accedere prima dal browser, con il tunnel spento, è di solito l’unico modo per passare.
Perché il blocco lo fa sembrare peggio
Se la VPN sempre attiva e il blocco delle connessioni senza VPN sono entrambi attivi, ogni app coperta viene bloccata ogni volta che il tunnel non è attivo. È la funzione che lavora, non un secondo guasto. Il sintomo passa da un’app che fallisce a tutto che fallisce, il che si legge come un problema molto più grande.
Spiega anche la sequenza che le persone leggono male: modalità aereo attiva, nessun collegamento ascendente, app bloccate, la VPN dice connecting. Il blocco era la policy che faceva il suo lavoro. Disattivare la policy per testare il collegamento ascendente toglie la protezione che probabilmente volevate e non vi insegna nulla.
Controllate invece l’ambito. Quali app sono coperte, quali escluse e se il profilo è per utente o per l’intero dispositivo. Un’attività che avvia l’app VPN appena compare il Wi-Fi è un trigger, non una garanzia che nessun pacchetto sia uscito prima che partisse.
Un ordine diagnostico che chiude le supposizioni
Lavorate dal basso verso l’alto. Confermate la modalità, confermate che esista una rete, che sia convalidata, che possa raggiungere qualcosa fuori dalla sottorete locale, e solo allora guardate il client. adb shell ping -c 3 1.1.1.1 è un test grossolano, ma separa un percorso mancante da un percorso che esiste mentre il tunnel è scontento.
Se il ping fallisce mentre una rete è elencata, il problema è a monte della VPN e nessuna impostazione del client lo risolverà. Se il ping riesce e il tunnel ancora non si stabilisce, catturate il log del client in quel momento: l’errore distinguerà un timeout da un rifiuto di autenticazione, e questi due non hanno nulla in comune.
Chiudete ripristinando lo stato desiderato: Wi-Fi consentito in modalità aereo se è la vostra configurazione abituale, il portale completato e la policy di blocco di nuovo attiva. Poi riconnettetevi una volta e confermate che il tunnel salga da solo, perché una configurazione che funziona solo dopo tentativi manuali fallirà di nuovo al prossimo avvio.