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

Integración de Cisco Meraki con Purple WiFi - Sesión informativa para consultores sénior Tiempo de ejecución: aproximadamente 10 minutos INTRODUCCIÓN Y CONTEXTO (aproximadamente 1 minuto) Bienvenido. Si usted es responsable de una implementación de Cisco Meraki y está intentando decidir si Purple WiFi es la capa de inteligencia de visitas adecuada para complementar su infraestructura, esta sesión es para usted. Le explicaré exactamente cómo funciona la integración, qué necesita configurar, cuáles son los errores comunes y qué tipo de retorno de inversión debería esperar de manera realista. Permítame contextualizar. Cisco Meraki es, por un margen significativo, la infraestructura inalámbrica administrada en la nube más implementada en el sector empresarial de hospitalidad, retail y sector público. Es confiable, escalable y su panel en la nube es genuinamente excelente. Pero el detalle es este: las capacidades nativas de WiFi para invitados de Meraki son funcionales, no estratégicas. Puede conectar a un invitado a internet, pero no puede capturar datos de primera mano valiosos, no puede crear un embudo de marketing a partir de ello y ciertamente no puede demostrar el ROI a su junta directiva. Ese es precisamente el vacío que llena Purple. ANÁLISIS TÉCNICO PROFUNDO (aproximadamente 5 minutos) Hablemos de arquitectura. La integración de Purple y Meraki opera a través de dos capas técnicas distintas, y entender ambas es esencial antes de modificar una sola opción de configuración. La primera capa es la API del panel de Meraki; esta es la capa de aprovisionamiento. Purple utiliza la API REST de Meraki para importar todo su parque de puntos de acceso al Purple Hub en una sola operación por lotes. Usted se autentica con su clave de API de Meraki, la cual genera desde la sección de Organización del panel de Meraki bajo 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 desde 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. Ese no es un ahorro operativo menor. La segunda capa es la capa de autenticación y de Captive Portal; aquí es donde realmente vive la experiencia del invitado. Purple opera como un proveedor externo de páginas de bienvenida, utilizando la API de Captive Portal de Meraki. Cuando un invitado se conecta a su SSID de invitados, Meraki intercepta su tráfico HTTP y lo redirige a la página de bienvenida alojada por Purple: su Captive Portal personalizado con su marca. El invitado se autentica mediante el método que usted haya configurado: inicio de sesión con redes sociales, formulario de correo electrónico, verificación por SMS o una combinación de estos. Luego, Purple se comunica de vuelta con Meraki a través de RADIUS (Remote Authentication Dial-In User Service), operando en el puerto 1812 para autenticación y en el puerto 1813 para contabilidad. Una vez que RADIUS confirma la autenticación, Meraki otorga al invitado acceso completo a la red. Ahora, permítame guiarlo a través de la configuración específica en el panel de Meraki, porque los detalles aquí son importantes. En el panel de control 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í, abierta, porque la autenticación se maneja mediante la capa de RADIUS y el captive portal, no al nivel de asociación 802.11. Establezca el tipo de página de inicio (splash page) en Sign-on con mi servidor RADIUS. Esta es la selección crítica: le indica a Meraki que use un servidor RADIUS externo para la autenticación en lugar de sus propias opciones integradas. En Advanced Splash Settings, establezca la seguridad del captive portal en Block all access until sign-on is complete. Habilite el walled garden: esta es la lista de dominios a los que los invitados pueden acceder antes de autenticarse, la cual debe incluir los dominios de la plataforma de Purple para que la página de inicio 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á agregar dos servidores; Purple proporciona endpoints primarios y secundarios para redundancia. El puerto de autenticación es 1812 y utilizará el secreto de RADIUS proporcionado en su Purple Hub. Agregue las entradas correspondientes para la contabilidad de RADIUS (accounting) en el puerto 1813. Establezca el intervalo interino de contabilidad en cuatro minutos; esto es importante para un seguimiento de sesión y analíticas precisos. 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 usar la dirección MAC del AP. Esto es fundamental para las analíticas de ubicación de Purple; sin esto, Purple no puede atribuir de manera precisa las sesiones a puntos de acceso específicos y, por lo tanto, no puede generar analíticas de piso significativas. Luego navegue a Wireless, Splash Page. Ingrese la URL de inicio personalizada provista por su Purple Hub; esta es la URL de su captive portal personalizado. Configure la URL de redireccionamiento posterior a la autenticación, que generalmente es el sitio web de su establecimiento o una página de destino específica. Ahora bien, 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 (por lo general llamado PurpleConnex) configurado como una red WPA2 Enterprise que utiliza los servidores RADIUS RadSec de Purple. RadSec es RADIUS sobre TLS, lo que proporciona un transporte cifrado para el tráfico de autenticación. Este SSID, combinado con la configuración de 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 otra vez. Su dispositivo reconoce el perfil de Passpoint y se conecta sin problemas. Esto es particularmente valioso en entornos donde se desea eliminar la fricción de repetir la autenticación, como un hotel donde un huésped se hospeda por tres noches o un miembro de un programa de lealtad minorista que realiza visitas semanales. La configuración de Hotspot 2.0 en Meraki requiere que establezca el nombre del operador como PURPLE dos puntos GB, configure la lista de dominios como securewifi.purple.ai y agregue los OI de Roaming Consortium que Purple especifica. 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 muy sencillo una vez que comprende la función de cada campo. RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES (aproximadamente 2 minutos) Permítame compartirle los tres modos de falla 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 inicio de sesión rota - el CSS no se cargará, las imágenes no se procesarán y la autenticación fallará de forma silenciosa. Purple mantiene una lista de permitidos actualizada con los dominios requeridos. Trate esta lista como un documento dinámico y revísela cada vez que Purple lance una actualización de la plataforma. Recomiendo probar la experiencia de Captive Portal desde un dispositivo invitado en un segmento de red independiente antes del lanzamiento oficial. Segundo: ajustes de tiempo de espera de RADIUS. El tiempo de espera de RADIUS predeterminado de 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á fallas de autenticación intermitentes durante las horas pico de carga - justo el peor momento para que la experiencia de sus invitados se degrade. Tercero: configuración incorrecta de NAS-ID y Called-Station-ID. Este es el error que más suele tomar por sorpresa a los ingenieros. Si configura estos campos de forma incorrecta - o los deja con los valores predeterminados - el motor de analítica de Purple no podrá mapear las sesiones con puntos de acceso específicos. Obtendrá datos agregados pero ninguna inteligencia a nivel de piso. El valor debe establecerse como dirección MAC del AP, no como el nombre del SSID ni ninguna otra opción. En cuanto al cumplimiento normativo: la captura de datos de Purple cumple con GDPR y CCPA por diseño. El Captive Portal presenta un mecanismo de consentimiento que cumple con los requisitos de ambas regulaciones. Si opera en un entorno dentro del 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 separada 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 nivel de aislamiento, pero su arquitectura de segmentación de red debe ser revisada de forma independiente por su equipo de seguridad. PREGUNTAS Y RESPUESTAS RÁPIDAS (aproximadamente 1 minuto) Pregunta: ¿Puede Purple integrarse con los dispositivos de seguridad Meraki MX además de con los AP inalámbricos? Respuesta: Sí. El proceso de configuración es esencialmente idéntico - el MX admite la misma página de inicio de sesión y configuración de RADIUS que los AP inalámbricos. El artículo de soporte cubre las configuraciones de AP, MX y el gateway de teletrabajador Z1. Pregunta: ¿Cuánto tiempo toma una implementación completa para un grupo hotelero de 50 sitios? Respuesta: Con el aprovisionamiento automatizado a través de la API de Meraki, la importación de puntos de acceso es una sola operación por organización. La configuración de SSID y RADIUS se puede estructurar con plantillas en todas las redes. Un despliegue de 50 sitios con un ingeniero de redes competente debería completarse en dos o tres días de trabajo de configuración, más el tiempo de pruebas. Pregunta: ¿Soporta Purple los puntos de acceso WiFi 6 y WiFi 6E más recientes de Meraki? Respuesta: Sí. La integración opera en la capa de aplicación - RADIUS y redireccionamiento HTTP - por lo que es independiente de la generación de hardware. Purple funciona con cualquier AP de Meraki que soporte la página de inicio y la configuración de RADIUS descrita. RESUMEN Y PRÓXIMOS PASOS (aproximadamente 1 minuto) En resumen: la integración de Cisco Meraki y Purple WiFi es un despliegue maduro y bien documentado que combina la excelente infraestructura administrada en la nube de Meraki con las capacidades de captura de datos e inteligencia de invitados de Purple. La integración utiliza dos mecanismos principales - la API del Dashboard de Meraki para el aprovisionamiento automatizado, y la API de Captive Portal con autenticación RADIUS para la capa de experiencia del invitado. Las tres cosas que se deben configurar correctamente son: la configuración de su walled garden (lista blanca), la configuración de reintentos y tiempo de espera de RADIUS, y su configuración de NAS-ID para un análisis de ubicación preciso. El caso de negocio es convincente. McDonald's Belgium, Walmart Canada y Harrods son despliegues activos de Purple y Cisco. AGS Airports logró un retorno de inversión del 842 por ciento. Harrods convirtió 600,000 inicios de sesión de WiFi en un retorno de inversión de 57 veces. Si está listo para avanzar, el siguiente paso es generar su clave API de Meraki, iniciar sesión en el Purple Portal y usar el Asistente de importación de hardware para cargar su parque de puntos de acceso. Desde allí, el equipo de su cuenta de Purple puede guiarlo a través de la configuración de SSID y RADIUS en una sola sesión. Muchas gracias por su tiempo.