Inicio de sesión en el portal cautivo de Android: inicie sesión y solucione fallos
Published
Está en la recepción de un hotel, su teléfono indica Conectado y nada carga. Sin página de inicio de sesión, sin errores sobre los que pueda actuar, solo aplicaciones cargando indefinidamente mientras el icono de WiFi muestra una pequeña advertencia. Eso se debe a que el inicio de sesión en el portal cautivo de Android no está haciendo bien su trabajo, o a que la red responde a las comprobaciones de Android de una forma que deja al teléfono atrapado entre conectado y con internet.
La solución rara vez consiste en tocar la pantalla al azar. Android sigue una máquina de estados de detección clara y, una vez que sabe en qué estado se encuentra, sabe qué pulsar, qué configuración cambiar o si la culpa es del establecimiento. Yo comenzaría con el aviso del sistema, luego iría hacia afuera, al navegador, a la configuración de privacidad y solo entonces al diseño del propio portal.
Índice de contenidos
- Iniciar sesión en un portal cautivo en Android en menos de un minuto
- Cómo decide Android si una red requiere inicio de sesión
- Solución de errores de inicio de sesión en su propio teléfono
- Problemas conocidos con la detección del portal cautivo
- Dispositivos Android gestionados y en modo quiosco
- Elija un diseño de portal que funcione en Android
Inicie sesión en un portal cautivo en Android en menos de un minuto
Consiga la notificación Iniciar sesión en la red antes de recurrir a Chrome. Android la abre en su propia vista de inicio de sesión, realiza un seguimiento de lo que selecciona y vuelve a probar la red cuando finaliza. Una pestaña del navegador que abra usted mismo no recibe ninguno de esos tratamientos, razón por la cual los usuarios que omiten el aviso a menudo terminan con una página en la que han iniciado sesión y un teléfono que sigue insistiendo en que no hay internet.
- Toque la notificación Iniciar sesión en la red. Despliegue el panel de notificaciones o toque el aviso situado debajo del nombre de la red WiFi. Por lo general, aparece a los pocos segundos de conectarse y le lleva directamente a la página del establecimiento sin tener que adivinar la URL.
- Si no hay ninguna notificación, abra una página http sencilla. En su navegador, visite una dirección http, no https. El portal puede interceptar y redirigir una solicitud sin cifrar, mientras que una página cifrada se bloqueará o mostrará una advertencia de certificado. Elija una dirección que no haya visitado recientemente, para que el navegador no responda desde su memoria caché y omita la red por completo.
- Complete el paso del establecimiento. Acepte los términos, introduzca su número de habitación, escriba el código SMS o utilice el inicio de sesión en redes sociales ofrecido. No cierre la ventana antes de tiempo, ya que Android necesita la señal de finalización para volver a realizar la comprobación.
- Espere a que desaparezca el aviso. El icono de WiFi debería perder el triángulo de advertencia y la etiqueta Sin internet debería desaparecer. Ese cambio significa que Android ha vuelto a validar la conexión, no solo que ha cargado una página, y es la diferencia entre un inicio de sesión completado y un formulario que ha rellenado para nada.
- Desactive y active el WiFi una vez si sigue indicando Sin internet. Apague y encienda el WiFi antes de intentar algo más invasivo. Una nueva conexión fuerza una nueva comprobación y borra un resultado obsoleto.
El éxito parece aburrido, que es de lo que se trata. La notificación se borra, la página que quería se carga y sus aplicaciones siguen funcionando después de salir del navegador. Si está creando instrucciones repetibles para el personal o los invitados, las colecciones de guías paso a paso pueden ayudarle a mantener esos pasos en un formato que las personas sigan en la recepción.
Cómo determina Android si una red requiere inicio de sesión
Android no toma decisiones consultando su navegador. Realiza una pregunta en segundo plano y, a continuación, evalúa la respuesta.
Cuando su teléfono se conecta a WiFi, envía una prueba HTTP en texto claro a un punto de conexión de conectividad conocido y espera una respuesta vacía correcta específica. Si la red intercepta esa solicitud y devuelve una redirección o una página de inicio de sesión en su lugar, Android considera que la red es cautiva y le solicita que inicie sesión. La documentación del portal cautivo de Android 11 señala que Android introdujo la detección integrada de portales cautivos en Android 5.0, lanzada en 2014, correspondiente al API nivel 21, y que históricamente la prueba utilizaba connectivitycheck.gstatic.com.
Esa fecha es importante para los operadores. La gestión de portales no es un truco del navegador que se añade a posteriori. Es una función del sistema operativo que controla los avisos, las etiquetas de validación y si las aplicaciones consideran que están conectadas.
Quién hace qué dentro de Android
Android divide el trabajo. NetworkMonitor prueba el alcance y el estado del portal. La aplicación preinstalada Captive Portal Login (Inicio de sesión del portal cautivo) muestra la página de autenticación y comunica al sistema la opción que ha elegido.
Tras iniciar sesión, Android vuelve a realizar la prueba. Si el sondeo se supera ahora, la red pasa al estado validado y la advertencia desaparece. Si no se supera, puede tener un formulario de inicio de sesión completado y seguir sin un acceso a internet utilizable.
La nueva ruta es más limpia. Una red puede anunciar su portal durante el proceso DHCP mediante la opción DHCP 114, que apunta Android a un punto de conexión de portal cautivoAPI. La Androidreferencia de NetworkCapabilities admite la parte de la aplicación relacionada con este flujo, donde Android 11 y versiones posteriores pueden recuperar dicho punto de conexión durante el procesamiento DHCP, y una respuesta JSON con captive: true hace que Android muestre directamente la interfaz de inicio de sesión del sistema. Si dicha API opción no está disponible, Android recurre a las comprobaciones.
Para los desarrolladores de aplicaciones, la señal se encuentra en la llamada de retorno de red. NET_CAPABILITY_CAPTIVE_PORTAL significa que el último sondeo ha detectado un portal. NET_CAPABILITY_VALIDATED significa que la red ha pasado la validación.
Una página HTTP 200 del portal no es prueba de acceso a Internet. Contabilice el inicio de sesión como correcto únicamente cuando la red alcance el estado validado.
Interpretación de la respuesta de la red
| Respuesta de la red | Qué concluye Android | Lo que ve usted |
|---|---|---|
| HTTP 204 del punto de conexión de prueba | Internet está abierto, sin portal | Sin aviso, la navegación funciona |
| HTTP 200 con HTML del portal en lugar de 204 | Portal cautivo detectado | Aparece la notificación de inicio de sesión |
| Prueba bloqueada, tiempo de espera agotado o fallo de DNS | La validación falla, portal no identificado | Sin aviso, etiqueta «Sin conexión a Internet» |
| JSON cautivo mediante DHCP Option 114 (Android 11 y posterior) | Inicio de sesión obligatorio | Se abre directamente la página de inicio de sesión del sistema |
| La prueba se supera tras iniciar sesión | Red validada | El aviso desaparece y las aplicaciones se pueden conectar |
Lea la tabla de izquierda a derecha. Android no juzga la imagen de su marca, los campos del formulario ni si la página parece terminada. Evalúa si la respuesta al sondeo ha cambiado de la forma esperada antes de iniciar sesión y si vuelve a la normalidad después.
Supongamos que una tableta de un hotel se conecta a la red de invitados pero nunca muestra el aviso. El personal suele culpar a la página de inicio de sesión y empieza a rediseñar los botones. Compruebe la sonda primero, porque si la red la bloquea, agota su tiempo de espera o la deja pasar demasiado libremente, es posible que Android nunca alcance el estado cautivo que activa el aviso.
Ese es el modelo mental que debe mantener. El aviso depende de cómo responde la red a una comprobación automatizada. Un portal impecable no puede solucionar una respuesta de sondeo incorrecta, y una respuesta de sondeo correcta puede hacer que incluso un portal sencillo resulte fiable.
Solucionar fallos de inicio de sesión en su propio teléfono
Analice los síntomas a continuación antes de cambiar varios ajustes a la vez. Haga un cambio, vuelva a probar una vez y luego continúe.
| Síntoma | Causa probable | Solución |
|---|---|---|
| No aparece la notificación de inicio de sesión tras conectarse | Comprobación bloqueada o resultado antiguo en caché | Olvide la red, vuelva a conectarse y abra una página http sencilla en el navegador |
| La página de inicio de sesión solo aparece en sitios https | El portal solo redirige solicitudes http sencillas | Abra una página http para activar la redirección |
| Sesión iniciada pero sigue indicando 'Sin internet' | DNS privado o VPN bloqueando la comprobación | Desactive el DNS privado y la VPN, y luego desactive y active el WiFi |
| El portal no deja de reaparecer | La dirección MAC aleatoria ha cambiado para la sesión | Configure la red para utilizar la dirección MAC del dispositivo en esta red |
| La página de inicio de sesión está en blanco o no se envía | Caché del navegador obsoleta o página del portal antigua | Borre la caché del navegador y pruebe con otro navegador |
| Funciona en un teléfono pero en otro no | Diferente versión de Android o ajustes de privacidad | Compare las versiones de Android y realice pruebas con la MAC aleatoria desactivada |
| Conectado, pero las aplicaciones siguen fallando | La conectividad aún no se ha vuelto a validar | Espere 30 segundos y active y desactive el modo avión |
Utilizaría este orden porque comienza con la solución más económica y evita debilitar la privacidad a menos que sea necesario.
- Desactive WiFi, a continuación, olvide la red y vuelva a conectarse. Esto borra el resultado de validación almacenado en la caché y fuerza una nueva comprobación.
- Compruebe el DNS privado, la VPN y la dirección MAC aleatoria. Estos ajustes se encuentran directamente en la ruta de DNS, enrutamiento e identidad del dispositivo, por lo que son los siguientes bloqueadores probables.
- Borre la caché del navegador o intente utilizar un segundo navegador. Hágalo cuando la página esté en blanco, cargada a medias o no se envíe.
Advertencia de privacidad: Desactivar el DNS privado o una VPN reduce su protección en una red pública. Vuelva a activar ambos en cuanto el inicio de sesión sea correcto y no realice operaciones bancarias ni cambios de contraseña hasta haberlo hecho.
La fila de dirección MAC aleatoria toma por sorpresa a la gente. Si el portal autorizó una identidad MAC y su teléfono presenta otra en la siguiente conexión, el establecimiento ve un dispositivo nuevo y muestra el portal de nuevo. Configurar esa red específica para usar la MAC del dispositivo estabiliza la sesión, pero no debe cambiarla a nivel global para todas las redes.
Si nada de esto funciona, deje de restablecer los ajustes. Anote la hora, el nombre de la red y el modelo del dispositivo y facilite estos datos al establecimiento para que puedan comprobar el lado del portal. Si el problema va más allá del inicio de sesión en WiFi, puede buscar ayuda con problemas del teléfono que cubra fallos más amplios del dispositivo, pero un portal de un establecimiento que nunca valida no se solucionará con un restablecimiento de fábrica.
Problemas conocidos con la detección de portales cautivos
La solución instintiva del operador es permitir más dominios antes del inicio de sesión. Ese instinto puede romper por completo el inicio de sesión en el portal cautivo de Android.
La guía actual de Captifi sobre portales cautivos que no se muestran explica que Android ejecuta comprobaciones de conectividad automatizadas que suelen esperar una respuesta HTTP 204 desde un extremo de comprobación de conectividad de Google, y que si un jardín vallado permite ese extremo de forma demasiado amplia, Android puede concluir que existe un acceso a internet sin restricciones y suprimir la solicitud de inicio de sesión. En términos sencillos, su lista de permitidos puede convencer al teléfono de que no hay ningún portal.
Esa es la diferencia que los operadores pasan por alto. Una lista de permitidos restrictiva podría bloquear un script de pago o un proveedor de identidad que el portal necesita. Una lista de permitidos amplia mantiene la página cuidada pero elimina el activador que la abre.
Dónde se interrumpe la máquina de estados
Los fallos no siempre parecen un aviso faltante. Los fallos de DNS pueden dejar en suspenso la validación. Una configuración de VPN o DNS privado puede desviarse del resolutor del establecimiento. El comportamiento solo HTTPS no ofrece al portal nada que pueda redirigir de forma segura. La aleatorización de MAC puede hacer que un teléfono parezca varios dispositivos a lo largo de las conexiones.
No se pueden depurar esos casos a partir de una captura de pantalla de la página de inicio de sesión. Registre las señales de la sesión que muestran a qué estado llegó Android y dónde se detuvo.
- Resultado de la comprobación: ¿La comprobación devolvió un código 204, una redirección, HTML del portal o nada?
- Resultado del DNS: ¿Se resolvió el punto de conexión a través del resolutor de la ubicación?
- Estado de la redirección: ¿Envió la pasarela el dispositivo a la URL del portal?
- Error de WebView: ¿No se pudo renderizar o enviar la vista de inicio de sesión?
- Identidad de MAC aleatoria: ¿Qué dirección MAC autorizó el portal?
- Validación posterior a la autenticación: ¿Se aprobó la red tras completar el formulario?
Supongamos que sus registros muestran sondeos permitidos y un inicio de sesión correcto, pero la validación nunca se produce. No culpe al dispositivo en primer lugar. Compruebe la redirección posterior al inicio de sesión y la liberación de la autorización, ya que el portal puede haber aceptado el formulario sin comunicar a la red que debe dar acceso al dispositivo.
Realizaría cuatro cambios, en este orden.
- Mantenga la lista de permitidos previa a la autenticación al mínimo que requieran el portal y sus proveedores de inicio de sesión.
- Registre cada campo de telemetría anterior para cada sesión fallida y correcta.
- Pruebe la incorporación segura mediante HTTPS para que los invitados no dependan de un único activador http básico.
- Planifique una ruta sin portal para dispositivos que no deban depender de un portal, utilizando opciones como OpenRoaming WiFi, Passpoint o certificados gestionados.
Quioscos y dispositivos gestionados de Android
Una tableta gestionada puede estar en una red que redirige correctamente y, aun así, no mostrar nunca una ventana de inicio de sesión. Eso no es un problema de intensidad de señal. Por lo general, se trata de una política.
Los consejos para consumidores asumen que puede pulsar notificaciones, desactivar una VPN y editar la configuración de privacidad de WiFi. El usuario de un quiosco a menudo no puede hacer nada de eso. Las directrices de movilidad empresarial sobre portales cautivos en quioscos establecen que los portales cautivos se gestionan mediante una aplicación preinstalada y que la directiva del quiosco debe permitirlo explícitamente, por lo que un paquete del sistema del portal cautivo bloqueado significa que el inicio de sesión nunca se ejecutará, incluso aunque la red funcione correctamente.
Esto afecta en lugares donde nadie piensa en el dispositivo como un teléfono. Piense en tablets de hospitales y escuelas, terminales de venta, tablets de hoteles y pantallas de check-in propiedad del establecimiento. El teléfono personal del cliente se conecta sin problemas, por lo que el personal declara que la red funciona correctamente mientras la flota gestionada permanece sin conexión.
Supongamos que un terminal de punto de venta portátil funciona cuando un encargado prueba la misma red en el teléfono del personal, pero la versión para el quiosco permanece desconectada. Compruebe la lista de permitidos de la directiva antes de tocar el portal. El teléfono demuestra que la redirección existe. El terminal portátil demuestra que la imagen gestionada no la abrirá.
Ejecute las comprobaciones de operador en este orden.
- Permita el paquete del sistema del portal cautivo en su directiva EMM o MDM, aplique la directiva y vuelva a conectarse a la red en un dispositivo de prueba.
- Pruebe Android System WebView en esa misma imagen de dispositivo, ya que un WebView no actualizado o deshabilitado puede hacer que el portal se quede en blanco o no pueda enviarse.
- Defina una ruta de incorporación alternativa para los dispositivos que no puedan mostrar un portal interactivo, como una conexión basada en certificados o un perfil preconfigurado, similar en concepto a una incorporación estructurada de BYOD en lugar de una contraseña compartida.
Primero la política, segundo WebView, tercero el mecanismo de reserva. Si invierte ese orden, creará soluciones alternativas para dispositivos que solo necesitaban permiso para mostrar la página que Android ya ha detectado.
Elija un diseño de portal que funcione en Android
Comience con tres criterios, no con el diseño de una página de bienvenida. La frecuencia con la que vuelven los invitados, si los dispositivos son personales o gestionados y qué versiones de Android deben funcionar deberían decidir el diseño.
Para invitados puntuales, un portal cautivo sigue siendo práctico. Mantenga la lista de permitidos de preautenticación tan pequeña como sea posible, admita los métodos de inicio de sesión que los invitados esperan y asegúrese de que la liberación posterior al inicio de sesión sea lo suficientemente rápida para que Android la valide antes de que el usuario empiece a cambiar la configuración. Nuestro propio portal se puede añadir a un controlador con la URL de bienvenida y RADIUS en menos de 15 minutos, con opciones de inicio de sesión que incluyen SSO, Google, Apple, Facebook y SMS, pero la velocidad de configuración no elimina la necesidad de probar el comportamiento de la prueba.
Para los invitados recurrentes, le aconsejo evitar forzar un portal en cada visita siempre que sea posible. Passpoint o OpenRoaming permite que un perfil instalado una sola vez se conecte automáticamente al volver, sin la fricción del portal y sin formularios repetidos. Compare esta opción con su configuración actual cuando revise las soluciones de WiFi para invitadosWiFi y confirme que la configuración de su controlador y de RADIUS admite esta opción antes de comprometerse.
A continuación, realice las pruebas como un operador, no como un diseñador.
- Versión de Android admitida más antigua: confirme que aparece el aviso y que se completa la validación.
- Dispositivo Android actual: confirme que los valores predeterminados de DNS privado y MAC aleatoria no dejen tirado al usuario.
- Compilación de quiosco administrada: confirme que la directiva permite la aplicación del portal y que WebView procesa la página.
En cada dispositivo, espere al estado validado y abra dos aplicaciones, no solo el navegador. Un teléfono que pase la prueba demuestra muy poco, ya que la detección varía según la versión de Android, la compatibilidad con DHCP y la directiva del dispositivo. Realice el despliegue para invitados únicamente después de que los tres casos hayan pasado la prueba.
Si sus invitados de Android no dejan de encontrarse con un portal que no responde, no valida o no mantiene la sesión iniciada, Purple Access puede ayudarle a ofrecer un portal cautivo personalizado para invitados puntuales y Passpoint o OpenRoaming para dispositivos recurrentes en los puntos de acceso que ya posee. Hable con nosotros para probar su dispositivo Android más antiguo, sus teléfonos actuales y cualquier configuración de quiosco gestionado antes de su próximo despliegue, de modo que el inicio de sesión funcione a la primera.
