La página splash de Cisco Meraki no funciona: diagrama de flujo de resolución de problemas

Las páginas de splash de Cisco Meraki dejan de aparecer cuando un cliente todavía está autorizado, no puede emitir la solicitud HTTP que activa la redirección, no puede llegar a una dependencia de splash permitida o no puede completar la autenticación RADIUS. Comience con un cliente afectado, filtre los registros de autenticación, 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 splash de Meraki?

Trate 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, ser clasificado como no autorizado, enviar tráfico que pueda iniciar el flujo de splash, 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 una redirección HTTP 307 a la URL de splash. 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 splash 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 redirigir. Cisco Meraki identifica esto específicamente como un escenario de tiempo de espera del navegador. 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 solicitud repetida como un fallo de la página. La frecuencia del splash es la política de autorización. Cisco Meraki mantiene el estado de splash en el punto de acceso de puerta de enlace y en el controlador de la nube, mientras que el navegador conserva una cookie de sesión. Es posible que un cliente con un periodo 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 solicitudes con demasiada frecuencia. [2]

¿Qué debe registrar antes de cambiar nada?

Comience con un único informe reproducible. Registre la dirección MAC del cliente, el SSID, el punto de acceso de la pasarela o MX, el tipo de dispositivo, la hora local, el navegador y si el dispositivo había completado previamente la autenticación splash. Solicite a la persona que informa que deje el dispositivo conectado mientras usted lo inspecciona. Esto le proporciona un límite del incidente y evita que un hotel concurrido, una tienda o el lugar de un evento conviertan una queja generalizada en cambios de configuración a ciegas.

Abra los detalles del cliente y compruebe si está autorizado. Cisco Meraki identifica un cliente no autorizado como Splash: Not authorized; un cliente autorizado muestra su tiempo restante de autorización. No utilice una pestaña del navegador guardada para realizar la prueba. Esto puede mezclar una sesión anterior con el estado de radio y DHCP actual. 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 página splash. 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 de omisión de autenticación MAC. El mismo filtro Auth está disponible para la autenticación splash de MX. Cisco Meraki señala que los dispositivos cargan los eventos almacenados tras volver a estar en línea, conservando las marcas de tiempo originales, así que alinee la zona horaria antes de decidir qué ocurrió primero. [5]

Utilice el siguiente registro ordenado. Reduce el dominio del fallo sin necesidad de adivinar.

¿Cómo se ejecuta el diagrama de flujo de resolución de problemas?

Utilice el diagrama de flujo una vez para un cliente de prueba limpio y otra para un cliente que se sepa afectado. La diferencia resulta útil. Si un cliente limpio llega a la página de bienvenida y el dispositivo conocido no lo hace, tendrá pruebas de que se trata 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 recinto.

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 fallo de DHCP. [6]

2. Confirme que el cliente no está autorizado. Es posible que un dispositivo previamente autorizado no requiera todavía otra página de bienvenida. Cisco Meraki documenta una función de revocación de autorización de clientes para realizar pruebas controladas. 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 recinto. [2] [3]

3. Pruebe el activador con HTTP. Borre la caché del navegador solo cuando 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 HTTPS de inicio no se puede redirigir 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 redirección a la 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 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 adivine direcciones IP ni añada un acceso amplio a internet como atajo. [3]

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

1. Pruebe el inicio de sesión RADIUS solo después de que se haya cargado la página. 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 se agota el tiempo de espera. Para este flujo de Cisco Meraki, la nube de 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 de Dashboard, un secreto compartido coincidente y compatibilidad con PAP. Cisco Meraki indica que RADSec no es compatible con la autenticación de la página de bienvenida. [4]
2. Ejecute la comprobación de RADIUS compatible y examine el registro del servidor. Cisco Meraki proporciona una prueba de RADIUS en el panel para la configuración inalámbrica documentada, aunque el botón de prueba no existe para las redes de las series MX o Z. Un tiempo de espera agotado significa que debe verificar la información actual del firewall del panel, las entradas del cliente RADIUS, la accesibilidad del host público, la alineación del secreto compartido y el comportamiento de la política. La comprobación de estado de Cisco Meraki envía solicitudes de acceso periódicas y considera que el servidor no está accesible después de seis intentos sin respuesta, con un intervalo de 20 segundos entre ellos. [4]

¿Cómo se aíslan los puntos de fallo comunes?

La frecuencia de la página de inicio (splash) parece incorrecta

Si la página de inicio aparece con menos frecuencia de la que sugiere la política, compruebe si el cliente ya estaba autorizado cuando cambió la frecuencia. Cisco Meraki indica que el periodo de autorización existente sigue vigente. Revocar la autorización del cliente seleccionado permite realizar una prueba válida de la configuración actualizada. Si la página aparece con más frecuencia, compruebe 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 de nuevo 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 terminal controlado después de un cambio y, a continuación, medir el resultado en función de tres resultados sencillos: el cliente pasa a estar autorizado, recibe la expiración esperada y la siguiente solicitud HTTP nueva se comporta de la manera prevista. Ese es un mejor criterio de validación que preguntar en recepción si han cesado las quejas.

El WiFi de invitados no redirecciona

No afirme que HTTPS ha "roto" los Captive Portals. El comportamiento documentado de Cisco Meraki es más limitado: el mecanismo de redirección funciona con un HTTP GET no autorizado, mientras que una solicitud que prioriza 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 determinar si la rama de la red funciona. 1 [2]

Para un despliegue ilustrativo en tiendas, el equipo de TI de una tienda puede reproducir la queja con un dispositivo de prueba del personal en el SSID de la tienda. La prueba de aceptación no es una vaga afirmación de carga de página. Registre el historial de asociación, la dirección válida, el estado no autorizado, el evento de 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 omisión. Revise primero el host de la página de inicio (splash) y, a continuación, las dependencias que realmente necesita su página de preautenticación. Cisco Meraki permite direcciones IP, rangos de IP y nombres de host, con dominios comodín. Cisco también requiere una URL de página de inicio (splash) personalizada o una dirección IP en el walled garden cuando dicha función está habilitada. [3]

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

El portal de inicio de sesión agota el tiempo de espera o rechaza las credenciales

Diferencie un rechazo de un 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 conectar" apunta en primer lugar a la capacidad de conexión entre el Dashboard y el servidor RADIUS configurado. Cisco Meraki documenta que las solicitudes del portal de inicio de sesión se originan en la nube del Dashboard y no pueden utilizar una dirección LAN privada para el servidor RADIUS. [4]

Confirme que el servidor espera PAP para este modo de portal, que los rangos de origen documentados de 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 señala que la integración del portal externo debe utilizar la login_url suministrada sin modificaciones, y que el filtrado debe permitir su nombre de host variable en lugar de un único patrón fijo. [4]

¿Qué significan los eventos del portal Meraki en el registro de eventos?

Lea el registro como una línea de tiempo. Asociación 802.11 significa que el cliente se unió a un AP. No significa que el cliente tenga una dirección, haya llegado a la página del portal o haya obtenido acceso a internet. Un evento de Auth es la categoría de evento para la autenticación de la página del portal. Un evento de DHCP cerca de la misma hora puede trasladar la investigación al direccionamiento. Un evento de 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 página de portal de inicio de sesión. Cisco Meraki identifica los mensajes de 802.1X y RADIUS para SSID de WPA2-Enterprise. Su documentación separada de RADIUS para el portal de inicio de sesión describe PAP entre la nube del Dashboard y su servidor RADIUS. En esta guía, utilice las categorías de asociación, Auth, DHCP y RADIUS para localizar la etapa que falla. 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 en la página de bienvenida a través de su Dashboard API documentada. El registro incluye la hora de inicio de sesión, el SSID, la MAC del dispositivo de puerta de enlace, 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 de la incidencia con un resultado de autenticación sin tener que tratar una anécdota como evidencia de un incidente. [9]

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

Mantenga un breve libro de ruta operativo junto al propietario del servicio de Guest WiFi . El libro de ruta debe identificar el SSID de prueba, el dispositivo de prueba, el procedimiento de revocación de autorización, el alojamiento de la página esperado, las dependencias de preautenticación, la propiedad de RADIUS y el contacto de escalada. 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 en la nube no está disponible. [3]

Para las instalaciones que utilizan un Captive Portal para el consentimiento, la marca y la política de acceso, trate la página sin conexión como un componente de aplicación controlado. Purple proporciona tipos de páginas sin conexión, en línea y fuera de horario. Utilice la guía publicada de Splash Pages para los cambios en el proceso 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 recurrente en el establecimiento, centralice las pruebas 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 sectores de Hospitality , Retail y Transport , donde los equipos locales necesitan un límite de escalada claro y el equipo de red necesita pruebas reproducibles. 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 despliegues de WiFi de invitados que se superponen a la infraestructura existente, incluyendo Cisco Meraki. Esta guía cubre el diagnóstico del día dos de un fallo en la página de bienvenida de Meraki. No sustituye el trabajo de diseño e incorporación necesario para un nuevo Captive Portal. Utilice la guía publicada de Purple Splash Pages para conocer los tipos de páginas compatibles y los cambios en el proceso de acceso. [7]

¿Cuánto trabajo se requiere para migrar una página de bienvenida 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 host de la página actual, las entradas de 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 bienvenida estándar y HTML, incluyendo recursos cargados y vista previa en tiempo real. Planifique la migración como un cambio controlado, no como la solución de un incidente. [7] [8]

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

No. Cisco Meraki documenta que su redirección de página de bienvenida comienza cuando un cliente no autorizado envía un HTTP GET. El tráfico que prioriza HTTPS está cifrado y no puede redirigirse mediante ese mecanismo. Realice pruebas con un destino HTTP y luego diferencie el comportamiento del navegador del cliente de un fallo de la página de bienvenida en toda la red. 1 [2]

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

El walled garden debe permitir la dirección IP o la URL de la página de bienvenida personalizada cuando esté habilitada. A continuación, permita únicamente los endpoints de preautenticación adicionales que la página requiera realmente. Cisco Meraki admite direcciones IP, rangos y nombres de host, incluyendo dominios comodín. No sustituya esa revisión por un acceso a internet sin restricciones. [3]

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

Un tiempo de espera de espera agotado suele significar que la nube de Cisco Meraki Dashboard no puede obtener una respuesta del servidor RADIUS configurado. Compruebe la accesibilidad pública, los rangos de origen actuales de Dashboard, las claves compartidas de cliente RADIUS coincidentes y la compatibilidad con PAP. El AP o MX local no es el origen de las solicitudes RADIUS de la página de bienvenida. [4]

¿Cómo supervisamos los fallos de inicio de sesión en la página de bienvenida en varios centros?

Utilice el registro de eventos de Meraki para filtrar el cliente afectado y la ventana de tiempo, y luego correlacione las categorías de autenticación, DHCP y RADIUS. La API de intentos de inicio de sesión de la página de bienvenida de Cisco puede devolver la hora de inicio de sesión, el SSID, el dispositivo de puerta de enlace, el identificador de cliente y el estado de autorización. Esto crea un registro de pruebas consistente para un servicio de soporte multi-sitio. [5] [9]

Referencias

[2]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Troubleshooting_and_Support/Troubleshooting/Troubleshooting_Splash_Page_Appearance_Frequency "Cisco Meraki: Troubleshooting Splash Page Appearance Frequency"[3]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Configuration_Guides/Splash_Page_Configuration/Splash_Page_Overview "Cisco Meraki: descripción general de la Splash Page" [4]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Configuration_Guides/Splash_Page_Configuration/Configuring_RADIUS_Authentication_with_a_Sign-on_Splash_Page "Cisco Meraki: configuración de la autenticación RADIUS con una Splash Page de inicio de sesión" [5]: https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Operate_and_Maintain/Monitoring_and_Reporting/Meraki_Event_Log "Cisco Meraki: cómo usar el Meraki Event Log" [6]: https://documentation.meraki.com/Wireless/Troubleshooting_and_Support/Troubleshooting/Common_Wireless_Event_Log_Messages_and_Issues "Cisco Meraki: problemas y mensajes comunes del Wireless Event Log" [7]: https://support.purple.ai/hc/en-gb/articles/7330834125085-Splash-Pages "Purple: Splash Pages" [8]: https://support.purple.ai/hc/en-gb/articles/7330855745949-Splash-Page-Editor-HTML "Purple: editor de Splash Pages - HTML" [9]: https://developer.cisco.com/meraki/api-v1/get-network-splash-login-attempts/ "Cisco Meraki Dashboard API: obtener intentos de inicio de sesión de la Splash Page de red"}