Captive Portal for Cisco Meraki

Bienvenido a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy vamos a tratar un tema que surge en casi todos los despliegues de WiFi para invitados empresariales en los que trabajamos: la configuración de un Captive Portal en los puntos de acceso Cisco Meraki MR, y específicamente cómo integrarlo con la plataforma en la nube de Purple mediante autenticación RADIUS. Tanto si es un MSP que incorpora a un nuevo cliente de hostelería como si es un arquitecto de redes interno en una cadena de tiendas, 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 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 control de Meraki. El objetivo es desplegar una experiencia de WiFi para invitados personalizada con su marca que recopile datos de origen, obligue a aceptar los términos del servicio y envíe los datos analíticos a una plataforma de marketing. Eso es exactamente para lo que se ha 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 un solo ajuste es el siguiente: en Cisco Meraki, la autenticación RADIUS para una página de bienvenida no la procesa localmente el punto de acceso. La solicitud de acceso RADIUS (Access-Request) se origina en la nube de Meraki (desde la infraestructura del panel de control), no desde el AP en su LAN. Esta es una distinción crítica que confunde a muchos ingenieros en su primer despliegue de 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 cortafuegos deben permitir el tráfico desde los rangos de IP del panel de control de Meraki, no solo desde la subred local de su AP. Encontrará los rangos de IP actuales del panel de control en la sección de Ayuda y, a continuación, en Información del cortafuegos en su panel de control de Meraki. Muy bien, entremos en la configuración. Le guiaré a través de este proceso en el orden en que lo haría en un despliegue real. Paso uno: configuración del SSID. En el panel de control de Meraki, navegue a Wireless, luego a Configure y después a SSIDs. Seleccione la ranura de SSID que desea utilizar para el acceso de invitados. Asígnele un nombre claro, algo como GuestWiFi o NombreDelEstablecimiento guion bajo Guest. En los requisitos de asociación (Association requirements), establezca la seguridad (Security) en Open, 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 está realizando el despliegue en un entorno PCI DSS, querrá asegurarse de que el tráfico de invitados esté aislado en su propia VLAN, algo que trataremos en breve. Paso dos: Captive Portal y autenticación. En la misma página de Control de acceso de su SSID, desplácese hacia abajo hasta la sección de Captive Portal. 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 contra un servidor RADIUS externo antes de conceder acceso a la red. Debajo de eso, verá la opción de Fuerza del Captive Portal. Establézcala en Bloquear todo el acceso hasta que se complete el inicio de sesión. Esto es lo que aplica el walled garden (entorno cerrado); sin esto, los invitados podrían eludir 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 del recinto del portal. Para garantizar la redundancia en entornos de producción, debería añadir 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, algo que recomiendo encarecidamente para cualquier recinto 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 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, podría establecerlo en 86.400 segundos (es decir, 24 horas). Para una cafetería, algo como 3.600 segundos (una hora) es más adecuado. También se respeta el atributo Idle-Timeout, pero solo si la contabilidad RADIUS está habilitada. Esto desconecta las sesiones inactivas, lo cual es importante para la gestión de la capacidad en recintos de alta densidad. Paso cuatro: URL del Captive Portal. Vaya a Wireless, luego a Configure y después a Splash page. Seleccione su SSID de invitados en el menú desplegable. Establezca la URL personalizada del Captive Portal con la URL del portal de Purple para su recinto. Esta es la URL a la que Meraki redirigirá a los clientes no autenticados. Meraki añade parámetros de consulta a esta URL (incluido un parámetro login_url) que Purple utiliza para completar el proceso de autenticación. No modifique ni elimine estos parámetros. Paso cinco: el walled garden. Aquí es donde la mayoría de las implementaciones experimentan problemas. El 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 Control de acceso para su SSID de invitado. Establezca el Walled garden en Walled garden habilitado. En el campo de rangos de Walled garden, debe añadir lo siguiente. Primero, los dominios de la plataforma Purple: star punto purple punto ai y star punto venuewifi punto com. Segundo, los dominios CDN que utiliza Purple para servir los recursos del portal: star punto cloudfront punto net y star punto akamaihd punto net. Tercero, la infraestructura de redirección de Meraki: star punto network-auth punto com. Cuarto, si ofrece opciones de inicio de sesión social, necesitará los dominios OAuth correspondientes. Para Google: accounts punto google punto com, star punto googleapis punto com, star punto gstatic punto com. Para Facebook: star punto facebook punto com, star punto fbcdn punto net y connect punto facebook punto net. Para Twitter o X: star punto twitter punto com y star 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, star 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 los 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áticas. Las entradas de IP estáticas son adecuadas para los endpoints RADIUS de Purple, que son estables, pero no para el tráfico de 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 tipo clic, sin RADIUS, solo con aceptación de condiciones. 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 tras 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 cortafuegos ascendente estaba bloqueando el UDP saliente en el puerto 1812 a cualquier elemento fuera de la subred local. Una vez que añadimos los rangos de IP del panel de Meraki a la lista de permitidos del cortafuegos, la autenticación funcionó de inmediato. Tras el despliegue, el hotel captó 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 generó un aumento medible en 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, las analíticas de Purple agregaron los datos de afluencia y tiempo de permanencia de todas las tiendas, ofreciendo al equipo de operaciones de retail una vista de panel único del comportamiento de los clientes por tienda, por región y por hora del día. Permítame darle 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 cortafuegos los bloquea, la autenticación fallará silenciosamente desde la perspectiva del usuario: simplemente 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 Control de Acceso, 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íticas. No cuesta nada habilitarlo y es muy difícil de implementar a posteriori. Ahora, algunas preguntas rápidas que me hacen con frecuencia. ¿Puedo utilizar la página de bienvenida integrada de Meraki en lugar de Purple? Sí, pero perderá la captura de datos, las analíticas, 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 clientes. ¿Funciona esta configuración en los cortafuegos 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 el 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 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 resulta relevante. Para resumir: la integración de Cisco Meraki y Purple está muy probada y es fiable, pero requiere prestar atención a 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 (session timeout). Si se configuran correctamente estos tres elementos, la implementación es sencilla. El caso de negocio es claro: los establecimientos que despliegan una plataforma de guest WiFi configurada correctamente con captura de datos obtienen de forma constante retornos medibles en el engagement de marketing y en la información operativa. Si desea profundizar más, consulte la guía de Purple sobre la implementación de la autenticación 802.1X con RADIUS en la nube, y nuestra guía de despliegue de Cisco Wireless AP en el blog de Purple. Ambas están enlazadas en las notas del programa. Gracias por escucharnos. Si tiene un escenario de despliegue específico que le gustaría que tratáramos, póngase en contacto con el equipo técnico de Purple. Nos vemos en el próximo episodio.