VPN atascada en Connecting en modo avión: atope o enlace ascendente
Un cliente que queda en Connecting en modo avión pode simplemente non ter enlace ascendente. Separe o estado da radio, a asociación, o inicio de sesión no portal e a política de bloqueo.
O teléfono mostra a icona do avión, o cliente VPN leva dous minutos en Connecting e o perfil é correcto. Hai unha hora funcionaba no mesmo edificio. Nada está roto: unha VPN é unha conexión que transporta outra rede, e o modo avión acaba de quitar a rede que a transportaba. O cliente segue reintentando porque é o que fai sen un enlace ascendente.
O que confunde é que o símbolo do avión non di se hai Wi-Fi dispoñible, e Connecting non di se o cliente se está autenticando ou só espera. Separe esas dúas lecturas e o diagnóstico tarda un minuto.
O símbolo do avión non é un informe de radio
En dispositivos Android compatibles, o Wi-Fi e o Bluetooth poden seguir activados en modo avión, e o dispositivo lembra a elección que fixo a última vez. A guía de Google sobre o modo avión no Pixel describe exactamente ese comportamento. Así que a icona pode significar que o móbil está apagado e nada máis.
Comprobe o estado real en lugar do glifo. adb shell settings get global airplane_mode_on devolve 0 ou 1 para o propio modo, e adb shell dumpsys connectivity enumera as redes que o dispositivo ten agora, co seu estado de validación. Esas dúas saídas xuntas responden a pregunta que a icona non pode.
Se o Wi-Fi está apagado, ou activado pero sen asociarse a nada, non hai camiño cara ao punto final da VPN e ningunha cantidade de reconexións o creará. Ese é o caso que convén descartar primeiro, porque é o único no que o arranxo correcto está fóra da aplicación VPN.
Que significa realmente Connecting
Un cliente pode manter un perfil gardado, mostrar o seu nome e xirar un indicador sen ter contactado con nada. A configuración é local. Establecer un túnel require un servidor accesible, un apretón de mans completado e unha interface pola que encamiñar. Só esa última parte necesita unha rede que funcione, e por iso as dúas primeiras poden parecer exitosas coa radio apagada.
Así que o indicador encaixa con polo menos tres situacións distintas: ningún enlace ascendente, un enlace ascendente que non acada o punto final e un enlace ascendente que o acada pero falla a autenticación. Na pantalla vense idénticos e nun rexistro son completamente distintos. Por iso o primeiro artefacto útil en calquera destes casos é o rexistro, non outro reintento.
A propia documentación de VPN de Android traza a mesma liña entre o establecemento da conexión e as políticas separadas de sempre activo e de bloqueo. Esa separación é a razón pola que un teléfono pode parecer protexido mentres está sen conexión e aínda así non ter túnel.
Catro estados que convén distinguir
Os catro estados seguintes son os que convén nomear, porque a pantalla móstraos de forma 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 |
A terceira fila atrapa a maioría da xente en hoteis e aeroportos. A asociación non é admisión: un portal que non deixou pasar o teléfono aceptará encantado o contrasinal do Wi-Fi e despois negarase a pasar tráfico cara ao punto final da VPN. Iniciar sesión primeiro polo navegador, co túnel apagado, adoita ser a única forma de pasar.
Por que o bloqueo o fai parecer peor
Se a VPN sempre activa e o bloqueo de conexións sen VPN están ambos activados, cada aplicación cuberta queda bloqueada sempre que o túnel non estea levantado. Iso é a función traballando, non unha segunda avaría. O síntoma pasa de fallar unha aplicación a fallar todo, o que se le como un problema moito maior.
Tamén explica a secuencia que a xente malinterpreta: modo avión activado, sen enlace ascendente, aplicacións bloqueadas, a VPN di connecting. O bloqueo era a política facendo o seu traballo. Desactivar a política para probar o enlace ascendente elimina a protección que vostede presumiblemente quería e non lle ensina nada.
Comprobe o alcance no seu lugar. Que aplicacións están cubertas, cales excluídas e se o perfil é por usuario ou para todo o dispositivo. Unha tarefa que inicia a aplicación VPN en canto aparece o Wi-Fi é un disparador, non unha garantía de que non saíse ningún paquete antes de que se executase.
Unha orde de diagnóstico que acaba coas conxecturas
Traballa de abaixo arriba. Confirme o modo, confirme que hai unha rede, confirme que está validada, confirme que pode acadar algo fóra da subrede local e só entón mire o cliente. adb shell ping -c 3 1.1.1.1 é unha proba tosca, pero separa un camiño que falta dun camiño que existe mentres o túnel está descontento.
Se o ping falla mentres hai unha rede na lista, o problema está por encima da VPN e ningún axuste do cliente o arranxará. Se o ping funciona e o túnel aínda non se establece, capture o rexistro do cliente nese momento: o erro distinguirá un tempo de espera dun rexeitamento de autenticación, e eses dous non teñen nada en común.
Termine restaurando o estado previsto: Wi-Fi permitido en modo avión se esa é a súa configuración habitual, o portal completado e a política de bloqueo de novo activada. Logo reconecte unha vez e confirme que o túnel sobe só, porque unha configuración que só funciona tras reintentos manuais volverá fallar no próximo arranque.