VPN encallat a Connecting en mode avió: trobeu l’enllaç ascendent
Un client que es queda a Connecting en mode avió potser simplement no té cap enllaç ascendent. Separeu l’estat de la ràdio, l’associació, l’inici de sessió al portal i la política de bloqueig.
El telèfon mostra la icona d’avió, el client VPN fa dos minuts que és a Connecting i el perfil és correcte. Fa una hora funcionava al mateix edifici. No hi ha res trencat: una VPN és una connexió que transporta una altra xarxa, i el mode avió acaba de treure la xarxa que la transportava. El client continua reintentant perquè és el que fa sense cap enllaç ascendent.
El que ho fa confús és que el símbol d’avió no diu si el Wi-Fi està disponible, i Connecting no diu si el client s’autentica o només espera. Separeu aquestes dues lectures i el diagnòstic triga un minut.
El símbol d’avió no és un informe de ràdio
En dispositius Android compatibles, el Wi-Fi i el Bluetooth poden quedar activats en mode avió, i el dispositiu recorda l’elecció que vau fer l’última vegada. La guia de Google sobre el mode avió al Pixel descriu exactament aquest comportament. Per tant, la icona pot significar que el mòbil està desactivat i res més.
Comproveu l’estat real i no el glif. adb shell settings get global airplane_mode_on retorna 0 o 1 per al propi mode, i adb shell dumpsys connectivity llista les xarxes que el dispositiu té ara mateix, amb el seu estat de validació. Aquestes dues sortides juntes responen la pregunta que la icona no pot.
Si el Wi-Fi està desactivat, o activat però sense associar a res, no hi ha cap camí fins al punt final de la VPN i cap quantitat de reconnexió no en crearà cap. Aquest és el cas que val la pena descartar primer, perquè és l’únic on la solució correcta queda fora de l’aplicació VPN.
Què significa realment Connecting
Un client pot mantenir un perfil desat, mostrar-ne el nom i ensenyar un indicador giratori sense haver contactat amb res. La configuració és local. Establir un túnel requereix un servidor accessible, una encaixada de mans completada i una interfície per on encaminar. Només aquesta última part necessita una xarxa que funcioni, i per això les dues primeres poden semblar correctes amb la ràdio apagada.
Així, l’indicador és compatible amb almenys tres situacions diferents: cap enllaç ascendent, un enllaç ascendent que no pot arribar al punt final i un enllaç ascendent que hi arriba però falla l’autenticació. A la pantalla es veuen idèntics i al registre són completament diferents. Per això el primer artefacte útil en qualsevol d’aquests casos és el registre, no un altre reintent.
La pròpia documentació de VPN d’Android traça la mateixa línia entre l’establiment de la connexió i les polítiques separades de sempre actiu i de bloqueig. Aquesta separació és la raó per la qual un telèfon pot semblar protegit mentre és fora de línia i tot i així no tenir túnel.
Quatre estats que val la pena distingir
Els quatre estats següents són els que val la pena anomenar, perquè la pantalla els mostra de manera idèntica.
| 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 tercera fila enganxa la majoria de la gent en hotels i aeroports. L’associació no és admissió: un portal que no ha deixat passar el telèfon acceptarà de bon grat la contrasenya del Wi-Fi i després es negarà a passar trànsit cap al punt final de la VPN. Iniciar sessió primer pel navegador, amb el túnel desactivat, sol ser l’única manera de passar.
Per què el bloqueig ho fa semblar pitjor
Si la VPN sempre activa i el bloqueig de connexions sense VPN estan tots dos activats, cada aplicació coberta queda bloquejada sempre que el túnel no estigui aixecat. Això és la funció funcionant, no una segona avaria. El símptoma passa de fallar una aplicació a fallar-ho tot, cosa que es llegeix com un problema molt més gran.
També explica la seqüència que la gent llegeix malament: mode avió activat, sense enllaç ascendent, aplicacions bloquejades, la VPN diu connecting. El bloqueig era la política fent la seva feina. Desactivar la política per provar l’enllaç ascendent elimina la protecció que presumiblement volíeu i no us ensenya res.
Comproveu l’abast en lloc d’això. Quines aplicacions estan cobertes, quines excloses i si el perfil és per usuari o per dispositiu. Una tasca que inicia l’aplicació VPN quan apareix el Wi-Fi és un disparador, no una garantia que cap paquet hagi sortit abans que s’executés.
Un ordre de diagnòstic que acaba amb les conjectures
Treballeu de baix a dalt. Confirmeu el mode, confirmeu que hi ha una xarxa, confirmeu que està validada, confirmeu que pot arribar a alguna cosa fora de la subxarxa local i només llavors mireu el client. adb shell ping -c 3 1.1.1.1 és una prova grollera, però separa un camí que falta d’un camí que existeix mentre el túnel no està content.
Si el ping falla mentre hi ha una xarxa llistada, el problema és per sobre de la VPN i cap paràmetre del client ho arreglarà. Si el ping funciona i el túnel encara no s’estableix, captureu el registre del client en aquell moment: l’error distingirà un temps d’espera d’un rebuig d’autenticació, i aquests dos no tenen res en comú.
Acabeu restaurant l’estat desitjat: Wi-Fi permès en mode avió si aquesta és la vostra configuració habitual, el portal completat i la política de bloqueig tornada a activar. Després reconnecteu un cop i confirmeu que el túnel puja sol, perquè una configuració que només funciona després de reintents manuals tornarà a fallar a la propera arrencada.