Inicio de sesión en portal cautivo de Android: Inicie sesión y solucione fallas
Published
Usted está en el lobby de un hotel, su teléfono dice Conectado y nada carga. Sin página de inicio de sesión, sin ningún error sobre el que pueda actuar, solo aplicaciones cargando indefinidamente mientras el ícono de WiFi muestra una pequeña advertencia. Eso es el inicio de sesión del portal cautivo de Android haciendo mal su trabajo, o la red respondiendo a las verificaciones de Android de una manera que deja al teléfono atrapado entre conectado y en línea.
La solución rara vez es pulsar al azar. Android sigue una clara máquina de estados de detección, y una vez que usted sabe en qué estado se encuentra, sabrá qué tocar, qué configuración cambiar o si la falla proviene del establecimiento. Yo comenzaría con la notificación del sistema, luego pasaría al navegador, a las opciones de privacidad y, solo después, al diseño del portal en sí.
Tabla de contenido
- Inicie sesión en un portal cautivo en Android en menos de un minuto
- Cómo decide Android si una red requiere iniciar sesión
- Solucione los fallos de inicio de sesión en su propio teléfono
- Problemas conocidos con la detección del portal cautivo
- Dispositivos en modo Kiosko y administrados de Android
- Elija un diseño de portal que funcione en Android
Inicie sesión en un portal cautivo en Android en menos de un minuto
Consulte la notificación Iniciar sesión en la red antes de abrir Chrome. Android la abre en su propia vista de inicio de sesión, realiza un seguimiento de lo que usted elige y vuelve a probar la red cuando finaliza. Una pestaña del navegador que abra usted mismo no recibe nada de ese procesamiento, razón por la cual las personas que omiten la solicitud a menudo terminan con una página con sesión iniciada 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 la sugerencia debajo del nombre de la red WiFi. Por lo general, aparece a los pocos segundos de conectarse y lo lleva directamente a la página del establecimiento sin tener que adivinar una URL.
- Si no hay ninguna notificación, abra una página http sin cifrar. 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 detendrá o mostrará una advertencia de certificado. Elija una dirección que no haya visitado recientemente para que el navegador no responda desde su caché e ignore la red por completo.
- Complete el paso del establecimiento. Acepte los términos, ingrese su número de habitación, escriba el código SMS o utilice el acceso a través de 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 prueba.
- Espere a que desaparezca la advertencia. El ícono de WiFi debería perder su triángulo de advertencia y la etiqueta Sin internet debería desaparecer. Ese cambio significa que Android volvió a validar la conexión, no solo que cargó una página, y es la diferencia entre un inicio de sesión completado y un formulario que llenó en vano.
- Desactive y active el WiFi una vez si todavía dice Sin internet. Apague y encienda el WiFi antes de intentar algo más invasivo. Una nueva conexión fuerza una nueva comprobación y elimina un resultado desactualizado.
El éxito parece aburrido, y esa es la idea. 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 huéspedes, las colecciones de guías paso a paso pueden ayudarle a mantener esos pasos en un formato que la gente pueda seguir en la recepción.
Cómo determina Android si una red requiere inicio de sesión
Android no decide examinando su navegador. Hace una pregunta en segundo plano y luego evalúa la respuesta.
Cuando su teléfono se une a WiFi, envía una prueba HTTP en texto claro a un punto de enlace de conectividad conocido y espera una respuesta vacía específica de éxito. Si la red intercepta esa solicitud y en su lugar devuelve una redirección o una página de inicio de sesión, Android trata la red como cautiva y le solicita que interactúe. La documentación del portal cautivo de Android 11 señala que Android introdujo la detección de portal cautivo integrada en Android 5.0, lanzada en 2014, correspondiente al APInivel de API 21, y que históricamente la prueba utilizaba connectivitycheck.gstatic.com.
Esa fecha es importante para los operadores. El manejo del portal no es un truco del navegador que se añade después. Es una función del sistema operativo que controla los avisos, las etiquetas de validación y si las aplicaciones consideran que están en línea.
Quién hace qué dentro de Android
Android divide el trabajo. NetworkMonitor prueba la accesibilidad y el estado del portal. La aplicación preinstalada Captive Portal Login muestra la página de autenticación del portal cautivo e informa al sistema sobre la opción que usted eligió.
Después de iniciar sesión, Android vuelve a realizar la prueba. Si el sondeo se aprueba ahora, la red pasa a estar en estado validado y la advertencia desaparece. Si no se aprueba, puede tener un formulario de inicio de sesión completado y aún así no tener acceso a internet utilizable.
El método más reciente es más limpio. Una red puede anunciar su portal durante el proceso DHCP mediante la Opción DHCP 114, apuntando Android a un extremo del portal cautivoAPI. La Androidreferencia de NetworkCapabilities admite la parte correspondiente a la aplicación de este flujo, donde Android 11 y versiones posteriores pueden recuperar dicho extremo durante el procesamiento de DHCP y una respuesta JSON con captive: true hace que Android presente directamente la interfaz de inicio de sesión del sistema. Si eso API no está disponible, Android recurre al uso de sondeos.
Para los desarrolladores de aplicaciones, la señal está en la devolución de llamada de la red. NET_CAPABILITY_CAPTIVE_PORTAL significa que el sondeo más reciente detectó un portal. NET_CAPABILITY_VALIDATED significa que la red superó la validación.
Una página HTTP 200 del portal no es prueba de acceso a internet. Cuente el inicio de sesión como exitoso ú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 desde el punto de enlace de prueba | El Internet está abierto, sin portal | Sin avisos, 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 avisos, etiqueta "Sin conexión a Internet" |
| JSON cautivo mediante Opción DHCP 114 (Android 11 y posteriores) | Inicio de sesión requerido | La página de inicio de sesión del sistema se abre directamente |
| La prueba se aprueba después de iniciar sesión | Red validada | La advertencia desaparece y las aplicaciones se pueden conectar |
Lea la tabla de izquierda a derecha. Android no está evaluando la identidad visual de su marca, los campos de su formulario o si la página parece terminada. Está evaluando si la respuesta del sondeo cambió de la manera 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 huéspedes pero nunca solicita el inicio de sesión. El personal suele culpar a la página de acceso y comienza a rediseñar los botones. Verifique la prueba de sondeo primero, porque si la red la bloquea, agota el tiempo de espera o la deja pasar demasiado libremente, es posible que Android nunca alcance el estado cautivo que activa la solicitud.
Ese es el modelo mental que debe conservar. El aviso depende de cómo responda 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 sea confiable.
Solucione los fallos de inicio de sesión en su propio teléfono
Analice los siguientes síntomas antes de cambiar varias opciones a la vez. Haga un cambio, vuelva a probar y luego continúe.
| Síntoma | Causa probable | Solución |
|---|---|---|
| No hay notificación de inicio de sesión tras conectarse | Sondeo bloqueado o resultado antiguo en caché | Olvide la red, vuelva a conectarse y abra una página http sin cifrar en el navegador |
| La página de inicio de sesión solo aparece en sitios https | El portal solo redirige solicitudes http sin cifrar | Abra una página http para activar la redirección |
| Sesión iniciada pero sigue apareciendo 'Sin internet' | DNS privado o VPN bloquean la comprobación | Desactive el DNS privado y la VPN, luego desactive y active el WiFi |
| El portal sigue reapareciendo | La dirección MAC aleatoria cambió para la sesión | Configure la red para usar 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 desactualizada o página del portal antigua | Borre la caché del navegador e intente con otro navegador |
| Funciona en un teléfono, pero no en otro | Diferente versión de Android o configuración de privacidad | Compare las versiones de Android y realice una prueba con la MAC aleatoria desactivada |
| Conectado, pero las aplicaciones siguen fallando | La conectividad aún no se ha vuelto a validar | Espere 30 segundos, luego active y desactive el modo avión |
Yo utilizaría este orden porque comienza con la solución menos costosa y evita reducir la privacidad a menos que sea necesario.
- Desactive WiFi, luego olvide la red y vuelva a conectarse. Esto borra el resultado de validación en caché y fuerza una nueva comprobación.
- Verifique el DNS privado, la VPN y la dirección MAC aleatoria. Estos ajustes se encuentran directamente en la ruta del DNS, el enrutamiento y la identidad del dispositivo, por lo que son los siguientes bloqueadores probables.
- Borre la caché del navegador o intente con un segundo navegador. Haga esto cuando la página esté en blanco, cargada a la mitad o no envíe la información.
Advertencia de privacidad: Desactivar el DNS privado o una VPN reduce su protección en una red pública. Vuelva a activar ambos tan pronto como el inicio de sesión sea exitoso y no realice transacciones bancarias ni cambios de contraseña hasta haberlo hecho.
La fila de dirección MAC aleatoria toma a la gente por sorpresa. 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 vuelve a mostrar el portal. 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 reiniciar las cosas. Anote la hora, el nombre de la red y el modelo del dispositivo, y luego proporcione esos detalles al establecimiento para que puedan verificar el lado del portal. Si el problema va más allá del inicio de sesión en WiFi, puede encontrar ayuda con problemas del teléfono que cubre fallas más amplias del dispositivo, pero un portal del establecimiento que nunca valida no se solucionará con un restablecimiento de fábrica.
Problemas conocidos con la detección del portal cautivo
La solución instintiva del operador es permitir más dominios antes del inicio de sesión. Ese instinto puede arruinar por completo el inicio de sesión del portal cautivo de Android.
La guía actual de Captifi sobre portales cautivos que no se muestran explica que Android realiza verificaciones de conectividad automatizadas que normalmente esperan una respuesta HTTP 204 desde un punto de enlace de verificación de conectividad de Google, y que si un jardín vallado permite ese punto de enlace de forma demasiado amplia, Android puede concluir que existe un acceso a internet sin restricciones y suprimir el aviso 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 desventaja que los operadores pasan por alto. Una lista de permitidos reducida podría bloquear un script de pago o un proveedor de identidad que el portal requiere. Una lista de permitidos amplia mantiene la página presentable pero elimina el activador que la abre.
Dónde se interrumpe la máquina de estados
Las fallas no siempre se ven como una falta de notificación. Las fallas de DNS pueden dejar la validación colgada. Una configuración de VPN o DNS privado puede desviarse del resolutor del establecimiento. El comportamiento exclusivo de HTTPS no le da al portal nada que pueda redirigir de manera segura. La aleatorización de MAC puede hacer que un teléfono parezca varios dispositivos a través de diferentes conexiones.
No puede depurar esos casos a partir de una captura de pantalla de la página de inicio de sesión. Registre las señales de sesión que muestran a qué estado llegó Android y dónde se detuvo.
- Resultado del sondeo: ¿La verificación devolvió un código 204, una redirección, el HTML del portal o nada?
- Resultado de DNS: ¿Se resolvió el extremo a través del resolvedor del establecimiento?
- Estado de la redirección: ¿El gateway envió el dispositivo a la URL del portal?
- Error de WebView: ¿La vista de inicio de sesión no se pudo procesar o enviar?
- Identidad MAC aleatoria: ¿Qué dirección MAC autorizó el portal?
- Validación posterior a la autenticación: ¿La red funcionó correctamente después de completar el formulario?
Suponga que sus registros muestran sondeos permitidos y un inicio de sesión exitoso, pero la validación nunca se realiza. No culpe al dispositivo de inmediato. Verifique la redirección posterior al inicio de sesión y la liberación de la autorización, ya que es posible que el portal haya aceptado el formulario sin indicarle a la red que permita el paso del dispositivo.
Yo realizaría cuatro cambios, en este orden.
- Mantenga la lista de autorizaciones previa a la autenticación en el 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 exitosa.
- Pruebe la incorporación segura mediante HTTPS para que los invitados no dependan de un solo 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 administrados.
Dispositivos quiosco y gestionados de Android
Una tableta gestionada puede estar en una red que redirige correctamente y aun así no mostrar nunca la ventana de inicio de sesión. Eso no es un problema de intensidad de señal. Por lo general, se trata de una directiva o política.
Las recomendaciones para usuarios finales asumen que usted puede presionar notificaciones, desactivar una VPN y modificar la configuración de privacidad de WiFi. Con frecuencia, un usuario de un quiosco no puede realizar nada de esto. La guía de movilidad empresarial sobre portales cautivos en quioscos establece que los portales cautivos son gestionados por una aplicación precargada y que la política 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 si la red funciona correctamente.
Esto afecta en lugares donde nadie piensa en el dispositivo como un teléfono. Piense en tabletas de hospitales y escuelas, dispositivos portátiles de retail, tabletas de hoteles y pantallas de registro propiedad del establecimiento. El teléfono personal del invitado inicia sesión sin problemas, por lo que el personal declara que la red está sana mientras que la flota administrada permanece fuera de línea.
Suponga que un dispositivo portátil minorista funciona cuando un gerente prueba la misma red en el teléfono del personal, pero la versión del kiosco permanece desconectada. Verifique la lista de permitidos de la directiva antes de modificar el portal. El teléfono demuestra que la redirección existe. El dispositivo portátil demuestra que la imagen administrada no la abrirá.
Ejecute las comprobaciones de operador en este orden.
- Permita el paquete del sistema del portal cautivo en su política EMM o MDM, luego aplique la política y vuelva a unirse a la red en un dispositivo de prueba.
- Pruebe Android System WebView en esa imagen de dispositivo exacta, ya que un WebView desactualizado o deshabilitado puede dejar el portal en blanco o imposibilitar el envío de datos.
- Defina una ruta de incorporación alternativa para los dispositivos que no pueden mostrar un portal interactivo, como un perfil preconfigurado o una conexión basada en certificados, con un enfoque similar a la incorporación de BYOD estructurada en lugar de una contraseña compartida.
Primero la política, segundo la vista web (WebView) y tercero la alternativa. Si invierte ese orden, creará soluciones alternativas para dispositivos que solo necesitaban permiso para mostrar la página Android que ya se había 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 inicio. La frecuencia con la que vuelven los invitados, si los dispositivos son personales o gestionados, y qué versiones de Android deben funcionar deberían determinar el diseño.
Para los invitados ocasionales, un portal cautivo sigue siendo práctico. Mantenga la lista de permitidos previa a la autenticación lo más pequeña 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 comience a cambiar la configuración. Nuestro propio portal se puede agregar a un controlador con la URL de la página de inicio y RADIUS en menos de 15 minutos, con opciones de inicio de sesión que incluyen SSO, Google, Apple, Facebook y SMS, pero la rapidez de la configuración no elimina la necesidad de probar el comportamiento de la prueba.
Para los invitados recurrentes, le recomiendo no forzar un portal en cada visita si puede evitarlo. Passpoint o OpenRoaming permite que un perfil instalado una sola vez se conecte automáticamente al regresar, sin la fricción de un portal y sin formularios repetidos. Compare esa opción con su configuración actual cuando revise las soluciones de WiFiWiFi para invitados, y confirme que su controlador y la configuración de RADIUS admitan esta opción antes de comprometerse.
Luego, realice las pruebas como un operador, no como un diseñador.
- Versión más antigua de Android compatible: Confirme que aparezca la notificación y que la validación se complete.
- Dispositivo Android actual: Confirme que los valores predeterminados de DNS privado y MAC aleatoria no dejen varado al usuario.
- Build de quiosco administrado: Confirme que la directiva permita la aplicación del portal y que WebView procese la página.
En cada dispositivo, espere al estado validado y abra dos aplicaciones, no solo el navegador. Un solo teléfono que pase demuestra muy poco, ya que la detección varía según la versión de Android, el soporte de DHCP y la directiva del dispositivo. Realice el despliegue para invitados solo después de que los tres hayan pasado la prueba.
Si los invitados de su Android siguen encontrando un portal que no da el aviso, no valida o no mantiene la sesión iniciada, Purple Access puede ayudarle a ejecutar un portal cautivo con la imagen de su marca para invitados ocasionales y Passpoint o OpenRoaming para dispositivos que regresan en los puntos de acceso que ya posee. Hable con nosotros sobre cómo probar su dispositivo Android más antiguo, sus teléfonos actuales y cualquier estructura de kiosco gestionada antes de su próximo despliegue, para que el inicio de sesión funcione a la primera.
