Resolución de problemas de WiFi público: Solucionar "Conectado, sin internet" y fallas de redirección a la Splash Page

Le damos la bienvenida a esta sesión informativa técnica de Purple. Hoy abordaremos uno de los problemas más persistentes y peor comprendidos en las redes inalámbricas empresariales: el captive portal de la red WiFi para invitados que simplemente se niega a cargar. Usted ha estado ahí. Un invitado llega a su hotel, tienda de retail, estadio o centro de conferencias. Se conecta a la red WiFi. No pasa nada. No aparece la página de inicio de sesión. No hay internet. Solo un icono girando y una creciente sensación de frustración. Para los directores de operaciones de las instalaciones 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 a la recepción y una oportunidad perdida para recopilar los datos de primera mano que justifican su inversión en infraestructura inalámbrica. En esta sesión informativa, analizaremos a fondo el funcionamiento interno. Explicaremos exactamente cómo funciona la detección de captive portal a nivel del sistema operativo, identificaremos las seis causas fundamentales responsables de la gran mayoría de las fallas de conexión y le proporcionaremos un marco de resolución de problemas práctico y aplicable que puede entregar a su equipo de TI hoy mismo. Comencemos con la parte mecánica. La mayoría de las personas piensan que un captive portal 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 sumamente importante cuando las cosas salen mal. Este es el orden de los pasos. 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 momento, el sistema operativo no espera a que el usuario abra un navegador. En segundo plano, un servicio del sistema inicia de inmediato una solicitud HTTP GET no cifrada a una URL de prueba 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 prueba en detectportal.firefox.com. Si la red tiene acceso abierto a internet, estas pruebas 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 esa prueba HTTP antes de que llegue a internet. En lugar de la respuesta esperada, el gateway devuelve una redirección HTTP 307 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 de red cautiva o Captive Network Assistant - para mostrar la página de inicio de sesión. Ese es el camino feliz. Ahora hablemos de las seis formas en que esto se rompe. Causa raíz número uno: agotamiento del pool de DHCP. Este es el asesino silencioso en eventos de alta densidad. Si está organizando una conferencia con dos mil asistentes en una subred estándar barra 24, tiene 254 direcciones IP utilizables. Si el tiempo de concesión 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á incluso antes de que comience la secuencia del Captive Portal. La solución es sencilla: configure los tiempos de concesión de DHCP para invitados entre 15 y 30 minutos para entornos de alta rotación, y dimensione sus subredes de manera adecuada para los usuarios concurrentes pico, no solo para el número total de personas. Causa raíz número dos: falla en la intercepción de DNS. El redireccionamiento 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 de DNS de clientes no autenticados, y verifique que su 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 previa a la autenticación - define qué dominios externos pueden alcanzar los invitados no autenticados. Si la página de inicio de su portal carga recursos desde una CDN que no está en el walled garden, la página se mostrará como una pantalla 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 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 fallando silenciosamente hoy. Programe auditorías trimestrales de walled garden y utilice el rastreo 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 el redireccionamiento. 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 redireccionar al portal, el navegador detectará una discrepancia de certificados. Presentará una advertencia de seguridad que no se puede omitir y bloqueará el redireccionamiento por completo. La solución correcta es nunca intentar la intercepción de HTTPS. Su puerta de enlace solo debe redireccionar las sondas canario HTTP no cifradas. La solución a largo plazo basada en estándares es RFC 8910, que define la Opción 114 de DHCP. Esta opción permite que su servidor DHCP anuncie directamente la URL del Captive Portal al dispositivo cliente, evitando por completo la necesidad de un redireccionamiento HTTP. iOS 14 y Android 11 y versiones superiores admiten esto de forma nativa. Quinta causa raíz: VPN activa en el dispositivo del invitado. Una VPN cifra todo el tráfico desde el 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 detecta 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 acceso a 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 atención al público, esta debería ser la primera pregunta que hagan cuando un invitado informe un problema de conexión. Sexta causa raíz: 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 ver la página de inicio de sesión después de que la MAC de su dispositivo cambie. La solución del lado del invitado es desactivar la Dirección Privada para su SSID específico en la configuración de red. La solución del lado del operador es implementar la 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. Ahora hablemos de la implementación. ¿Cómo se ve en la práctica un despliegue de Captive Portal bien configurado? Comience con su arquitectura DHCP. Para cualquier recinto que espere más de 200 dispositivos simultáneos, evite el uso de una sola subred de barra-24. Utilice una barra-22 o superior, y configure los tiempos de concesión para que coincidan con el perfil de permanencia de su recinto. Un hotel establece concesiones de 8 horas. Un estadio establece concesiones de 3 horas. Un centro comercial establece concesiones de 90 minutos. Un centro de conferencias establece concesiones de 30 minutos. A continuación, valide su jardín amurallado (walled garden) antes de cada evento importante. Las entradas mínimas requeridas son: el nombre de dominio completamente calificado 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 para cada proveedor de inicio de sesión social que admita. En la plataforma de Purple, mantenemos y actualizamos estas entradas del jardín amurallado 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 recinto. 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 omite el portal por completo y concluye 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.Permítame presentarle dos escenarios del mundo real que ilustran estos principios. Escenario uno: un hotel de 350 habitaciones en el centro de Londres. La propiedad utilizaba una única subred diagonal 24 para el WiFi de invitados. Durante una gran conferencia, llegaron 400 delegados de forma simultánea. En un lapso de 20 minutos, el pool de DHCP se agotó. Los huéspedes reportaron estar conectados pero no podían acceder al Captive Portal ni a internet. La solución inmediata fue ampliar la subred a diagonal 22, lo que proporcionó 1,022 direcciones útiles, y reducir el tiempo de concesión de 24 a 8 horas. La solución a largo plazo fue implementar el Captive Portal gestionado en la nube de Purple, el cual monitorea la utilización del pool de DHCP en tiempo real y alerta al equipo de red antes de que ocurra el agotamiento. La tasa de falla del portal disminuyó a casi cero dentro de las 48 horas posteriores al cambio. Escenario dos: una importante cadena de tiendas de autoservicio con 200 sucursales. La cadena utilizaba el inicio de sesión social a través de Google y Facebook en su portal de invitados. Después de que Google actualizó su infraestructura de OAuth, los nuevos dominios de autenticación no se encontraban en el walled garden. Los invitados podían llegar a la página del portal, pero los botones de inicio de sesión social mostraban pantallas en blanco. El equipo de TI de la cadena pasó dos días diagnosticando el problema antes de identificar la brecha en el walled garden. La solución tomó 10 minutos una vez identificada. La lección: nunca codifique de forma fija las direcciones IP en su walled garden para proveedores de OAuth basados en la nube. Utilice entradas de dominio con comodines y revíselas trimestralmente. Ahora, pasemos a algunas preguntas rápidas que escuchamos con frecuencia de los equipos de TI de los establecimientos. ¿Por qué el portal funciona en iPhones pero no en dispositivos Android? Android utiliza connectivitycheck.gstatic.com como su URL de prueba. Si su firewall bloquea ese dominio o si no está en su walled garden, los dispositivos Android nunca activarán el portal. Agréguelo de forma explícita. Un invitado dice que el portal cargó pero que no puede conectarse a internet después de iniciar sesión. Esto es casi siempre 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 de Access-Reject. ¿Cómo manejamos a los invitados que se desconectan constantemente después de unos minutos? Revise la configuración del tiempo de espera por inactividad. Muchos controladores tienen predeterminado un tiempo de espera por inactividad de 5 minutos, lo cual es demasiado agresivo para los dispositivos móviles que entran en modo de suspensión entre interacciones. Establezca el tiempo de espera por inactividad en al menos 30 minutos para entornos de hotelería y comercio minorista. Para resumir los puntos clave de la sesión de hoy. Las fallas del Captive Portal de WiFi de invitados se clasifican en seis categorías: agotamiento del pool de DHCP, falla de intercepció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 una 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 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 más largo plazo, evalúe OpenRoaming como el sucesor de la reautenticación de Captive Portal para los visitantes frecuentes. 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. Purple opera en 80,000 establecimientos y ha procesado 440 millones de inicios de sesión solo en 2024. Hemos visto todos los modos de falla descritos en esta sesión informativa y construimos las herramientas para prevenirlos. Si desea explorar cómo se integra la plataforma en la nube de Purple con su infraestructura existente de Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist, visite purple.ai o hable con su gerente de cuenta. Gracias por su atención.