Ver transcripción del podcast
Te damos la bienvenida a la serie de sesiones técnicas de Purple. Soy tu presentador y hoy vamos a tratar un tema que surge en casi todas las implementaciones de WiFi para invitados que realizamos a nivel empresarial: la configuración de un Captive Portal en los puntos de acceso Cisco Meraki MR, y concretamente cómo integrarlo con la plataforma en la nube de Purple mediante autenticación RADIUS. Tanto si eres un MSP que incorpora a un nuevo cliente de hostelería como si eres un arquitecto de red interno de una cadena de tiendas, este episodio te proporcionará los pasos de configuración precisos y el porqué de cada uno de ellos.
Pongámonos en situación. Tienes un espacio —puede ser un hotel, un centro de conferencias, un estadio o un parque comercial— que cuenta con puntos de acceso Cisco Meraki MR gestionados a través del panel de Meraki. El objetivo es implantar una experiencia de WiFi de invitados con imagen de marca que recopile datos de origen, obligue a aceptar las condiciones de servicio y envíe datos analíticos a una plataforma de marketing. Para eso es exactamente para lo que se ha creado Purple, y Meraki es una de nuestras implementaciones de hardware más habituales en todo el mundo.
Ahora bien, el punto clave de arquitectura que debes entender antes de tocar una sola configuración es el siguiente: en Cisco Meraki, la autenticación RADIUS para una página de bienvenida no la procesa localmente el punto de acceso. El RADIUS Access-Request se origina desde la nube de Meraki —desde la infraestructura del panel— y no desde el AP en tu LAN. Esta es una diferencia fundamental que pilla desprevenidos a muchos ingenieros en su primera implementación de Meraki. Significa que tu servidor RADIUS, en este caso el endpoint RADIUS en la nube de Purple, debe ser accesible desde internet, y tus reglas de firewall deben permitir el tráfico de los rangos de IP del panel de Meraki, no solo de la subred local de tu AP. Encontrarás los rangos de IP de panel actuales en la sección Ayuda, luego Información de firewall en tu panel de Meraki.
Bien, entremos en materia de configuración. Te guiaré por este proceso en el orden en que lo harías en una implementación real.
Paso uno: configuración del SSID. En el panel de Meraki, navega a Red inalámbrica, luego Configurar y, a continuación, SSIDs. Selecciona la ranura de SSID que deseas utilizar para el acceso de invitados. Asígnale un nombre claro, por ejemplo, GuestWiFi o NombreDelEstablecimiento guion bajo Guest. En Requisitos de asociación, establece la Seguridad en Abierta, sin cifrado. Esto es correcto e intencionado —la capa de seguridad para los invitados se gestiona mediante el Captive Portal y la autenticación RADIUS, no mediante el cifrado WPA. Si vas a realizar la implementación en un entorno PCI-DSS, deberás asegurarte de que el tráfico de invitados esté aislado en su propia VLAN, algo que trataremos en breve.
Paso dos: Página de inicio (splash page) y autenticación. En la misma página de Control de acceso para su SSID, desplácese hacia abajo hasta la sección Página de inicio (splash page). Establézcalo en Iniciar sesión con y, en el menú desplegable, seleccione mi servidor RADIUS. Este es el ajuste crítico que indica a Meraki que debe autenticar a los usuarios en un servidor RADIUS externo antes de conceder acceso a la red. Debajo de eso, verá la opción de Fuerza del portal cautivo. Establézcala en Bloquear todo el acceso hasta completar el inicio de sesión. Esto es lo que aplica el portal cautivo (walled garden); sin ello, los invitados podrían saltarse el portal por completo.
Paso tres: Configuración del servidor RADIUS. En la sección RADIUS, haga clic en Añadir servidor. Necesitará tres datos de su cuenta de Purple: la dirección IP o FQDN del servidor RADIUS, el puerto de autenticación (que es UDP 1812) y el secreto compartido. Purple proporciona estos datos en la sección de configuración de espacios del portal. Para garantizar la redundancia en despliegues de producción, debe añadir un servidor RADIUS secundario (Purple proporciona un punto de conexión de failover). Establezca el puerto de contabilidad (accounting) en UDP 1813 si desea que los datos de la sesión se envíen de vuelta al motor de analítica de Purple, algo que recomiendo encarecidamente para cualquier espacio donde el tiempo de permanencia y la duración de la sesión sean métricas relevantes.
Una breve nota sobre los atributos RADIUS. Meraki respeta el atributo Session-Timeout devuelto en la respuesta Access-Accept de RADIUS. Purple utiliza esto para controlar cuánto dura la sesión de un invitado antes de que se requiera una nueva autenticación. Para un hotel, puede establecerlo en 86.400 segundos (es decir, 24 horas). Para una cafetería, un valor de 3.600 segundos (una hora) es más adecuado. También se respeta el atributo Idle-Timeout, pero solo si la contabilidad (accounting) RADIUS está habilitada. Esto desconecta las sesiones inactivas, lo cual es importante para la gestión de la capacidad en espacios de alta densidad.
Paso cuatro: URL de la página de inicio (splash page). Diríjase a Red inalámbrica, luego a Configurar y después a Página de inicio (splash page). Seleccione su SSID de invitados en el menú desplegable. Establezca la URL de splash personalizada con la URL del portal de Purple de su espacio. Esta es la URL a la que Meraki redirigirá a los clientes no autenticados. Meraki añade parámetros de consulta a esta URL - incluyendo un parámetro login_url - que Purple utiliza para completar el protocolo de autenticación. No modifique ni elimine estos parámetros.
Paso cinco: El portal cautivo (walled garden). Aquí es donde la mayoría de los despliegues experimentan problemas. El portal cautivo (walled garden) es la lista de dominios y rangos de IP a los que un dispositivo invitado puede acceder antes de haberse autenticado. Sin las entradas correctas, la propia página del Captive Portal no se cargará, ya que se bloqueará el acceso del navegador a la CDN de Purple y a los proveedores de inicio de sesión social.
Vuelva a la sección de Control de acceso para su SSID de invitados. Establezca Walled garden en Walled garden está habilitado. En el campo Rango de walled garden, debe añadir lo siguiente. Primero, los dominios de la plataforma Purple: asterisco punto purple punto ai y asterisco punto venuewifi punto com. Segundo, los dominios de la CDN que Purple utiliza para servir los recursos del portal: asterisco punto cloudfront punto net y asterisco punto akamaihd punto net. Tercero, la infraestructura de redireccionamiento de Meraki: asterisco punto network-auth punto com. Cuarto, si ofrece opciones de inicio de sesión con redes sociales, necesitará los dominios de OAuth correspondientes. Para Google: accounts punto google punto com, asterisco punto googleapis punto com, asterisco punto gstatic punto com. Para Facebook: asterisco punto facebook punto com, asterisco punto fbcdn punto net y connect punto facebook punto net. Para Twitter o X: asterisco punto twitter punto com y asterisco punto twimg punto com.
Una nota importante sobre cómo gestiona Meraki los dominios con comodines en el walled garden. Meraki admite entradas con comodines utilizando el prefijo de asterisco, por ejemplo, asterisco punto cloudfront punto net. Sin embargo, se trata de una coincidencia basada en DNS: Meraki resuelve el dominio y permite las direcciones IP resultantes. Esto significa que para proveedores de CDN como CloudFront o Akamai, donde las IP resueltas pueden cambiar con frecuencia, debe utilizar el comodín de dominio en lugar de rangos de IP estáticos. Las entradas de IP estática son adecuadas para los endpoints RADIUS de Purple, que son estables, pero no para el tráfico de la CDN.
Ahora hablemos de dos escenarios del mundo real en los que he trabajado directamente.
El primero es un hotel de 350 habitaciones en el Reino Unido. El cliente utilizaba puntos de acceso Meraki MR46 en tres edificios, con unos 400 dispositivos de invitados simultáneos en las horas punta. El despliegue inicial utilizaba una página de bienvenida de un solo clic - sin RADIUS, solo aceptación de condiciones. El problema era que no tenían ninguna visibilidad de quién se conectaba, no capturaban correos electrónicos y no tenían forma de realizar campañas de marketing tras la estancia. Los migramos a Purple con un inicio de sesión basado en RADIUS. La configuración fue sencilla, pero el inconveniente fue que su firewall ascendente estaba bloqueando el UDP saliente en el puerto 1812 a cualquier cosa fuera de la subred local. Una vez que añadimos los rangos de IP del Dashboard de Meraki a la lista de permitidos del firewall, la autenticación funcionó de inmediato. Tras el despliegue, el hotel capturó las direcciones de correo electrónico de aproximadamente el 68 por ciento de los huéspedes que se conectaron en el primer mes, y su equipo de marketing realizó una campaña de reactivación que impulsó un aumento cuantificable de las reservas directas.
El segundo escenario es una cadena de tiendas con 45 establecimientos, cada uno de ellos con puntos de acceso Meraki MR33. El reto aquí era la escala y la consistencia. Configurar manualmente 45 SSID con los ajustes de RADIUS y las listas de walled garden correctos habría sido propenso a errores y habría consumido mucho tiempo. La solución fue utilizar la configuración basada en plantillas de Meraki. Creamos una única plantilla de red con los ajustes correctos de SSID, RADIUS y walled garden, y luego vinculamos las 45 redes de las tiendas a esa plantilla. Cualquier cambio - por ejemplo, añadir un nuevo proveedor de inicio de sesión social al walled garden - se realiza una sola vez en la plantilla y se propaga a todas las tiendas automáticamente. A continuación, el sistema de analítica de Purple agrupó los datos de afluencia y tiempo de permanencia de todas las tiendas, ofreciendo al equipo de operaciones comerciales una única vista de panel del comportamiento de los invitados por tienda, por región y por hora del día.
Permítame ofrecerle tres reglas prácticas que le ahorrarán tiempo en cada despliegue de Captive Portal de Meraki.
Regla uno: Compruebe siempre los rangos de IP del Dashboard de Meraki antes de configurar RADIUS. Los rangos cambian ocasionalmente y, si su firewall los está bloqueando, la autenticación fallará de forma silenciosa desde la perspectiva del usuario - simplemente verán que la página del portal se queda colgada. Utilice la herramienta de prueba RADIUS integrada en el Dashboard, bajo Access Control, para verificar la conectividad antes de la puesta en marcha.
Regla dos: Utilice comodines de dominio en el walled garden, no rangos de IP, para cualquier contenido alojado en CDN. Los rangos de IP de las CDN son amplios y cambian con frecuencia. Una entrada de dominio con comodín es más fácil de mantener y más fiable.
Regla tres: Habilite la contabilidad RADIUS en el puerto 1813 incluso si cree que aún no la necesita. Los datos de sesión son muy valiosos para solucionar problemas de desconexión y para introducir métricas precisas de tiempo de permanencia en su plataforma de analítica. No cuesta nada habilitarlo y es muy difícil de implementar a posteriori.
Ahora, algunas preguntas rápidas que me hacen con regularidad.
¿Puedo utilizar la página de bienvenida integrada de Meraki en lugar de Purple? Sí, pero perderá la captura de datos, la analítica, la automatización de marketing y la gestión de consentimiento conforme con el GDPR. La página de bienvenida integrada está bien para un clic básico, pero no es una plataforma de inteligencia de invitados.
¿Funciona esta configuración en los firewalls Meraki MX además de en los puntos de acceso MR? La configuración de la página de bienvenida RADIUS es compatible con los puntos de acceso MR. Los dispositivos MX gestionan la autenticación de VPN de cliente de forma diferente. Específicamente para WiFi de invitados, configurará los SSID de MR.
¿Qué pasa con WPA3? Los puntos de acceso Meraki MR son compatibles con WPA3 en SSID empresariales. Para los despliegues de Captive Portal de invitados, el SSID suele ser Open, por lo que WPA3 no se aplica directamente. Sin embargo, si está desplegando un SSID de Passpoint o OpenRoaming junto a su SSID de Captive Portal - algo que Purple admite - ese SSID utiliza WPA3-Enterprise con 802.1X, y ahí es donde WPA3 cobra relevancia.
Para terminar: la integración de Cisco Meraki y Purple está muy probada y es fiable, pero requiere atención a tres aspectos: el enrutamiento de la IP de origen de RADIUS, la definición completa del walled garden y la configuración del tiempo de espera de la sesión. Si se configuran correctamente estos tres elementos, la implementación es sencilla. El caso de negocio es claro - los establecimientos que implementan una plataforma de WiFi para invitados configurada correctamente con captura de datos obtienen de manera constante retornos medibles en la interacción de marketing y la información operativa.
Si desea profundizar más, consulte la guía de Purple sobre cómo implementar la autenticación 802.1X con RADIUS en la nube, y nuestra guía de implementación de AP inalámbricos de Cisco en el blog de Purple. Ambas están enlazadas en las notas del programa.
Gracias por escucharnos. Si tiene un escenario de implementación específico que le gustaría que cubriéramos, póngase en contacto con el equipo técnico de Purple. Nos vemos en el próximo episodio.
