Ver transcripción del podcast
Bienvenido a la Serie de Sesiones Técnicas de Purple. Soy su anfitrión, y hoy abordaremos un tema que surge en casi todos los despliegues de WiFi para invitados en empresas con los que trabajamos: configurar un captive portal en los puntos de acceso Cisco Meraki MR, y específicamente cómo integrar esto con la plataforma en la nube de Purple mediante autenticación RADIUS. Ya sea que sea un MSP que está incorporando a un nuevo cliente del sector hotelero o un arquitecto de red interno en una cadena de retail, este episodio le proporcionará los pasos de configuración precisos y la justificación de cada uno de ellos.
Pongámonos en situación. Tiene un recinto (puede ser un hotel, un centro de conferencias, un estadio o un parque comercial) que opera con puntos de acceso Cisco Meraki MR gestionados a través del Meraki Dashboard. El objetivo es desplegar una experiencia de WiFi para invitados con la imagen de la marca que recopile datos de primera mano, haga cumplir la aceptación de las condiciones del servicio y envíe datos analíticos a una plataforma de marketing. Eso es exactamente para lo que está diseñado Purple, y Meraki es uno de nuestros despliegues de hardware más comunes a nivel mundial.
Ahora bien, el punto arquitectónico clave que debe comprender antes de tocar una sola configuración es el siguiente: en Cisco Meraki, la autenticación RADIUS para una página de bienvenida no se procesa localmente en el punto de acceso. El RADIUS Access-Request se origina desde la nube de Meraki (desde la infraestructura del Dashboard) y no desde el AP en su LAN. Esta es una distinción fundamental que toma por sorpresa a muchos ingenieros en su primer despliegue con Meraki. Significa que su servidor RADIUS, en este caso el endpoint RADIUS en la nube de Purple, debe ser accesible desde internet, y las reglas de su firewall deben permitir el tráfico desde los rangos de IP del Dashboard de Meraki, no solo de la subred de su AP local. Encontrará los rangos de IP actuales del Dashboard en la sección Help y luego Firewall Info en su Meraki Dashboard.
Muy bien, pasemos a la configuración. Le guiaré a través de esto en el orden en que lo haría en un despliegue real.
Paso uno: configuración de SSID. En el Meraki Dashboard, navegue a Wireless, luego Configure y después SSIDs. Seleccione la ranura de SSID que desea utilizar para el acceso de invitados. Asígnele un nombre claro, algo como GuestWiFi o NombreDelRecinto_Guest. En Association requirements, establezca la Security en Open, no encryption. Esto es correcto e intencional; la capa de seguridad para los invitados se gestiona mediante el captive portal y la autenticación RADIUS, no mediante el cifrado WPA. Si está realizando un despliegue en un entorno PCI-DSS, querrá asegurarse de que el tráfico de invitados esté aislado en su propia VLAN, lo cual cubriremos en breve.
Paso dos: Página de bienvenida y autenticación. Aún en la página de Control de acceso para su SSID, desplácese hacia abajo hasta la sección de Página de bienvenida. Establézcala en Iniciar sesión con y, en el menú desplegable, seleccione mi servidor RADIUS. Esta es la configuración crítica que le indica a Meraki que autentique a los usuarios contra un servidor RADIUS externo antes de otorgar acceso a la red. Debajo de eso, verá la opción de Fuerza del Captive Portal. Establézcala en Bloquear todo el acceso hasta completar el inicio de sesión. Esto es lo que aplica el walled garden - sin esto, los invitados podrían evadir el portal por completo.
Paso tres: Configuración del servidor RADIUS. En la sección RADIUS, haga clic en Agregar 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 del lugar en el portal. Para redundancia en implementaciones de producción, debe agregar un servidor RADIUS secundario - Purple proporciona un endpoint de failover. Establezca el puerto de contabilidad en UDP 1813 si desea que los datos de la sesión se envíen de vuelta al motor de analítica de Purple, lo cual recomiendo ampliamente para cualquier lugar donde el tiempo de permanencia y la duración de la sesión sean métricas significativas.
Una nota rápida sobre los atributos RADIUS. Meraki respeta el atributo Session-Timeout devuelto en la respuesta RADIUS Access-Accept. Purple utiliza esto para controlar cuánto tiempo dura la sesión de un invitado antes de que se requiera una nueva autenticación. Para un hotel, podría establecer esto en 86,400 segundos - eso es 24 horas. Para una cafetería, algo como 3,600 segundos, una hora, es más apropiado. El atributo Idle-Timeout también se respeta, pero solo si la contabilidad RADIUS está habilitada. Esto desconecta las sesiones inactivas, lo cual es importante para la gestión de capacidad en lugares de alta densidad.
Paso cuatro: URL de la página de bienvenida. Navegue a Wireless, luego a Configure y después a Splash page. Seleccione su SSID de invitados en el menú desplegable. Establezca la Custom splash URL con la URL del portal de Purple para su lugar. 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 intercambio de autenticación. No modifique ni elimine estos parámetros.
Paso cinco: el walled garden. Aquí es donde la mayoría de las implementaciones tienen problemas. El walled garden es la lista de dominios y rangos de IP a los que un dispositivo de invitado puede acceder antes de autenticarse. Sin las entradas correctas, la propia página del Captive Portal no se cargará, ya que se bloqueará el acceso del navegador al CDN de Purple y a los proveedores de inicio de sesión social.
Navegue de regreso a Access Control para su SSID de invitados. Establezca Walled garden en Walled garden is enabled. En el campo de rangos de Walled garden, debe agregar lo siguiente. Primero, los dominios de la plataforma Purple: asterisco punto purple punto ai, y asterisco punto venuewifi punto com. Segundo, los dominios CDN que Purple utiliza para servir recursos del portal: asterisco punto cloudfront punto net, y asterisco punto akamaihd punto net. Tercero, la infraestructura de redirección de Meraki: asterisco punto network-auth punto com. Cuarto, si ofrece opciones de inicio de sesión social, necesita los dominios 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 Meraki maneja los dominios comodín en el walled garden. Meraki admite entradas comodín utilizando el prefijo de asterisco, por ejemplo, asterisco punto cloudfront punto net. Sin embargo, esta es una coincidencia basada en DNS - Meraki resuelve el dominio y permite las direcciones IP resultantes. Esto significa que para proveedores CDN como CloudFront o Akamai, donde las IP resueltas pueden cambiar con frecuencia, debe usar el comodín de dominio en lugar de rangos de IP estáticas. Las entradas de IP estáticas están bien para los extremos RADIUS de Purple, que son estables, pero no para el tráfico 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 concurrentes en horas pico. El despliegue inicial utilizaba una página de bienvenida de tipo clic - sin RADIUS, solo aceptación de términos. El problema era que no tenían ninguna información sobre quién se conectaba, no captaban correos electrónicos y no tenían forma de realizar campañas de marketing después de la estancia. Los migramos a Purple con 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 agregamos los rangos de IP del Meraki Dashboard 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 invitados que se conectaron en el primer mes, y su equipo de marketing realizó una campaña de reactivación que generó un aumento medible en las reservas directas.
El segundo escenario es una cadena de retail con 45 tiendas, cada una de ellas 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 sería propenso a errores y consumiría 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. Las herramientas de analítica de Purple agregaron después los datos de afluencia y tiempo de permanencia de todas las tiendas, lo que proporcionó al equipo de operaciones de retail una vista única en un panel del comportamiento de los invitados por tienda, por región y por hora del día.
Permítame compartirle 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 de Meraki Dashboard antes de configurar RADIUS. Los rangos cambian ocasionalmente y, si su firewall los está bloqueando, la autenticación fallará silenciosamente desde la perspectiva del usuario (solo verán que la página del portal se queda colgada). Utilice la herramienta de prueba de RADIUS integrada en el Dashboard, en la sección de 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 valiosos para solucionar problemas de desconexión y para alimentar métricas precisas de tiempo de permanencia en su plataforma de analítica. No cuesta nada habilitarla 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 que cumple con el GDPR. La página de bienvenida integrada está bien para un clic de acceso 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 con 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 el WiFi de invitados, configurará los SSID de MR.
¿Qué ocurre con WPA3? Los puntos de acceso Meraki MR son compatibles con WPA3 en SSID empresariales. Para 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 (lo cual es compatible con Purple), ese SSID utiliza WPA3-Enterprise con 802.1X, y ahí es donde WPA3 cobra relevancia.
Para resumir: la integración de Cisco Meraki y Purple está muy probada y es confiable, pero requiere atención en tres aspectos: el enrutamiento de la IP de origen de RADIUS, la integridad del walled garden y la configuración del tiempo de espera de la sesión. Haga bien esos tres puntos y la implementación será sencilla. El caso de negocio es claro - los establecimientos que implementan una plataforma de WiFi para invitados configurada correctamente con captura de datos ven de manera constante retornos medibles en la interacción de marketing y la información operativa.
Si quiere 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. Ambos enlaces se encuentran en las notas del programa.
Gracias por escucharnos. Si tiene un escenario de implementación específico que le gustaría que cubramos, póngase en contacto con el equipo técnico de Purple. Nos vemos en el próximo episodio.
