¿Por qué no se conecta mi WiFi de invitados? Resolución de problemas con el Captive Portal

TITLE: ¿Por qué no se conecta mi WiFi de invitados? Solución de problemas con el Captive Portal FORMAT: Pódcast de informes técnicos de Purple VOICE: Inglés británico - Tono de arquitecto sénior de soluciones DURATION: Aproximadamente 10 minutos --- SECTION 1: Introducción y contexto - aproximadamente 1 minuto Hola y bienvenidos a este informe técnico de Purple. Soy su anfitrión, y hoy vamos a abordar uno de los problemas más persistentes y peor comprendidos en las redes inalámbricas empresariales: el Captive Portal de la WiFi de invitados que simplemente se niega a cargar. Seguro que ha pasado por eso. Un invitado llega a su hotel, a su tienda de retail, a su estadio o a su centro de conferencias. Se conecta a la red WiFi. No pasa nada. No hay página de inicio de sesión. No hay internet. Solo un icono dando vueltas y una creciente sensación de frustración. Para los directores de operaciones de las instalaciones y los responsables de TI, ese momento no es solo un pequeño inconveniente. Representa un fallo directo en la experiencia de sus invitados, un aumento en las llamadas de soporte en recepción y una oportunidad perdida de capturar los datos de primera mano que justifican su inversión en infraestructura inalámbrica. En este informe, vamos a mirar bajo el capó. Explicaremos exactamente cómo funciona la detección del Captive Portal a nivel de sistema operativo, identificaremos las seis causas principales responsables de la gran mayoría de los fallos de conexión y le ofreceremos un marco de resolución de problemas práctico y aplicable que podrá entregar a su equipo de TI hoy mismo. Comencemos. --- SECTION 2: Análisis técnico profundo - aproximadamente 5 minutos Para solucionar un problema de Captive Portal, primero debe comprender qué hace realmente un Captive Portal a nivel de red. La mayoría de la gente piensa que es simplemente una página de inicio de sesión. En realidad, es un mecanismo de interceptación de tráfico a nivel de red, y esa distinción es enormemente importante cuando las cosas van mal. Esta es la secuencia. El dispositivo de un invitado se conecta a su SSID de invitados y recibe una dirección IP a través de DHCP. En ese punto, el sistema operativo no espera a que el usuario abra un navegador. En segundo plano, un servicio del sistema lanza inmediatamente una solicitud HTTP GET no cifrada a una URL de sondeo controlada por el proveedor. Los dispositivos Apple consultan captive.apple.com. Los dispositivos Android consultan connectivitycheck.gstatic.com. Los dispositivos Windows consultan msftconnecttest.com. Firefox tiene su propio sondeo en detectportal.firefox.com. Si la red tiene acceso abierto a internet, estos sondeos devuelven las respuestas esperadas y el sistema operativo concluye que todo está bien. Pero en una red de invitados, su gateway o controlador inalámbrico intercepta ese sondeo HTTP antes de que llegue a internet. En lugar de la respuesta esperada, la gateway devuelve una redirección HTTP 302 que apunta a la página de bienvenida de su Captive Portal. El sistema operativo detecta la redirección inesperada, se da cuenta de que está detrás de un Captive Portal y abre una ventana de navegador aislada (a menudo llamada asistente del Captive Portal) para mostrar la página de inicio de sesión. Ese es el camino feliz. Ahora hablemos de las seis formas en que se interrumpe. Causa raíz número uno: el agotamiento del pool de DHCP. Este es el asesino silencioso en eventos de alta densidad. Si estás organizando una conferencia con dos mil asistentes en una subred estándar slash-24, dispones de 254 direcciones IP utilizables. Si el tiempo de concesión de DHCP está configurado en las 24 horas predeterminadas, agotarás ese pool a los pocos minutos de abrir las puertas. Cada intento de conexión posterior fallará antes de que comience la secuencia del Captive Portal. La solución es sencilla: configura los tiempos de concesión de DHCP para invitados entre 15 y 30 minutos en entornos de alta rotación, y dimensiona las subredes de forma adecuada para los usuarios concurrentes pico, no solo para el número total de asistentes. Causa raíz número dos: fallo de interceptación de DNS. La redirección del Captive Portal depende de que la pasarela intercepte la sonda HTTP. Pero la sonda requiere primero una resolución de DNS. Si tu configuración de DNS no permite que los clientes preautenticados resuelvan nombres de dominio externos, la sonda nunca se activa. Asegúrate de que la política de tu cortafuegos permita explícitamente las consultas DNS de clientes no autenticados, y verifica que la interceptación de DNS funcione realizando una captura de paquetes en un dispositivo de prueba. Causa raíz número tres: walled garden incompleto. El walled garden - también llamado lista de control de acceso previa a la autorización - define a qué dominios externos pueden acceder los invitados no autenticados. Si la página de inicio de tu portal carga recursos de una CDN que no está en el walled garden, la página se mostrará como una pantalla en blanco. Si ofreces inicio de sesión social a través de Google, Apple o Facebook, todos los dominios OAuth que utilicen esos proveedores deben estar en la lista de permitidos. Y aquí está el punto crítico: los proveedores de identidad social actualizan sus rangos de IP de CDN y dominios de autenticación con regularidad. Un walled garden que funcionaba perfectamente hace seis meses puede estar roto hoy en día de forma silenciosa. Programa auditorías trimestrales del walled garden y utiliza la detección de dominios con comodines si tu hardware lo admite. En Cisco Meraki, HPE Aruba, Ruckus y Juniper Mist, esto está disponible de forma nativa. Causa raíz número cuatro: HSTS bloqueando la redirección. HTTP Strict Transport Security, o HSTS, es una política de seguridad del navegador que obliga a realizar conexiones a dominios específicos únicamente a través de HTTPS. Si el dispositivo de un invitado intenta ponerse en contacto con un dominio precargado con HSTS - lo que incluye prácticamente a todos los sitios web importantes - y tu pasarela intenta interceptar esa solicitud HTTPS para redirigirla al portal, el navegador detectará una discrepancia de certificado. Presentará una advertencia de seguridad que no se puede omitir y bloqueará la redirección por completo. La solución correcta es no intentar nunca la interceptación de HTTPS. Tu pasarela solo debe redirigir las sondas canario HTTP no cifradas. La solución a largo plazo basada en estándares es el RFC 8910, que define la opción DHCP 114. Esta opción permite que tu servidor DHCP anuncie directamente la URL del Captive Portal al dispositivo cliente, evitando por completo la necesidad de redirección HTTP. iOS 14 y Android 11 y versiones superiores son compatibles con esto de forma nativa. Causa principal número cinco: VPN activa en el dispositivo del invitado. Una VPN cifra todo el tráfico del dispositivo y lo dirige a través de un túnel externo antes de que llegue a su gateway. Su gateway nunca llega a ver la sonda HTTP. La secuencia de detección del Captive Portal nunca se activa. El invitado no ve ninguna página de inicio de sesión ni tiene internet. La solución para el invitado es sencilla: desactivar la VPN, conectarse al portal y luego volver a activar la VPN. Para su personal de recepción, esta debería ser la primera pregunta que hagan cuando un invitado informe de un problema de conexión. Causa principal número seis: la aleatorización de direcciones MAC rompe la persistencia de la sesión. Los dispositivos modernos con iOS y Android utilizan direcciones MAC aleatorias por defecto como función de privacidad. Cada vez que un dispositivo se conecta a una red, puede presentar una dirección MAC diferente. Dado que el estado de la sesión del Captive Portal se rastrea mediante la dirección MAC, un invitado que se autenticó hace una hora puede volver a encontrarse con la página de inicio de sesión después de que rote la MAC de su dispositivo. La solución por parte del invitado es desactivar la Dirección Privada para su SSID específico en los ajustes de red. La solución por parte del operador es implementar una autenticación basada en perfiles - como OpenRoaming a través de Passpoint y 802.1X - que se autentica en la Capa 2 utilizando credenciales en lugar de direcciones MAC, haciendo que la aleatorización sea irrelevante. - SECCIÓN 3: Recomendaciones de implementación y errores comunes - aproximadamente 2 minutos Ahora que entendemos las causas principales, hablemos de cómo es en realidad un despliegue de Captive Portal bien configurado. Comience con su arquitectura DHCP. Para cualquier recinto que espere más de 200 dispositivos concurrentes, evite utilizar una única subred de barra-24. Utilice una barra-22 o superior, y ajuste los tiempos de concesión (lease times) para que coincidan con el perfil de permanencia de su recinto. Un hotel configura las concesiones en 8 horas. Un estadio configura las concesiones en 3 horas. Un centro comercial configura las concesiones en 90 minutos. Un centro de conferencias configura las concesiones en 30 minutos. A continuación, valide su walled garden antes de cada gran evento. Las entradas mínimas requeridas son: el FQDN de su portal y todos los dominios CDN asociados, las URL de detección de Captive Portal para Apple, Google, Windows y Firefox, y los dominios OAuth de cada proveedor de inicio de sesión social que admita. En la plataforma de Purple, mantenemos y actualizamos estas entradas de walled garden automáticamente como parte de nuestro servicio gestionado en la nube, lo que elimina la carga de mantenimiento manual para su equipo. Para el certificado de su portal, utilice un certificado TLS de confianza pública de una autoridad de certificación reconocida. Los certificados autofirmados provocarán advertencias del navegador en todos los dispositivos. Renueve los certificados antes de que caduquen - un certificado vencido es una de las causas más comunes de fallos repentinos del portal en todo el recinto. Un error habitual en el que caen muchos equipos de TI es probar el portal desde un dispositivo que ya se ha autenticado previamente. La sesión de su dispositivo sigue activa, por lo que se salta el portal por completo y se concluye que todo funciona. Realice siempre las pruebas desde un dispositivo en un estado nuevo y sin autenticar, ya sea un dispositivo nuevo o uno en el que haya olvidado la red y borrado el perfil de WiFi. Por último, considere la dirección estratégica a seguir. Los portales cautivos son una tecnología madura, pero conllevan una fricción inherente. OpenRoaming, basado en Passpoint y 802.1X, permite que los clientes que regresan se conecten de forma automática y segura sin ver nunca una página de inicio de sesión. Purple actúa como un proveedor de identidad gratuito para OpenRoaming bajo nuestro plan Connect. Lugares como Premier Inn y Manchester Airports Group ya están implementando esto para eliminar la fricción de la autenticación repetida para los visitantes recurrentes, manteniendo al mismo tiempo el cumplimiento total de GDPR y la captura de datos de primera mano. - SECCIÓN 4: Preguntas y respuestas rápidas - aproximadamente 1 minuto Repasemos las preguntas más comunes que escuchamos de los equipos de TI de los establecimientos. Pregunta: ¿Por qué el portal funciona en iPhones pero no en dispositivos Android? Respuesta: Android utiliza connectivitycheck.gstatic.com como su URL de prueba. Si ese dominio está bloqueado por su firewall o no está en su walled garden, los dispositivos Android nunca activarán el portal. Agréguelo explícitamente. Pregunta: Un cliente dice que el portal se cargó pero no puede conectarse después de iniciar sesión. Respuesta: Casi siempre se trata de un fallo de autorización de RADIUS. Compruebe que su servidor RADIUS es accesible desde el controlador inalámbrico, verifique que el secreto compartido coincide en ambos lados y revise los registros de RADIUS para ver si hay mensajes de Access-Reject. Pregunta: ¿Cómo gestionamos a los clientes que siguen cerrando la sesión después de unos minutos? Respuesta: Compruebe la configuración del tiempo de espera de inactividad. Muchos controladores tienen por defecto un tiempo de espera de inactividad de 5 minutos, que es demasiado agresivo para los dispositivos móviles que entran en reposo entre interacciones. Establezca el tiempo de espera de inactividad en al menos 30 minutos para entornos de hostelería y comercio minorista. - SECCIÓN 5: Resumen y próximos pasos - aproximadamente 1 minuto En resumen: los fallos del Captive Portal de WiFi para invitados se dividen en seis categorías: agotamiento de DHCP, fallo de interceptación de DNS, walled garden incompleto, bloqueo de redirección de HSTS, VPN activa en el dispositivo cliente y aleatorización de direcciones MAC. Cada uno tiene una solución específica y comprobable. Para su equipo de TI, las acciones inmediatas son: auditar los tiempos de concesión de DHCP y el tamaño de la subred, validar su walled garden frente a los dominios OAuth actuales de sus proveedores de inicio de sesión social y probar su portal desde un dispositivo nuevo no autenticado después de cada cambio de configuración. Para su hoja de ruta a más largo plazo, evalúe OpenRoaming como el sucesor de la autenticación repetida en portales cautivos para los visitantes recurrentes. La tecnología es madura, los estándares están establecidos bajo IEEE 802.1X y WPA3, y Purple lo pone a su disposición sin coste de software adicional bajo el plan Connect. Para obtener más guías técnicas, casos de éxito y recursos de implementación, visite purple.ai. Gracias por escuchar esta sesión técnica de Purple. Mantenga sus redes estables y a sus invitados conectados.