La página de inicio de Cisco Meraki no funciona: un diagrama de flujo para la resolución de problemas

Las páginas de inicio de Cisco Meraki dejan de aparecer cuando un cliente aún está autorizado, no puede emitir la solicitud HTTP que activa el redireccionamiento, no puede alcanzar una dependencia permitida de la página de inicio o no puede completar la autenticación RADIUS. Comience con un cliente afectado, filtre los registros de Auth, DHCP y RADIUS por su dirección MAC, y luego pruebe la rama correspondiente a continuación. 1 2 3 5

¿Qué debe seguir funcionando para que aparezca una página de inicio de Meraki?

Considere un Captive Portal como una cadena corta, no como una sola página web. Un dispositivo debe asociarse al SSID correcto, recibir un direccionamiento válido, clasificarse como no autorizado, enviar tráfico que pueda iniciar el flujo de la página de inicio, llegar al servicio alojado requerido y luego recibir la autorización. Cisco Meraki describe el activador como un HTTP GET de un cliente no autorizado. El AP intercepta esa solicitud y devuelve un redireccionamiento HTTP 307 a la URL de la página de inicio. 1

Esto explica una llamada de soporte común: un invitado puede unirse a su WiFi de invitados pero dice que la página de inicio no se carga. El punto de acceso puede estar funcionando según lo diseñado. Si el dispositivo abre primero un destino que es solo HTTPS, la solicitud cifrada no se puede redireccionar. Cisco Meraki identifica esto específicamente como un escenario de tiempo de espera del navegador (browser timeout). Pruebe la rama HTTP controlada antes de cambiar el SSID, el diseño de la página o el servidor RADIUS. 2

La misma disciplina evita un segundo error común: tratar cada aviso repetido como una falla de la página. La frecuencia de la página de inicio es una política de autorización. Cisco Meraki mantiene el estado de la página de inicio en el punto de acceso de la puerta de enlace y en el controlador en la nube, mientras que el navegador conserva una cookie de sesión. Es posible que un cliente con un período de autorización válido no vuelva a ver la página después de que usted acorte la frecuencia configurada. Por el contrario, un cliente con cookies desactivadas o borradas puede parecer que recibe avisos con demasiada frecuencia. 2

¿Qué debe registrar antes de cambiar algo?

Comience con un único reporte reproducible. Registre la dirección MAC del cliente, el SSID, el punto de acceso de la puerta de enlace o MX, el tipo de dispositivo, la hora local, el navegador y si el dispositivo ya había completado la autenticación de la splash page. Pida a la persona que reporta el problema que deje el dispositivo conectado mientras usted lo inspecciona. Esto le proporciona un límite para el incidente y evita que un hotel concurrido, una tienda minorista o el lugar de un evento conviertan una queja general en cambios de configuración a ciegas.

Abra los detalles del cliente y verifique si está autorizado. Cisco Meraki identifica a un cliente no autorizado como Splash: Not authorized; un cliente autorizado muestra el tiempo restante de su autorización. No use una pestaña del navegador guardada para realizar la prueba. Eso puede mezclar una sesión pasada con el estado actual de radio y DHCP. 1

Luego filtre el registro de eventos del Dashboard por la dirección MAC del cliente y la hora del incidente. Para los puntos de acceso MR, el tipo de evento Auth representa la autenticación de la splash page. 802.11 muestra la asociación y desasociación, DHCP contiene los eventos relacionados con la concesión de direcciones, y RADIUS identifica la actividad de RADIUS o del bypass de autenticación de MAC. El mismo filtro Auth está disponible para la autenticación de splash page de MX. Cisco Meraki señala que los dispositivos cargan los eventos almacenados una vez que vuelven a estar en línea, conservando las marcas de tiempo originales, así que alinee la zona horaria antes de decidir qué sucedió primero. 5

Utilice el siguiente registro ordenado. Este reduce el dominio de la falla sin necesidad de adivinar.

¿Cómo ejecutar el diagrama de flujo para la resolución de problemas?

Use el diagrama de flujo una vez para un dispositivo cliente de prueba limpio y otra para un dispositivo que se sepa afectado. La diferencia es útil. Si un cliente limpio llega a la página de bienvenida y el dispositivo conocido no lo hace, tendrá evidencia de un problema de autorización, del estado del navegador o de una política específica del cliente, en lugar de una interrupción en todo el sitio.

1. Confirme la asociación y el direccionamiento. Si el registro de eventos no muestra que el cliente se esté asociando al SSID previsto, no intente solucionar problemas de la página de bienvenida. Si se asocia pero los registros de DHCP muestran un error, corrija primero el direccionamiento o la ruta de la VLAN. Cisco Meraki identifica el etiquetado de VLAN en el SSID o en el puerto del switch ascendente como un área común de falla de DHCP. 6

2. Confirme que el cliente no está autorizado. Es posible que un dispositivo previamente autorizado aún no requiera otra página de bienvenida. Cisco Meraki documenta una función de revocación de autorización del cliente para realizar pruebas controladas de manera recurrente. Utilice esta función en el dispositivo designado, en lugar de cambiar la frecuencia de la página de bienvenida para todos los usuarios del sitio. 2 3

3. Pruebe el activador con HTTP. Borre la caché del navegador solo cuando esto se ajuste a su procedimiento de prueba, confirme que las cookies estén habilitadas y luego abra un destino HTTP. Cisco Meraki indica que una solicitud que prioriza HTTPS no se puede redireccionar porque el tráfico está cifrado. Si la prueba de HTTP funciona, documente el comportamiento del cliente como la causa. La red no ha perdido su redireccionamiento de página de bienvenida. 1 2

4. Pruebe la accesibilidad de la página y el walled garden. Un walled garden permite direcciones IP, rangos o nombres de host específicos antes de la autenticación de la página de bienvenida, incluidos los dominios con comodines. Si utiliza una URL de página de bienvenida personalizada, Cisco Meraki indica que la dirección IP o la URL de la página personalizada deben estar en el walled garden. Cuando la página dependa de endpoints de recursos, identidad o servicios independientes, revise cada destino requerido con el propietario del servicio. No intente adivinar las direcciones IP ni agregue un acceso amplio a internet como un atajo. 3

Las páginas de Purple aclaran esta distinción. Una página de bienvenida offline aparece antes de iniciar sesión y no puede incluir enlaces o recursos externos porque el visitante se encuentra dentro del walled garden. Una página online aparece después de un inicio de sesión exitoso y puede contener recursos multimedia o enlaces externos. Si una página HTML offline de Purple perdió una imagen, hoja de estilo, script o elemento de identidad de terceros después de un cambio, compare esas dependencias con las entradas permitidas de preautenticación antes de modificar el diseño. 7 8

1. Pruebe el inicio de sesión RADIUS solo después de que la página se haya cargado. RADIUS, el protocolo utilizado aquí para las solicitudes de autenticación central, no es el primer sospechoso cuando no aparece ninguna página de bienvenida. Adquiere relevancia cuando el formulario de inicio de sesión se carga pero la autenticación falla o agota el tiempo de espera. Para este flujo de Cisco Meraki, la nube del Dashboard origina la solicitud de acceso RADIUS, no el AP o MX local. El servidor necesita accesibilidad pública desde los rangos de origen documentados del Dashboard, un secreto compartido que coincida y compatibilidad con PAP. Cisco Meraki establece que RADSec no es compatible con la autenticación de la página de bienvenida. 4
2. Ejecute la verificación de RADIUS compatible y examine el registro del servidor. Cisco Meraki proporciona una prueba de RADIUS en el Dashboard para la configuración inalámbrica documentada, aunque el botón de prueba no existe para las redes de la serie MX o de la serie Z. Un tiempo de espera agotado (timeout) significa que debe verificar la información actual del firewall del Dashboard, las entradas del cliente RADIUS, la accesibilidad del host público, la alineación del secreto compartido y el comportamiento de las políticas. La verificación de estado de Cisco Meraki envía solicitudes de acceso periódicas y considera que el servidor no está disponible después de seis intentos sin respuesta, espaciados cada 20 segundos. 4

¿Cómo aislar los puntos de falla comunes?

La frecuencia de la Splash Page parece incorrecta

Si la Splash Page aparece con menos frecuencia de lo que sugiere la política, verifique si el cliente ya estaba autorizado cuando cambió la frecuencia. Cisco Meraki indica que el período de autorización existente permanece vigente. Revocar la autorización del cliente seleccionado crea una prueba válida para la configuración actualizada. Si la página aparece con más frecuencia, verifique la aceptación de cookies del navegador, la limpieza de la caché y la continuidad del punto de acceso de la puerta de enlace. Un reinicio de la puerta de enlace puede requerir autenticación nuevamente a menos que el navegador pueda presentar su cookie. 2

Esto es importante en el sector hotelero. Un hotel ilustrativo de 200 habitaciones debería realizar pruebas con un teléfono controlado después de un cambio, y luego medir el resultado bajo tres resultados simples: el cliente cambia a autorizado, recibe la expiración esperada y la siguiente solicitud HTTP nueva se comporta como se espera. Ese es un mejor filtro de lanzamiento que preguntar en recepción si han dejado de recibir quejas.

El WiFi de invitados no está redireccionando

No asuma que HTTPS ha "dañado" los portales cautivos. El comportamiento documentado de Cisco Meraki es más específico: el mecanismo de redirección funciona en un HTTP GET no autorizado, mientras que una solicitud inicialmente HTTPS no se puede redireccionar. Los dispositivos modernos pueden iniciar su flujo de detección de Captive Portal del sistema operativo al asociarse. Si ese aviso no aparece, utilice la prueba HTTP para establecer si la rama de la red funciona. 1 2

Para un despliegue minorista ilustrativo, el equipo de TI de una tienda puede reproducir la queja con un dispositivo de prueba del personal en el SSID del piso de ventas. La evidencia de aceptación no es un reclamo vago de carga de página. Capture el registro de asociación, la dirección válida, el estado no autorizado, el evento Auth después de la prueba HTTP y el estado de autorización resultante. Este registro se puede comparar entre tiendas sin exponer las credenciales de los visitantes.

El Walled Garden está incompleto

Un Walled Garden es un acceso limitado de forma intencionada antes de la autorización. No debe convertirse en una lista de desvíos. Revise primero el host de la Splash Page y luego las dependencias que su página de autenticación previa realmente necesita. Cisco Meraki permite direcciones IP, rangos de IP y nombres de host, con dominios comodín. Cisco también requiere una URL de Splash Page personalizada o una dirección IP en el Walled Garden cuando esa función está habilitada. 3

Una página fuera de línea de Purple es la etapa más restringida. Purple establece que no puede usar enlaces o recursos externos mientras el visitante se encuentre en el walled garden. El editor HTML permite a su equipo subir elementos al portal y previsualizar la página actual, lo que puede reducir las dependencias remotas innecesarias. Siga los pasos publicados por Purple antes de publicar una plantilla editada. 7 8

La pantalla de inicio de sesión agota el tiempo de espera o rechaza las credenciales

Separe el rechazo del agotamiento de tiempo de espera. Un rechazo es el resultado de una autenticación o política. Un mensaje de agotamiento de tiempo de espera o "dificultad para conectarse" señala primero a la capacidad de alcance entre el Dashboard y el servidor RADIUS configurado. Cisco Meraki documenta que las solicitudes de inicio de sesión de la pantalla de bienvenida se originan en la nube del Dashboard y no pueden usar una dirección LAN privada para el servidor RADIUS. 4

Confirme que el servidor espera PAP para este modo de pantalla de bienvenida, que los rangos de origen documentados del Dashboard están permitidos, que todas las IP de origen relevantes están configuradas como clientes RADIUS y que el secreto compartido coincide en ambos extremos. Cisco Meraki también indica que la integración de la pantalla de bienvenida externa debe usar la login_url suministrada sin modificaciones, y el filtrado debe permitir su nombre de host variable en lugar de un único patrón fijo. 4

¿Qué significan los eventos de pantalla de bienvenida de Meraki en el registro de eventos?

Lea el registro como una línea de tiempo. 802.11 association significa que el cliente se unió a un AP. No significa que el cliente tenga una dirección, haya llegado a la página de bienvenida o haya obtenido acceso a internet. Un evento Auth es la categoría de evento para la autenticación de la página de bienvenida. Un evento DHCP cerca de la misma hora puede trasladar la investigación al direccionamiento. Un evento RADIUS es importante para un flujo de inicio de sesión respaldado por RADIUS, pero no es prueba de que el navegador haya llegado a la página. 5 6

Evite confundir 802.1X con una pantalla de inicio de sesión. Cisco Meraki identifica los mensajes 802.1X y RADIUS para los SSID de WPA2-Enterprise. Su documentación separada de RADIUS para inicio de sesión de pantalla de bienvenida describe PAP entre la nube del Dashboard y su servidor RADIUS. En esta guía, use las categorías de asociación, Auth, DHCP y RADIUS para localizar la etapa fallida. No infiera una causa raíz exacta a partir de una sola línea de registro. 4 6

Cisco Meraki también expone los intentos de inicio de sesión de la página de inicio a través de su API de Dashboard documentada. El registro incluye la hora de inicio de sesión, el SSID, la MAC del dispositivo de gateway, la MAC del cliente y el estado de autorización. Para los equipos de TI de múltiples sitios, esto le permite asociar el ticket del lugar con un resultado de autenticación sin tratar una anécdota como evidencia de un incidente. 9

¿Cómo evitar que una página de inicio fija vuelva a fallar?

Mantenga un manual de procedimientos operativo corto junto con el propietario del servicio de Guest WiFi . El manual de procedimientos debe identificar el SSID de prueba, el dispositivo de prueba, el procedimiento de revocación de autorización, el host de página esperado, las dependencias de preautenticación, la propiedad de RADIUS y el contacto de escalación. También debe indicar el comportamiento de desconexión del controlador de la implementación. Cisco Meraki documenta el comportamiento abierto, restringido y predeterminado cuando el controlador de la nube no está disponible. 3

Para las propiedades que utilizan un Captive Portal para el consentimiento, el branding y la política de acceso, trate la página fuera de línea como un componente de aplicación controlado. Purple ofrece tipos de páginas fuera de línea, en línea y fuera de horario. Utilice la guía publicada de Splash Pages para los cambios en el flujo de acceso y la guía del HTML editor para los recursos cargados y la vista previa. Mantenga el diagnóstico del día dos separado de la configuración inicial. 7 8

Cuando esto se convierta en un problema repetitivo en el lugar, centralice la evidencia en lugar de centralizar las suposiciones. Correlacione la hora del incidente, la MAC del cliente, el AP o MX, el SSID, el estado de autorización, las categorías del registro de eventos y la respuesta del servidor RADIUS. Este enfoque se adapta a los sitios de Hospitality , Retail y Transport donde los equipos locales necesitan un límite de escalación claro y el equipo de red necesita evidencia reproducible. Para un diseño de servicio más amplio, consulte Guest WiFi Management: Smart Authentication & Segmentation .

Preguntas frecuentes

¿Funciona Purple con los puntos de acceso Cisco Meraki existentes?

Sí. Purple es compatible con implementaciones de WiFi para invitados que se superponen a la infraestructura existente, incluyendo Cisco Meraki. Esta guía cubre el diagnóstico del segundo día de una falla de splash en Meraki. No reemplaza el trabajo de diseño e incorporación necesario para un nuevo Captive Portal. Utilice la guía publicada de páginas de Splash de Purple para conocer los tipos de página admitidos y los cambios en el proceso de acceso. 7

¿Cuánto trabajo se requiere para migrar una página de splash de Meraki a Purple?

El trabajo depende del flujo de autenticación existente, las dependencias de preautenticación y el diseño de la página. Comience por inventariar el alojamiento de la página actual, las entradas del walled garden, el método de inicio de sesión y el destino posterior al inicio de sesión. Purple admite plantillas de páginas de splash estándar y HTML, incluyendo recursos cargados y vista previa en vivo. Planifique la migración como un cambio controlado, no como la solución de un incidente. 7 8

¿Puede una página de splash de Cisco Meraki redirigir una solicitud exclusiva de HTTPS?

No. Cisco Meraki documenta que su redirección de splash comienza cuando un cliente no autorizado envía un HTTP GET. El tráfico que prioriza HTTPS está encriptado y no se puede redirigir mediante ese mecanismo. Realice pruebas con un destino HTTP y luego distinga el comportamiento del navegador del cliente de una falla de splash en toda la red. 1 2

¿Qué entradas de walled garden necesita una página de splash personalizada de Meraki?

El walled garden debe permitir la dirección IP o la URL de la página de splash personalizada cuando esté habilitada. Luego, permita únicamente los endpoints de preautenticación adicionales que la página realmente requiera. Cisco Meraki admite direcciones IP, rangos y nombres de host, incluyendo dominios con comodines. No reemplace esa revisión con un acceso a internet sin restricciones. 3

¿Por qué se agota el tiempo de espera de una página de splash de inicio de sesión de Meraki con RADIUS?

Un agotamiento del tiempo de espera a menudo significa que la nube del Cisco Meraki Dashboard no puede obtener una respuesta del servidor RADIUS configurado. Verifique la accesibilidad pública, los rangos de origen actuales del Dashboard, las claves compartidas del cliente RADIUS que coincidan y el soporte de PAP. El AP o MX local no es el origen de las solicitudes RADIUS de splash. 4

¿Cómo monitoreamos las fallas de inicio de sesión de splash en varias sedes?

Utilice el registro de eventos de Meraki para filtrar el cliente afectado y la ventana de tiempo, luego correlacione las categorías Auth, DHCP y RADIUS. La API de intentos de inicio de sesión de splash de Cisco puede devolver la hora de inicio de sesión, el SSID, el dispositivo de puerta de enlace, el identificador del cliente y el estado de autorización. Eso crea un registro de evidencia consistente para una mesa de ayuda de múltiples sitios. 5 9

Referencias