Resolución de problemas de Captive Portal de Cisco Meraki: lista de verificación para splash page, walled garden y RADIUS

Un captive portal de Meraki que falla suele tener uno de cuatro problemas. El tipo de splash page es incorrecto, o al walled garden le faltan los dominios y recursos del portal. El traspaso de la URL de concesión puede estar roto, o los puntos de acceso no pueden comunicarse con RADIUS con un secreto compartido coincidente. El registro de eventos de Meraki muestra qué fallo tiene.

¿Cómo se ve un captive portal de Meraki que no funciona?

Tres síntomas cubren la mayoría de los tickets de soporte. Cada uno apunta a un eslabón diferente en la cadena de inicio de sesión.

• La splash page nunca aparece. El dispositivo se une al SSID y obtiene una dirección IP, pero no se abre ninguna ventana de inicio de sesión.
• El portal entra en bucle. El invitado completa el formulario, toca conectar y vuelve a la página de inicio de sesión.
• El portal acepta los datos pero nunca concede acceso. La página informa que el proceso fue exitoso, pero el dispositivo sigue cautivo.

Un cuarto síntoma es más silencioso. A los invitados recurrentes se les pide que inicien sesión con mucha más frecuencia de la esperada. Eso rara vez es un fallo del portal. Por lo general, se trata de la configuración de la frecuencia de la splash page.

Antes de cambiar algo, confirme cómo debería funcionar la cadena. En una implementación de Purple, el punto de acceso de Meraki redirige el dispositivo a los servidores de la splash page de Purple. La splash page recopila los datos del invitado y emite un inicio de sesión de un solo uso. Luego, el punto de acceso pasa ese inicio de sesión al servidor RADIUS de Purple para completar la autenticación. El artículo de soporte del captive portal de Purple describe este flujo. Cada síntoma se asocia con el fallo de uno de esos tres traspasos.

Esta guía asume que el SSID ya está creado. Complementa la guía de configuración del captive portal de Meraki y no repite los pasos de configuración.

¿Qué suele causar que una splash page de Meraki no se muestre o entre en bucle?

El tipo de splash page no coincide con el portal

Meraki ofrece opciones de click-through, inicio de sesión con un servidor RADIUS y opciones de captive portal externo. El portal y el SSID deben esperar el mismo método.

Un portal externo click-through libera el dispositivo llamando a una URL de concesión. Un portal externo de inicio de sesión envía las credenciales, que el punto de acceso verifica contra RADIUS. Si el SSID y el portal no coinciden, el traspaso falla y el invitado entra en bucle.

El walled garden está incompleto

El walled garden enumera los destinos a los que un dispositivo puede acceder antes de autenticarse. Meraki acepta entradas como dominios o rangos de IP. Si falta el propio dominio del portal, la splash page no se puede cargar en absoluto.

La falta de recursos causa fallos más sutiles. Las hojas de estilo, imágenes, fuentes, redes de entrega de contenido y proveedores de inicio de sesión social se cargan desde sus propios servidores. Si alguno está bloqueado, la página se visualiza rota o el botón de inicio de sesión no hace nada.

El walled garden también puede ser demasiado permisivo. Los dispositivos ejecutan un Asistente de Red Cautiva (CNA), que verifica un dominio predefinido para probar el acceso a Internet. Si ese dominio de prueba es accesible antes del inicio de sesión, el dispositivo concluye que está en línea. Por lo tanto, nunca muestra la ventana de inicio de sesión.

La URL de concesión o la URL de continuación se ha perdido

Con un captive portal externo, Meraki agrega parámetros a la redirección. Estos incluyen una URL de concesión base (grant URL) y la URL de continuación que el invitado solicitó originalmente. El portal debe enviar el dispositivo de regreso a la URL de concesión para liberarlo.

Si el portal descarta, sobreescribe o almacena en caché esos parámetros, el punto de acceso nunca recibe la concesión. El invitado ve un mensaje de éxito, pero luego la siguiente carga de página lo redirige nuevamente a la página de inicio de sesión.

El servidor RADIUS no está disponible o el secreto compartido es incorrecto

El inicio de sesión con RADIUS depende de que los puntos de acceso se comuniquen con el servidor RADIUS. RADIUS es el protocolo Remote Authentication Dial-In User Service, definido en la norma RFC 2865. El servidor trata a cada remitente como un cliente RADIUS y verifica un secreto compartido en cada solicitud.

Predominan dos fallas: un firewall bloquea el tráfico RADIUS desde los puntos de acceso, o el secreto compartido difiere entre el dashboard y el servidor. En cualquiera de los casos, el portal recopila los datos pero la autenticación nunca se completa.

El modo NAT y el modo bridge cambian los puntos a verificar

En el modo NAT, el punto de acceso asigna las direcciones de los clientes por sí mismo. Los dispositivos de red ascendentes ven el tráfico proveniente del punto de acceso, no del cliente. En el modo bridge, los clientes obtienen las direcciones de su propio servidor DHCP en su LAN o VLAN.

El modo bridge añade puntos de falla que quedan bajo su responsabilidad. Estos incluyen un alcance DHCP agotado, una VLAN que no se conecta mediante trunking al punto de acceso, y reglas de DNS ascendentes o de firewall que bloquean los hosts del portal.

¿Cómo identificar cuál es la causa del problema?

Trabaje desde el cliente hacia afuera. Realice pruebas con un solo dispositivo y borre la red de la memoria entre intentos para que cada prueba comience desde cero.

Síntoma	Qué muestra el registro de eventos	Causa más probable	Primera verificación
No aparece la página de bienvenida	Asociación, pero sin redirección a la página de bienvenida	Dominio de prueba del CNA accesible, o falla de DHCP o DNS	Confirme que el dispositivo tenga una IP y DNS, luego abra neverssl.com
Página de bienvenida en blanco o sin estilo	Redirección a la página de bienvenida, pero página incompleta	Faltan los hosts de recursos en el walled garden	Herramientas de desarrollador del navegador, liste cada host bloqueado
Bucle infinito después de enviar	Redirecciones repetidas a la página de bienvenida, sin concesión	Pérdida de parámetros de la URL de concesión, o discrepancia en el tipo de página de bienvenida	Compare la cadena de consulta de redirección con lo que devuelve el portal
Mensaje de éxito, sin internet	Intentos de autenticación que fallan o expiran	RADIUS bloqueado o discrepancia en el secreto compartido	Registros del servidor RADIUS para buscar solicitudes desde los puntos de acceso
Se vuelve a solicitar acceso a invitados recurrentes	Nuevos eventos de página de bienvenida para dispositivos conocidos	Frecuencia de la página de bienvenida demasiado corta	Configuración de frecuencia de la página de bienvenida en el SSID
Advertencia de certificado en computadora de escritorio	La redirección se completa	Página de inicio de sesión provista a través de HTTP	Certificado en el host del portal

Lectura del registro de eventos de Meraki

Abra el registro de eventos de red en el dashboard de Meraki y filtre por la dirección MAC del dispositivo de prueba. Luego, filtre por los tipos de eventos de página de bienvenida y autenticación.

Lea los eventos en orden cronológico: asociación, asignación de dirección, redirección de splash, autenticación. El punto donde se detiene la secuencia es donde se encuentra la falla. Si no hay evento de splash, significa que la redirección nunca se activó. Un evento de splash sin evento de autenticación apunta al portal o a la URL de concesión. Un evento de autenticación fallido apunta a RADIUS.

¿Cómo se soluciona en las redes Meraki MR y dispositivos cliente?

Siga los pasos del proveedor en el artículo de soporte del portal cautivo de Purple. Las siguientes soluciones le indican qué cambiar y por qué.

Corregir el walled garden

Cargue la página de splash en un dispositivo fuera de la red de invitados, con las herramientas de desarrollador abiertas. Registre cada host al que llama la página, incluidos los proveedores de inicio de sesión social. Agregue cada uno al walled garden como un dominio o rango de IP. Elimine cualquier elemento que coincida con un dominio de prueba de CNA.

Corregir la transferencia de la URL de concesión

Capture la URL de redirección completa de un dispositivo que esté fallando. Confirme que el portal devuelva el dispositivo a la URL de concesión base con los parámetros intactos. Verifique que ningún proxy, acortador de enlaces o caché se encuentre entre el portal y el dispositivo.

Corregir RADIUS

Confirme que los puntos de acceso puedan comunicarse con el servidor RADIUS en los puertos configurados. Vuelva a introducir el secreto compartido en ambos lados, desde una misma copia, al mismo tiempo. Luego, revise el registro del servidor para ver las solicitudes que llegan desde las direcciones de los puntos de acceso.

Corregir el comportamiento del cliente

Android muestra una notificación de "es posible que deba iniciar sesión" que abre el CNA. Algunos fabricantes de dispositivos modifican este comportamiento, por lo que se recomienda realizar pruebas en los modelos que utilizan sus invitados. Si un invitado no ve el aviso, Purple recomienda abrir un navegador y visitar neverssl.com. Ese sitio evita problemas de redirección de SSL porque nunca utiliza HTTPS.

Los navegadores de escritorio advierten cuando se ofrece una página de inicio de sesión a través de HTTP simple. El artículo sobre certificados de Cisco WLC de Purple cubre la falla equivalente en los Cisco WLCs. La solución allí es un certificado de confianza pública cuyo Common Name coincida con el nombre de host del portal. El mismo principio se aplica a cualquier host de portal.

Otros proveedores

Purple es independiente del hardware. Las mismas comprobaciones se aplican en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo difieren los nombres de los menús.

Dos escenarios de ejemplo reales

Un hotel de 200 habitaciones después de un rediseño del portal

Situación. Un establecimiento del sector de hospitalidad en el centro de la ciudad actualizó su página de splash con nuevas fuentes y un botón de inicio de sesión social. Después de esto, los huéspedes veían una página en blanco sin botón de inicio de sesión.

Qué se hizo. El equipo de TI cargó la nueva página con las herramientas de desarrollador abiertas y encontró dos hosts bloqueados. Uno era una red de distribución de fuentes. El otro era el proveedor de inicio de sesión social. Ambos se agregaron al walled garden.

Resultado. La página se procesó por completo en la siguiente prueba. Las quejas en la recepción sobre el acceso de los huéspedes cesaron el mismo día.

Una cadena minorista de 40 tiendas después de un cambio de firewall

Situación. Una cadena de retail restringió el firewall de su oficina central. A la mañana siguiente, los compradores de todas las tiendas veían la página de éxito pero no podían navegar.

Qué se hizo. El registro de eventos mostró tiempos de espera agotados en la autenticación en todos los sitios. La nueva regla había bloqueado el tráfico RADIUS de los puntos de acceso de la tienda. El equipo restableció la regla únicamente para los puertos RADIUS.

Resultado. Los eventos de autenticación volvieron a la normalidad en las 40 tiendas a la hora siguiente del cambio.

¿Cómo evitar que vuelvan a ocurrir fallas en el Captive Portal de Meraki?

• Vincule el walled garden a los cambios del portal. Cada cambio de diseño activa una revisión del walled garden antes del lanzamiento.
• Mantenga el SSID abierto. Purple recomienda una red abierta para el acceso de invitados, ya que la convención es familiar y reduce la fricción.
• Rotar secretos compartidos en parejas. Cambie el dashboard y el servidor RADIUS en una sola ventana de mantenimiento.
• Pruebe en cuatro plataformas. Android, iOS, Windows y macOS manejan el CNA de manera diferente.
• Use un certificado de confianza. Ofrezca la página de inicio de sesión a través de HTTPS con un certificado de confianza pública.
• Separe al personal de los invitados. El personal debe autenticarse por identidad, no a través de una página de bienvenida para invitados. Consulte Cómo habilitar el inicio de sesión único.

Purple opera Guest WiFi en más de 80,000 ubicaciones activas y procesó 440 millones de inicios de sesión en 2024 (datos propios de Purple). La misma lista de verificación se aplica en centros de transporte que atienden a pasajeros y en sitios de atención médica que atienden a pacientes y visitantes.

Preguntas frecuentes

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

Sí, Purple se ejecuta en sus puntos de acceso Cisco Meraki MR existentes como una superposición en la nube. Solo tiene que apuntar la página de bienvenida del SSID a Purple y configurar los detalles de RADIUS de Purple en el dashboard de Meraki. No se necesita hardware nuevo. El artículo de soporte del Captive Portal de Purple cubre los pasos de configuración. El mismo enfoque funciona en el resto de una infraestructura mixta.

¿Puede Purple operar Guest WiFi en una infraestructura de múltiples proveedores?

Sí, Purple es independiente del hardware y es compatible con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Usted administra una sola página de bienvenida y un solo flujo de inicio de sesión para todos los proveedores desde una sola plataforma. Esto es ideal para grupos que han adquirido sitios con hardware diferente. También se adapta a infraestructuras que planean reemplazar puntos de acceso de manera gradual en lugar de hacerlo en un solo proyecto.

¿El acceso de invitados debe ejecutarse en un SSID abierto o en uno seguro?

Purple recomienda un SSID abierto para el acceso de invitados, ya que ahora es la convención estándar y los invitados la reconocen. El Captive Portal se encarga del paso de inicio de sesión, por lo que los invitados no necesitan una contraseña antes de conectarse. Una red abierta reduce la fricción en el punto de conexión. Mantenga los dispositivos del personal en una red separada basada en la identidad en lugar de compartir el SSID de invitados.

¿Los datos de los invitados capturados a través de la página de inicio cumplen con el GDPR?

Sí, Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials, y opera de acuerdo con el GDPR y la CCPA. Los invitados otorgan su consentimiento de manera consciente en la página de inicio, por lo que el consentimiento de marketing es explícito. Los datos que recopila son datos de primera mano, propiedad de su organización. Purple también es una empresa certificada B Corp. Asegúrese de que su propio aviso de privacidad coincida con los campos que recopila su página de inicio.

¿Por qué los navegadores de escritorio muestran una advertencia de certificado antes de la página de inicio de sesión?

Los navegadores de escritorio muestran una advertencia cuando el portal redirige a una página de inicio de sesión a través de HTTP estándar. Los navegadores modernos esperan que las páginas de inicio de sesión utilicen HTTPS, por lo que marcan la conexión como no privada. La solución es un certificado SSL/TLS de confianza pública en el servidor del portal. El Nombre Común del certificado debe coincidir con el nombre de host que utiliza la redirección. La advertencia no bloquea el acceso, pero debilita la confianza del invitado.

¿Quién se encarga de la autenticación RADIUS cuando Purple aloja el portal?

El servidor RADIUS de Purple completa el inicio de sesión. La página de inicio emite un inicio de sesión de un solo uso y el punto de acceso de Meraki lo transmite al servidor RADIUS de Purple. Debe ingresar los detalles de RADIUS de Purple y el secreto compartido en el panel de Meraki. Su firewall debe permitir que el tráfico de RADIUS desde los puntos de acceso llegue a Purple. Si el secreto compartido no coincide en ambos extremos, la autenticación fallará.

¿Qué tanto esfuerzo requiere migrar de la página de inicio de Meraki a Purple?

La migración es un cambio de configuración en cada SSID, no un proyecto de hardware. Debe cambiar el tipo de página de inicio, agregar las entradas del walled garden e ingresar los detalles de RADIUS de Purple. La mayor parte del esfuerzo se destina a realizar pruebas en Android, iOS, Windows y macOS antes del lanzamiento. Planifique primero un sitio piloto y luego implemente la configuración probada en el resto de sus instalaciones.