Cisco Meraki y WiFi de invitados: configuración de captive portal con Purple

Integración de Cisco Meraki con Purple WiFi - Un resumen para consultores sénior Duración: aproximadamente 10 minutos INTRODUCCIÓN Y CONTEXTO (aproximadamente 1 minuto) Le damos la bienvenida. Si es responsable de una implantación de Cisco Meraki y está intentando decidir si Purple WiFi es la capa de inteligencia de visitas adecuada para complementarla, este resumen es para usted. Le guiaré exactamente por cómo funciona la integración, qué necesita configurar, cuáles son los errores comunes y qué tipo de retorno puede esperar de forma realista. Permítame situarle. Cisco Meraki es, por un margen significativo, la infraestructura inalámbrica gestionada en la nube más ampliamente implantada en el sector empresarial de la hostelería, el comercio minorista y el sector público. Es fiable, escalable y su panel de control en la nube es realmente excelente. Pero ahí está el detalle: las capacidades de WiFi de visitas nativas de Meraki son funcionales, no estratégicas. Puede conectar a un usuario visitante, pero no puede capturar datos de origen significativos, no puede crear un embudo de marketing a partir de ello y, por supuesto, no puede demostrar el ROI a su junta directiva. Ese es precisamente el vacío que llena Purple. ANÁLISIS TÉCNICO DETALLADO (aproximadamente 5 minutos) Hablemos de arquitectura. La integración de Purple y Meraki funciona a través de dos capas técnicas distintas, y entender ambas es fundamental antes de modificar un solo ajuste de configuración. La primera capa es la API del panel de control de Meraki; esta es la capa de aprovisionamiento. Purple utiliza la API REST de Meraki para importar todo su parque de puntos de acceso en el Portal de Purple en una sola operación por lotes. Se autentica con su clave de API de Meraki, que se genera desde la sección Organización del panel de control de Meraki, en la pestaña de API y Webhooks. Una vez que Purple tiene esa clave, puede extraer cada punto de acceso, cada red y cada configuración de SSID directamente de su nube de Meraki. Para un parque de, por ejemplo, trescientos puntos de acceso en un grupo hotelero, esto reduce lo que sería un ejercicio de configuración manual de varios días a algo que puede completar en menos de una hora. No es un ahorro operativo insignificante. La segunda capa es la de autenticación y del portal cautivo; aquí es donde reside realmente la experiencia del usuario visitante. Purple funciona como un proveedor externo de páginas de inicio de sesión (splash page) utilizando la API de Captive Portal de Meraki. Cuando un visitante se conecta a su SSID de visitas, Meraki intercepta su tráfico HTTP y lo redirige a la página de inicio de sesión alojada por Purple, su Captive Portal personalizado. El visitante se autentica mediante el método que haya configurado: inicio de sesión social, formulario de correo electrónico, verificación por SMS o una combinación de ellos. A continuación, Purple se comunica de vuelta con Meraki a través de RADIUS (Remote Authentication Dial-In User Service), que funciona en el puerto 1812 para la autenticación y en el puerto 1813 para la contabilidad. Una vez que RADIUS confirma la autenticación, Meraki concede al visitante acceso total a la red. Ahora, permítame guiarle a través de la configuración específica del panel de control de Meraki, porque los detalles importan en este punto. En el panel de Meraki, navegue a Wireless y luego a Access Control. Seleccione su SSID de invitados en el menú desplegable. Establezca la seguridad en Open - sí, abierto, porque la autenticación se gestiona en la capa de RADIUS y Captive Portal, no al nivel de asociación 802.11. Establezca el tipo de splash page en Sign-on with my RADIUS server. Esta es la selección crítica: le indica a Meraki que utilice un servidor RADIUS externo para la autenticación en lugar de sus propias opciones integradas. En Advanced Splash Settings, establezca la intensidad del Captive Portal en Block all access until sign-on is complete. Active el walled garden: esta es la lista de dominios a los que los invitados pueden acceder antes de autenticarse, que debe incluir los dominios de la plataforma de Purple para que la propia splash page pueda cargarse. Purple proporciona una lista blanca actualizada de estos dominios en su documentación de soporte. Para la configuración del servidor RADIUS, deberá añadir dos servidores: Purple proporciona endpoints primarios y secundarios para redundancia. El puerto de autenticación es 1812 y utilizará el secreto RADIUS proporcionado en su Purple Portal. Añada las entradas correspondientes para RADIUS accounting en el puerto 1813. Establezca el intervalo intermedio de contabilidad (accounting interim interval) en cuatro minutos - esto es importante para un seguimiento y análisis precisos de las sesiones. Establezca el tiempo de espera del servidor en cinco segundos con un recuento de tres intentos. En Advanced RADIUS Settings, configure el Called-Station-ID y el NAS-ID para utilizar la dirección MAC del AP. Esto es crítico para los análisis de ubicación de Purple - sin ello, Purple no puede atribuir con precisión las sesiones a puntos de acceso específicos y, por lo tanto, no puede generar análisis significativos a nivel de planta. A continuación, navegue a Wireless, Splash Page. Introduzca la URL de splash personalizada proporcionada por su Purple Portal - esta es la URL de su Captive Portal de marca. Configure la URL de redirección posterior a la autenticación; normalmente el sitio web de su establecimiento o una página de destino específica. Ahora, hay un segundo componente que vale la pena analizar en detalle: PurpleConnex, que es la solución SecurePass de Purple. Esto crea un segundo SSID - normalmente llamado PurpleConnex - configurado como una red WPA2 Enterprise que utiliza los servidores RADIUS RadSec de Purple. RadSec es RADIUS sobre TLS, lo que proporciona transporte cifrado para el tráfico de autenticación. Este SSID, combinado con la configuración Hotspot 2.0 - también conocida como Passpoint, el estándar IEEE 802.11u - permite que los invitados que regresan se vuelvan a conectar automáticamente sin tener que ver el Captive Portal de nuevo. Su dispositivo reconoce el perfil Passpoint y se conecta sin problemas. Esto es especialmente valioso en entornos donde se desea eliminar la fricción de repetir la autenticación, como un hotel donde un huésped se aloja tres noches o un miembro de un programa de fidelización de tiendas que realiza visitas semanales. La configuración de Hotspot 2.0 en Meraki requiere establecer el nombre del operador como PURPLE dos puntos GB, configurar la lista de dominios como securewifi.purple.ai y añadir los OI de Roaming Consortium que especifique Purple. El NAI Realm se configura con el método de autenticación EAP-TTLS y PAP. Todo esto está documentado en el portal de soporte de Purple, y es un proceso sencillo una vez que se entiende la función de cada campo. RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aproximadamente 2 minutos) Permítame detallar los tres modos de fallo más comunes que observo en las implementaciones de Meraki y Purple, y cómo evitarlos. Primero: configuración incorrecta del walled garden. Si su lista de walled garden está incompleta, los invitados verán una página de bienvenida defectuosa - el CSS no se cargará, las imágenes no se mostrarán y la autenticación fallará de forma silenciosa. Purple mantiene una lista de dominios permitidos requeridos actualizada. Trate esta lista como un documento dinámico y revísela siempre que Purple publique una actualización de la plataforma. Recomiendo probar la experiencia del Captive Portal desde un dispositivo de invitado en un segmento de red independiente antes de la puesta en marcha. Segundo: ajustes de tiempo de espera (timeout) de RADIUS. El tiempo de espera de RADIUS predeterminado en Meraki suele ser demasiado bajo para los servidores RADIUS alojados en la nube. Cinco segundos con tres intentos es la configuración correcta. Si lo deja en los dos segundos predeterminados, experimentará fallos de autenticación intermitentes durante las horas de máxima carga - precisamente el peor momento para que la experiencia de sus invitados empeore. Tercero: configuración incorrecta de NAS-ID y Called-Station-ID. Este es el punto que más suele pillar por sorpresa a los ingenieros. Si configura estos campos de forma incorrecta - o los deja por defecto - el motor de analítica de Purple no podrá asociar las sesiones a puntos de acceso específicos. Obtendrá datos agregados pero no inteligencia a nivel de planta. El valor debe establecerse en la dirección MAC del AP, no en el nombre del SSID ni en ninguna otra opción. En cuanto al cumplimiento normativo: la captura de datos de Purple cumple por diseño con el GDPR y la CCPA. El Captive Portal presenta un mecanismo de consentimiento que cumple los requisitos de ambas normativas. Si opera en un entorno bajo el alcance de PCI-DSS - por ejemplo, un hotel con una terminal de pago en el mismo segmento de red - asegúrese de que el SSID de invitados esté en una VLAN independiente con las reglas de firewall adecuadas. El modo NAT de Meraki para la asignación de IP de clientes, que es la configuración recomendada, proporciona cierto grado de aislamiento, pero la arquitectura de segmentación de su red debe ser revisada de forma independiente por su equipo de seguridad. PREGUNTAS Y RESPUESTAS RÁPIDAS (aproximadamente 1 minuto) Pregunta: ¿Puede integrarse Purple tanto con los dispositivos de seguridad Meraki MX como con los AP inalámbricos? Respuesta: Sí. El proceso de configuración es prácticamente idéntico - el MX admite la misma configuración de página de bienvenida y de RADIUS que los AP inalámbricos. El artículo de soporte cubre las configuraciones para AP, MX y la pasarela de teletrabajo Z1. Pregunta: ¿Cuánto tiempo requiere un despliegue completo para un grupo hotelero de 50 centros? Answer: With the automated provisioning via the Meraki API, the access point import is a single operation per organisation. The SSID and RADIUS configuration can be templated across networks. A 50-site deployment with a competent network engineer should be achievable in two to three days of configuration work, plus testing time. Question: Does Purple support Meraki's newer Wi-Fi 6 and Wi-Fi 6E access points? Answer: Yes. The integration operates at the application layer - RADIUS and HTTP redirect - so it is hardware-generation agnostic. Purple works with any Meraki AP that supports the splash page and RADIUS configuration described. SUMMARY AND NEXT STEPS (approximately 1 minute) To summarise: the Cisco Meraki and Purple WiFi integration is a mature, well-documented deployment that combines Meraki's excellent cloud-managed infrastructure with Purple's guest intelligence and data capture capabilities. The integration uses two primary mechanisms - the Meraki Dashboard API for automated provisioning, and the Captive Portal API with RADIUS authentication for the guest experience layer. The three things to get right are: your walled garden configuration, your RADIUS timeout and retry settings, and your NAS-ID configuration for accurate location analytics. The business case is compelling. McDonald's Belgium, Walmart Canada, and Harrods are all live Purple and Cisco deployments. AGS Airports achieved an 842 per cent return on investment. Harrods turned 600,000 WiFi logins into a 57 times return on investment. If you are ready to move forward, the next step is to generate your Meraki API key, log into the Purple Portal, and use the Hardware Import Wizard to pull in your access point estate. From there, your Purple account team can walk you through the SSID and RADIUS configuration in a single session. Thank you for your time.