VPN atascada en Connecting en modo avión: encuentre el enlace ascendente
Un cliente que se queda en Connecting en modo avión puede simplemente no tener enlace ascendente. Separe el estado de la radio, la asociación, el inicio de sesión del portal y la política de bloqueo.
El teléfono muestra el icono del avión, el cliente VPN lleva dos minutos en Connecting y el perfil es correcto. Hace una hora funcionaba en el mismo edificio. Nada está roto: una VPN es una conexión que transporta otra red, y el modo avión acaba de quitar la red que la transportaba. El cliente sigue reintentando porque es lo que hace sin un enlace ascendente.
Lo que confunde es que el símbolo del avión no dice si hay Wi-Fi disponible, y Connecting no dice si el cliente se está autenticando o solo espera. Separe esas dos lecturas y el diagnóstico tarda un minuto.
El símbolo del avión no es un informe de radio
En dispositivos Android compatibles, el Wi-Fi y el Bluetooth pueden seguir activados en modo avión, y el dispositivo recuerda la elección que hizo la última vez. La guía de Google sobre el modo avión en Pixel describe exactamente ese comportamiento. Así que el icono puede significar que el móvil está apagado y nada más.
Compruebe el estado real en lugar del glifo. adb shell settings get global airplane_mode_on devuelve 0 o 1 para el propio modo, y adb shell dumpsys connectivity enumera las redes que el dispositivo tiene ahora, con su estado de validación. Esas dos salidas juntas responden la pregunta que el icono no puede.
Si el Wi-Fi está apagado, o encendido pero sin asociarse a nada, no hay camino hacia el punto final de la VPN y ninguna cantidad de reconexiones lo creará. Ese es el caso que conviene descartar primero, porque es el único en el que el arreglo correcto está fuera de la aplicación VPN.
Qué significa realmente Connecting
Un cliente puede mantener un perfil guardado, mostrar su nombre y girar un indicador sin haber contactado con nada. La configuración es local. Establecer un túnel requiere un servidor accesible, un handshake completado y una interfaz por la que encaminar. Solo esa última parte necesita una red que funcione, y por eso las dos primeras pueden parecer exitosas con la radio apagada.
Así que el indicador encaja con al menos tres situaciones distintas: ningún enlace ascendente, un enlace ascendente que no alcanza el punto final y un enlace ascendente que lo alcanza pero falla la autenticación. En pantalla se ven idénticos y en un registro son completamente distintos. Por eso el primer artefacto útil en cualquiera de estos casos es el registro, no otro reintento.
La propia documentación de VPN de Android traza la misma línea entre el establecimiento de la conexión y las políticas separadas de siempre activo y de bloqueo. Esa separación es la razón por la que un teléfono puede parecer protegido mientras está sin conexión y aun así no tener túnel.
Cuatro estados que conviene distinguir
Los cuatro estados siguientes son los que conviene nombrar, porque la pantalla los muestra 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 |
La tercera fila atrapa a la mayoría de la gente en hoteles y aeropuertos. La asociación no es admisión: un portal que no ha dejado pasar el teléfono aceptará encantado la contraseña del Wi-Fi y luego se negará a pasar tráfico hacia el punto final de la VPN. Iniciar sesión primero por el navegador, con el túnel apagado, suele ser la única forma de pasar.
Por qué el bloqueo lo hace parecer peor
Si la VPN siempre activa y el bloqueo de conexiones sin VPN están ambos activados, cada aplicación cubierta queda bloqueada siempre que el túnel no esté levantado. Eso es la función trabajando, no una segunda avería. El síntoma pasa de fallar una aplicación a fallar todo, lo que se lee como un problema mucho mayor.
También explica la secuencia que la gente malinterpreta: modo avión activado, sin enlace ascendente, aplicaciones bloqueadas, la VPN dice connecting. El bloqueo era la política haciendo su trabajo. Desactivar la política para probar el enlace ascendente elimina la protección que usted presumiblemente quería y no le enseña nada.
Compruebe el alcance en su lugar. Qué aplicaciones están cubiertas, cuáles excluidas y si el perfil es por usuario o para todo el dispositivo. Una tarea que inicia la aplicación VPN en cuanto aparece el Wi-Fi es un disparador, no una garantía de que no saliera ningún paquete antes de que se ejecutara.
Un orden de diagnóstico que acaba con las conjeturas
Trabaje de abajo hacia arriba. Confirme el modo, confirme que hay una red, confirme que está validada, confirme que puede alcanzar algo fuera de la subred local y solo entonces mire al cliente. adb shell ping -c 3 1.1.1.1 es una prueba tosca, pero separa un camino que falta de un camino que existe mientras el túnel está descontento.
Si el ping falla mientras hay una red en la lista, el problema está por encima de la VPN y ningún ajuste del cliente lo arreglará. Si el ping funciona y el túnel aún no se establece, capture el registro del cliente en ese momento: el error distinguirá un tiempo de espera de un rechazo de autenticación, y esos dos no tienen nada en común.
Termine restaurando el estado previsto: Wi-Fi permitido en modo avión si esa es su configuración habitual, el portal completado y la política de bloqueo de nuevo activada. Luego reconecte una vez y confirme que el túnel sube solo, porque una configuración que solo funciona tras reintentos manuales volverá a fallar en el próximo arranque.