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

TITLE: ¿Por qué no se conecta mi WiFi de invitados? Resolución de problemas de Captive Portal FORMAT: Podcast de informe técnico de Purple VOICE: Inglés británico - Tono de Arquitecto de Soluciones Senior 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 abordaremos uno de los problemas más persistentes y peor comprendidos en las redes inalámbricas empresariales: el Captive Portal de WiFi de invitados que simplemente se niega a cargarse. Usted ha estado allí. Un invitado llega a su hotel, su tienda minorista, su estadio o su centro de conferencias. Se une a la red WiFi. No pasa nada. No hay página de inicio de sesión. No hay internet. Solo un ícono giratorio y una creciente sensación de frustración. Para los directores de operaciones de los establecimientos y los gerentes de TI, ese momento no es solo un inconveniente menor. Representa una falla directa en la experiencia de sus invitados, un aumento en las llamadas de soporte y una oportunidad perdida para capturar los datos de primera mano que justifican su inversión en infraestructura inalámbrica. En este informe, iremos más allá de la superficie. Explicaremos exactamente cómo funciona la detección de Captive Portal a nivel del sistema operativo, identificaremos las seis causas raíz responsables de la gran mayoría de las fallas de conexión y le brindaremos un marco de trabajo práctico y aplicable para la resolución de problemas que puede 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 en él simplemente como una página de inicio de sesión. En realidad, es un mecanismo de intercepción de tráfico a nivel de red, y esa distinción es sumamente importante cuando las cosas salen mal. Esta es la secuencia. El dispositivo de un invitado se une 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 envía inmediatamente una solicitud HTTP GET no cifrada a una URL de sonda 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 propia sonda en detectportal.firefox.com. Si la red tiene acceso abierto a internet, estas sondas devuelven sus respuestas esperadas y el sistema operativo concluye que todo está bien. Pero en una red de invitados, su puerta de enlace o controlador inalámbrico intercepta esa sonda HTTP antes de que llegue a internet. En lugar de la respuesta esperada, la puerta de enlace 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 segura (sandboxed), a menudo llamada Asistente de Captive Portal, para mostrar la página de inicio de sesión. Ese es el camino ideal. Ahora hablemos de las seis formas en que se interrumpe. Causa raíz número uno: agotamiento del pool de DHCP. Este es el asesino silencioso en eventos de alta densidad. Si organiza una conferencia con dos mil asistentes en una subred estándar barra 24, tiene 254 direcciones IP utilizables. Si el tiempo de arrendamiento de DHCP está configurado en las 24 horas predeterminadas, agotará 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: configure los tiempos de arrendamiento de DHCP de invitados entre 15 y 30 minutos para entornos de alta rotación, y dimensione sus subredes adecuadamente para el pico de usuarios concurrentes, no solo para el número total de personas. Causa raíz número dos: falla en la intercepción de DNS. La redirección del Captive Portal depende de que la puerta de enlace intercepte la sonda HTTP. Pero la sonda requiere primero una búsqueda de DNS. Si su configuración de DNS no permite que los clientes preautenticados resuelvan nombres de dominio externos, la sonda nunca se activa. Asegúrese de que su política de firewall permita explícitamente las consultas DNS de clientes no autenticados y verifique que la intercepción de DNS funcione ejecutando 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 de preautenticación, define a qué dominios externos pueden acceder los invitados no autenticados. Si la página de bienvenida de su portal carga recursos de una CDN que no está en el Walled Garden, la página se mostrará en blanco. Si ofrece inicio de sesión social a través de Google, Apple o Facebook, cada dominio de OAuth que utilicen esos proveedores debe estar en la lista blanca. 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 fallando silenciosamente hoy. Programe auditorías trimestrales del Walled Garden y utilice la detección de dominios con comodines si su 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 comunicarse con un dominio precargado con HSTS (lo que incluye prácticamente a todos los sitios web importantes) y su puerta de enlace intenta interceptar esa solicitud HTTPS para redirigirla al portal, el navegador detectará una discrepancia en el certificado. Presentará una advertencia de seguridad que no se puede omitir y bloqueará la redirección por completo. La solución correcta es nunca intentar la intercepción de HTTPS. Su puerta de enlace solo debe redirigir las sondas canario HTTP no cifradas. La solución a largo plazo basada en estándares es RFC 8910, que define la Opción DHCP 114. Esta opción permite que su 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 admiten esto de forma nativa. Causa raíz número cinco: VPN activa en el dispositivo del invitado. Una VPN cifra todo el tráfico del dispositivo y lo enruta a través de un túnel externo antes de que llegue a su puerta de enlace. Su puerta de enlace nunca ve la sonda HTTP. La secuencia de detección del Captive Portal nunca se activa. El invitado no ve la página de inicio de sesión ni tiene internet. La solución para el invitado es simple: desactivar la VPN, conectarse al portal y luego volver a activar la VPN. Para su personal de atención al público, esta debería ser la primera pregunta que hagan cuando un invitado informe un problema de conexión. Causa raíz 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 de forma predeterminada 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 encontrarse nuevamente con la página de inicio de sesión después de que la MAC de su dispositivo rote. La solución para el invitado es desactivar la opción de Dirección Privada para su SSID específico en la configuración de red. La solución para el operador es implementar una autenticación basada en perfiles, como OpenRoaming a través de Passpoint y 802.1X, que autentica en la Capa 2 utilizando credenciales en lugar de direcciones MAC, lo que hace que la aleatorización sea irrelevante. --- SECTION 3: Recomendaciones de implementación y errores comunes - aproximadamente 2 minutos Ahora que comprendemos las causas raíz, hablemos de cómo se ve una implementación de Captive Portal bien configurada. Comience con su arquitectura DHCP. Para cualquier establecimiento que espere más de 200 dispositivos concurrentes, evite utilizar una sola subred barra 24. Utilice una barra 22 o superior, y configure los tiempos de arrendamiento para que coincidan con el perfil de permanencia de su establecimiento. Un hotel configura los arrendamientos en 8 horas. Un estadio los configura en 3 horas. Un centro comercial los configura en 90 minutos. Un centro de conferencias los configura en 30 minutos. A continuación, valide su Walled Garden antes de cada evento importante. Las entradas mínimas requeridas son: el FQDN de su portal y todos los dominios de CDN asociados, las URL de detección de Captive Portal para Apple, Google, Windows y Firefox, y los dominios de OAuth para cada proveedor de inicio de sesión social que admita. En la plataforma de Purple, mantenemos y actualizamos estas entradas del Walled Garden de forma automática 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 emitido por una autoridad de certificación reconocida. Los certificados autofirmados generarán advertencias del navegador en todos los dispositivos. Renueve los certificados antes de su vencimiento; un certificado vencido es una de las causas más comunes de fallas repentinas del portal en todo el establecimiento. Un error común que afecta a muchos equipos de TI: probar el portal desde un dispositivo que ya se ha autenticado previamente. La sesión de su dispositivo sigue activa, por lo que omitirá el portal por completo y concluirá que todo funciona. Realice siempre las pruebas desde un dispositivo en un estado nuevo y no autenticado, 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 Captive Portals son una tecnología madura, pero conllevan una fricción inherente. OpenRoaming, basado en Passpoint y 802.1X, permite a los invitados recurrentes conectarse 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. Establecimientos como Premier Inn y Manchester Airports Group ya están implementando esto para eliminar la fricción de la reautenticación para los visitantes recurrentes, manteniendo al mismo tiempo el cumplimiento total de GDPR y la captura de datos de primera mano. --- SECTION 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 sonda. Si su firewall bloquea ese dominio o no está en su Walled Garden, los dispositivos Android nunca activarán el portal. Agréguelo explícitamente. Pregunta: Un invitado dice que el portal se cargó pero no puede conectarse a internet después de iniciar sesión. Respuesta: Esto casi siempre se debe a una falla de autorización de RADIUS. Verifique que su servidor RADIUS sea accesible desde el controlador inalámbrico, compruebe que el secreto compartido coincida en ambos lados y revise los registros de RADIUS en busca de mensajes Access-Reject. Pregunta: ¿Cómo manejamos a los invitados que se desconectan continuamente después de unos minutos? Respuesta: Verifique la configuración del tiempo de espera por inactividad (idle timeout). Muchos controladores tienen un tiempo de espera predeterminado de 5 minutos, lo cual es demasiado agresivo para los dispositivos móviles que entran en modo de suspensión entre interacciones. Configure el tiempo de espera por inactividad en al menos 30 minutos para entornos de hotelería y comercio minorista. --- SECTION 5: Resumen y próximos pasos - aproximadamente 1 minuto En resumen: las fallas del Captive Portal de WiFi de invitados se dividen en seis categorías: agotamiento de DHCP, falla en la intercepción de DNS, Walled Garden incompleto, bloqueo de redirección HSTS, VPN activa en el dispositivo cliente y aleatorización de direcciones MAC. Cada una tiene una solución específica y comprobable. Para su equipo de TI, las acciones inmediatas son: auditar los tiempos de arrendamiento de DHCP y el tamaño de las subredes, validar su Walled Garden frente a los dominios de 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 largo plazo, evalúe OpenRoaming como el sucesor de la reautenticación de Captive Portal para visitantes recurrentes. La tecnología es madura, los estándares están establecidos bajo IEEE 802.1X y WPA3-Enterprise, y Purple la pone a su disposición sin costo de software adicional bajo el plan Connect. Para obtener más guías técnicas, casos de estudio y recursos de implementación, visite purple.ai. Gracias por escuchar este informe técnico de Purple. Mantenga sus redes confiables y a sus invitados conectados.