Saltar al contenido principal

Aruba Central and Purple WiFi: Cloud-Managed Integration

Una guía de referencia técnica completa para integrar Aruba Central con la plataforma de inteligencia de WiFi para invitados alojada en la nube de Purple. Esta guía cubre la arquitectura, la configuración paso a paso de Captive Portals externos y RADIUS, y las estrategias de implementación en múltiples sitios para equipos de TI empresariales.

By Iain JewittPublished
📖 7 min de lectura153 palabras2 ejemplos resueltos3 preguntas de práctica8 definiciones clave

Escucha esta guía

Ver transcripción del podcast
Aruba Central y Purple WiFi: Integración gestionada en la nube. Una sesión informativa para líderes de TI. Bienvenido. Si gestionas WiFi para invitados en múltiples sedes y utilizas Aruba Central, este episodio es directamente relevante para ti. Te guiaré exactamente a través de cómo Purple se integra con Aruba Central: la arquitectura, los pasos de configuración, los patrones de implementación multisitio y los errores comunes que suelen cometer los equipos. Esta es una sesión práctica, no un discurso de ventas. Comencemos. Sección uno: Contexto y por qué es importante. Aruba Central es la plataforma de red gestionada en la nube de HPE. Es el plano de control para decenas de miles de Aruba Instant Access Points desplegados en hoteles, cadenas de retail, estadios, centros de conferencias y edificios del sector público. Si has migrado de controladores Aruba locales (los Mobility Controllers o Mobility Conductors) a Central, ya has experimentado el cambio de una configuración basada en CLI y específica de cada sitio a una gestión de políticas basada en grupos y distribuida desde la nube. Ese cambio transforma fundamentalmente la forma en que integras una plataforma de WiFi para invitados como Purple. En un controlador Aruba local tradicional, configurarías el redireccionamiento del Captive Portal y la autenticación RADIUS directamente en el propio controlador. El controlador era el punto de aplicación de políticas y se ubicaba en tu centro de datos o sala de comunicaciones. Con Aruba Central, la aplicación de políticas sigue ocurriendo en el Access Point, pero la configuración se envía desde la nube. Eso significa que tus puntos de contacto de integración son diferentes. Trabajas con plantillas de grupo, perfiles de SSID y objetos de perfil de Captive Portal externo que residen en la jerarquía de configuración de Central, no en un equipo físico en un rack. Purple se sitúa por encima de todo esto como una plataforma de inteligencia de WiFi para invitados alojada en la nube. Proporciona el Captive Portal (la página de inicio que ven los invitados), gestiona la lógica de autenticación, captura datos de primera mano con consentimiento y envía analíticas a tus equipos de marketing y operaciones. La pregunta es: ¿cómo conectas estas dos plataformas en la nube de forma limpia, a escala, a través de potencialmente cientos de sitios? Sección dos: La arquitectura técnica. Permíteme describir el flujo de datos cuando un invitado se conecta. El dispositivo de un invitado se asocia con tu SSID de invitados (llamémoslo Hotel-Guest), el cual es transmitido por un Aruba Instant AP. El AP ha sido configurado, a través de Aruba Central, con un perfil de Captive Portal externo. Ese perfil contiene dos piezas de información críticas: la URL de redireccionamiento, que apunta al servidor del Captive Portal de Purple, y los detalles del servidor RADIUS, que apuntan al endpoint de RADIUS-as-a-Service de Purple. Cuando el huésped abre un navegador, el AP intercepta la solicitud HTTP y la redirige a la splash page de Purple. El huésped se autentica — a través de inicio de sesión social, correo electrónico, SMS o un formulario personalizado, según su configuración de Purple. El backend de Purple luego envía un mensaje RADIUS Access-Accept de vuelta al AP, el cual otorga al huésped acceso a internet y lo mueve del rol de preautenticación al rol de huésped autenticado. Los paquetes de contabilidad RADIUS fluyen a lo largo de la sesión, lo que le da a Purple visibilidad sobre la duración de la sesión y el uso de datos. Ahora, la diferencia clave con Aruba local: en Aruba Central, usted configura el perfil de External Captive Portal una sola vez, a nivel de grupo, y este se propaga a cada AP en ese grupo. No tiene que tocar los AP individuales. Esto es enormemente potente para implementaciones en múltiples sitios, pero requiere que defina correctamente la estructura del grupo antes de comenzar. Aruba Central organiza los dispositivos en Grupos, y dentro de los grupos, puede tener Sitios. Un Grupo es la unidad de configuración — los SSID, los perfiles de radio y las políticas de seguridad residen a nivel de grupo. Los Sitios son la unidad de ubicación y monitoreo. Para una cadena hotelera, una estructura sensata es un grupo por tipo de propiedad — por ejemplo, Hoteles de Servicio Completo y Propiedades Económicas — con cada hotel físico como un sitio independiente dentro del grupo correspondiente. La configuración de Purple luego se mapea a los grupos: un perfil de External Captive Portal por grupo, apuntando al mismo endpoint RADIUS de Purple, pero potencialmente con diferentes temas de splash page por sitio utilizando la personalización a nivel de sucursal de Purple. El walled garden es un elemento de configuración crítico que los equipos suelen configurar de manera incorrecta. Antes de que un huésped se autentique, el AP solo permite el tráfico DNS y DHCP, además de cualquier dominio que usted agregue explícitamente a la lista de permitidos. Para que Purple funcione, debe agregar a la lista de permitidos el dominio del Captive Portal de Purple, cualquier dominio de CDN que Purple utilice para recursos y cualquier dominio de proveedor de inicio de sesión social si utiliza autenticación social — Facebook, Google, Apple. Si omite un dominio, la splash page se cargará parcialmente o la autenticación fallará silenciosamente. La documentación de soporte de Purple proporciona la lista actual de walled garden, y vale la pena tratar esa lista como un documento vivo que debe revisar cada vez que Purple actualice su plataforma. Sección tres: Superficie de la API de Aruba Central para automatización. Si está realizando un despliegue en más de veinte sitios, la configuración manual a través de la interfaz de usuario de Central se convierte en un cuello de botella. Aruba Central expone una API REST integral — la API de Central — que le permite automatizar la creación de SSID, la asignación de perfiles de Captive Portal y la configuración de walled garden. La API se autentica mediante OAuth 2.0, y necesitará generar credenciales de API desde el portal de Central. Los endpoints clave de la API para una integración con Purple son: el endpoint de configuración de WLAN, que te permite crear y actualizar perfiles de SSID; el endpoint de perfil de Captive Portal externo, que es donde defines la URL de redirección de Purple y los detalles del servidor RADIUS; y los endpoints de gestión de sitios y grupos, que te permiten asignar dispositivos a sitios y grupos de forma programática. Si estás incorporando un nuevo establecimiento, puedes escribir un script que cree el sitio en Central, asigne los AP al sitio, aplique la plantilla de grupo correcta y configure el perfil de Captive Portal específico de Purple, todo sin tocar la interfaz de usuario. Purple también expone su propia API, la cual te permite crear registros de establecimientos, configurar temas de páginas de inicio (splash pages) y extraer datos analíticos. Una integración madura utilizará ambas APIs en conjunto: la API de Central para gestionar la capa de red y la API de Purple para gestionar la capa de la experiencia del invitado. Este es el patrón que utilizan las grandes cadenas de retail y grupos hoteleros cuando incorporan docenas de sitios nuevos por trimestre. Sección cuatro: Configuración paso a paso. Permíteme guiarte a través de la secuencia de configuración para un solo sitio, la cual luego podrás automatizar a escala. Primero, en Aruba Central, navega a tu grupo objetivo y abre la configuración de WLAN. Crea un nuevo SSID (por ejemplo, Venue-Guest) y establece el nivel de seguridad en Visitantes. Esta es la terminología de Aruba para una red abierta o autenticada mediante Captive Portal. Segundo, en la pestaña de Seguridad, establece el tipo de Splash Page en External Captive Portal. Crea un nuevo perfil de External Captive Portal. Dale un nombre descriptivo; Purple-Guest-Portal funciona bien. Establece el Tipo de Autenticación en Autenticación RADIUS. Ingresa el nombre de host del servidor de Captive Portal de Purple en el campo de IP o Nombre de Host. Ingresa la URL de redirección. Habilita HTTPS. Establece el comportamiento de Falla de Captive Portal en Denegar Internet, que es la opción predeterminada más segura. Tercero, configure el servidor RADIUS. En Central, ve a la configuración del servidor de autenticación y agrega el servidor RADIUS-as-a-Service de Purple. Necesitarás la IP o el nombre de host del servidor, el secreto compartido (que generas en la plataforma de Purple) y el puerto de autenticación, que es el estándar 1812, con contabilidad (accounting) en el 1813. Agrega este servidor como el Servidor Primario para tu SSID de invitados. Cuarto, configura el walled garden. En las reglas de acceso del SSID, agrega el dominio del Captive Portal de Purple y cualquier dominio de inicio de sesión social a la lista de permitidos. Prueba esto con cuidado: la falta de un dominio es la causa más común de fallas en las páginas de inicio. Quinto, guarda y envía la configuración. Central enviará la configuración a todos los AP del grupo. Verifica en un dispositivo de prueba que la redirección se active correctamente y que la autenticación se complete. Sección cinco: Patrones de despliegue multisitio. Para un despliegue en cincuenta o más sitios, necesitas un enfoque disciplinado. El patrón que recomiendo es: pilotear, templar, automatizar y validar. Realice una prueba piloto en un solo sitio. Asegúrese de que la configuración sea exacta: el walled garden completo, RADIUS funcionando, la splash page cargando limpiamente y la contabilidad fluyendo. Documente cada valor de los parámetros. Luego, integre esa configuración en una plantilla de grupo de Central. La plantilla se convertirá en su única fuente de verdad. Para el despliegue, utilice la API de Central para enviar la plantilla a los nuevos grupos a medida que incorpore sitios. Si su implementación de Purple utiliza diferentes temas de splash page por marca o región, parametrice el perfil del Captive Portal; la URL de redireccionamiento puede incluir parámetros de consulta que Purple utiliza para servir el tema correcto. Esto significa que puede tener un único endpoint de RADIUS pero múltiples experiencias de splash page, todo gestionado de forma centralizada. Valide cada sitio después de la incorporación. Un script de validación sencillo que asocie un dispositivo de prueba, verifique el redireccionamiento, autentique y compruebe el acceso a internet detectará cualquier desviación en la configuración antes de que los clientes la experimenten. El panel de analíticas de Purple también le mostrará si se están registrando las sesiones; si un sitio deja de reportar en Purple, esa es su señal de que algo está fallando en la capa de red. Sección seis: Errores comunes de implementación. El walled garden es el punto de falla número uno. Realice pruebas con un dispositivo que no tenga DNS en caché ni sesiones de portal activas. Utilice un perfil de navegador nuevo o el modo incógnito. El segundo error común es la discrepancia en el secreto compartido de RADIUS. El secreto que configure en Central debe coincidir exactamente con el secreto en la plataforma de Purple. Una diferencia de un solo carácter provocará fallas de autenticación silenciosas: el AP no recibirá respuesta del servidor RADIUS y denegará el acceso al cliente o, si ha configurado el modo de falla del Captive Portal en Permitir Internet, otorgará acceso sin autenticación, lo que representa un riesgo de cumplimiento. El tercer error común es la mala configuración de la VLAN. El tráfico de invitados debe estar en una VLAN dedicada, aislada de su red corporativa. En Aruba Central, esto se configura en los ajustes de VLAN del perfil de SSID. Si su VLAN de invitados no está correctamente conectada en el puerto del switch de enlace ascendente, los AP se activarán pero los invitados no obtendrán direcciones DHCP. El cuarto error común es la confianza del certificado en el redireccionamiento del Captive Portal. Los navegadores y sistemas operativos modernos son cada vez más estrictos con la aplicación de HTTPS. El servidor del Captive Portal de Purple utiliza un certificado TLS válido, pero si su walled garden bloquea los endpoints OCSP o CRL que el cliente utiliza para validar el certificado, verá errores de certificado en la splash page. Agregue esos endpoints a su walled garden. Sección siete: Preguntas rápidas. ¿Funciona Purple con la arquitectura AOS-10 de Aruba Central al igual que con AOS-8? Sí. El mecanismo del Captive Portal externo es consistente en ambos flujos de firmware. La ruta de la interfaz de usuario difiere ligeramente, pero los objetos de configuración subyacentes son los mismos. ¿Puedo usar el RADIUS-as-a-Service de Purple sin ejecutar mi propia infraestructura RADIUS? Sí, ese es el punto. El RADIUS-as-a-Service de Purple es un servidor RADIUS alojado en la nube al que apuntas tus AP de Aruba. No necesitas FreeRADIUS ni Cisco ISE de forma local. ¿Esta integración es compatible con WPA3? Aruba Central es compatible con WPA3 en AP compatibles, y puedes habilitar el modo de transición WPA3 en tu SSID de invitados. El mecanismo de Captive Portal de Purple es agnóstico a la capa de cifrado; opera a nivel de redirección HTTP, no a nivel de asociación 802.11. ¿Los datos que recopila Purple cumplen con el GDPR? Purple está diseñado con el cumplimiento del GDPR como un requisito fundamental. La página de inicio presenta un mecanismo de consentimiento, y el procesamiento de datos de Purple se rige por tu acuerdo de procesamiento de datos con ellos. Para los establecimientos de la UE, asegúrate de que tu configuración de Purple incluya el lenguaje de consentimiento adecuado y que tu DPA esté implementado antes del lanzamiento. Sección ocho: Resumen y próximos pasos. En resumen: Aruba Central y Purple se integran a través del mecanismo de Captive Portal externo, con la autenticación RADIUS gestionada por el servicio RADIUS en la nube de Purple. La configuración reside a nivel de grupo en Central y se propaga a todos los AP del grupo, lo cual es la diferencia arquitectónica clave con respecto a Aruba local. Para implementaciones en múltiples sitios, utiliza la API de Central para automatizar el aprovisionamiento y trata la configuración de tu sitio piloto como la plantilla para todo lo que sigue. Tus próximos pasos inmediatos: primero, confirma que la estructura de tu grupo de Aruba Central se asocie con la jerarquía de tus establecimientos de Purple. Segundo, obtén la lista actual de dominios de walled garden de Purple y los detalles del endpoint de RADIUS desde el portal de soporte de Purple. Tercero, ejecuta un piloto en un solo sitio y valida el flujo de autenticación completo antes de escalar. Cuarto, crea tus scripts de automatización utilizando la API de Central y la API de Purple en paralelo. Si estás evaluando Purple por primera vez, las páginas de la plataforma de WiFi para invitados y analítica en purple.ai te ofrecen una imagen clara de lo que obtienes más allá del Captive Portal: la captura de datos de primera fuente, la automatización de marketing y la analítica de afluencia. Ese es el caso de negocio que consigue el financiamiento para este proyecto. Gracias por escuchar. Si tienes preguntas sobre esta integración, el equipo de soluciones de Purple puede guiarte a través de una prueba de concepto adaptada a tu entorno específico de Aruba Central.

Parte de nuestra serie principal: Enterprise WiFi Security Guide

Aruba Central and Purple WiFi: Cloud-Managed Integration

执行摘要

对于管理分布式无线网络的企业IT团队而言,从本地控制器迁移到像Aruba Central这样的云端管理平台,从根本上改变了部署模式。虽然强制门户和RADIUS认证的核心机制保持不变,但配置范式已从以设备为中心转向基于分组的策略管理。

本指南为将Aruba Central与Purple的云端托管访客WiFi智能平台集成提供了全面的技术参考。我们涵盖了本地部署与云端管理部署之间的架构差异、外部强制门户和RADIUS即服务的分步配置,以及利用Aruba Central API实现多站点自动部署的策略。无论您是在十几个区域办公室部署 访客WiFi ,还是在全球零售门店网络中部署,本参考都能提供切实可行的指导,确保实现安全、可扩展且合规的集成。

技术深度剖析

架构转变:从控制器到云端

在传统的Aruba部署中,移动控制器充当策略执行点。强制门户配置文件、围墙花园规则和RADIUS服务器定义直接在控制器上配置。当访客设备与AP关联时,其流量被隧道化回控制器,控制器处理到强制门户的HTTP重定向,并代理向后端RADIUS服务器的认证请求。

Aruba Central采用分布式执行模型。策略执行发生在Instant接入点(IAP)边缘,而配置则从云端下发。集成的接触点从本地设备配置转移到Central配置层次结构中的组模板、SSID配置文件以及外部强制门户对象。

Aruba Central and Purple WiFi: Cloud-Managed Integration - architecture overview

Purple作为云端托管的智能平台,位于此网络层之上。它提供强制门户引擎,处理认证逻辑(包括社交登录、短信和基于表单的认证),捕获第一方数据,并通过 WiFi Analytics 仪表板将分析数据反馈给您的市场和运营团队。Purple还提供RADIUS即服务,消除了为访客认证部署本地RADIUS基础设施(如FreeRADIUS或Cisco ISE)的需求。

认证流程

  1. 关联: 访客设备与Aruba IAP广播的访客SSID关联。
  2. 预认证角色: IAP为访客分配一个预认证角色。该角色仅允许DNS、DHCP以及访问围墙花园中明确允许的域名的流量。
  3. HTTP拦截: 当访客打开浏览器并尝试访问HTTP站点时,IAP拦截该请求。
  4. 重定向: IAP引用其外部强制门户配置文件,将访客浏览器重定向到Purple的初始页面URL,附加AP MAC地址和客户端MAC地址等参数。
  5. 认证: 访客通过Purple初始页面进行认证。
  6. RADIUS访问请求: Purple后端代表访客向IAP(或虚拟控制器)发送RADIUS访问请求。
  7. RADIUS访问接受: 认证成功后,Purple向IAP发送RADIUS访问接受消息。
  8. 已认证角色: IAP将访客从预认证角色移至已认证访客角色,授予其完全的互联网访问权限。
  9. 计费: IAP在整个会话期间向Purple发送RADIUS计费开始和临时更新数据包,提供会话时长和数据使用量的可见性。

实施指南

本节概述了在Aruba Central中集成单个站点所需的分步配置。对于多站点部署,此配置应纳入组模板中。

步骤1:创建访客SSID

  1. 在Aruba Central WebUI中,导航到目标组上下文。
  2. 管理下,点击设备 > 接入点,然后点击配置图标。
  3. 选择WLANs选项卡,点击**+ 添加SSID**。
  4. 输入SSID名称(例如,Venue-Guest)。
  5. 安全选项卡下,将安全级别设置为访客

步骤2:配置外部强制门户配置文件

  1. 在SSID安全设置中,将初始页面类型选择为外部强制门户
  2. 点击**+**图标创建新的强制门户配置文件。
  3. 名称: 输入描述性名称(例如,Purple-Portal)。
  4. 认证类型: 选择RADIUS认证
  5. IP或主机名: 输入Purple门户设置中提供的Purple强制门户服务器主机名。
  6. URL: 输入Purple提供的重定向URL。
  7. 使用HTTPS: 启用此选项以强制安全通信。
  8. 强制门户故障: 选择拒绝互联网,以确保如果门户不可达,访客无法绕过认证。

步骤3:配置RADIUS即服务

  1. 仍在SSID安全设置中,定位外部强制门户配置下的主服务器字段。
  2. 点击**+**图标添加新的外部认证服务器。
  3. IP地址: 输入Purple RADIUS服务器的IP地址或主机名。
  4. 共享密钥: 输入在Purple门户中生成的RADIUS共享秘密。关键:必须完全匹配。
  5. 认证端口: 1812
  6. 计费端口: 1813
  7. 确保计费已启用,并设置为合理的间隔(例如,5分钟),以确保在Purple仪表板中准确跟踪会话。

步骤4:定义围墙花园

围墙花园是最关键的配置元素。它定义了访客在认证之前可以访问的域。如果围墙花园不完整,初始页面将无法加载,或社交认证将失败。

  1. 在SSID设置中,导航到访问规则。
  2. 添加规则,允许流量访问Purple的强制门户域和CDN端点。
  3. 如果您使用社交登录(例如,Facebook、Google、X),则必须添加这些身份提供商各自的域。Purple在其支持文档中维护了一份最新的所需围墙花园域列表。

步骤5:VLAN和DHCP配置

确保访客SSID映射到一个专用的VLAN,与您的企业网络隔离。

  1. 在SSID配置的VLANs选项卡下,选择外部DHCP服务器分配(如果使用自己的DHCP基础设施)或Instant AP分配(如果虚拟控制器正在为访客处理DHCP和NAT)。
  2. 为访客网络指定正确的VLAN ID。

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.

多站点部署的最佳实践

当在数十个或数百个场所部署时 - 无论是在 零售酒店业 还是 医疗保健 领域 - 手动配置容易出错。需要一种严谨的自动化方法。

Aruba Central and Purple WiFi: Cloud-Managed Integration - multisite rollout

1. 组结构和层次

使您的Aruba Central组结构与您的场所层次保持一致。一种常见模式是基于场所类型或品牌创建组(例如,“旗舰店”与“快闪店”)。外部强制门户配置文件在组级别应用,这意味着该组中的所有AP都会继承相同的Purple集成设置。

2. 参数化重定向

如果不同的站点需要不同的初始页面主题,您无需为每个站点创建单独的强制门户配置文件。Purple允许您使用一个单一的重定向URL,该URL可根据AP MAC地址或Aruba AP附加到URL的自定义参数动态提供正确的主题。

3. API驱动的配置

利用Aruba Central REST API实现站点入网的自动化。Central API允许您以编程方式创建SSID、分配强制门户配置文件以及更新围墙花园列表。与Purple API结合使用时,您可以构建一个零接触的配置工作流:

  • 脚本触发器: 一个新的场所被添加到您的CMDB中。
  • Purple API: 在Purple中创建场所记录并生成RADIUS秘密。
  • Central API: 在Aruba Central中创建站点,分配AP,应用组模板,并注入Purple RADIUS秘密。

4. SSID整合

避免为不同用户类型(例如,“访客”、“承包商”、“供应商”)广播多个访客SSID。正如我们关于 室内定位系统:UWB、BLE和WiFi指南 中详细说明的那样,过多的SSID会因消耗宝贵的空口时间发送信标帧而降低RF性能。广播一个单一的SSID,并使用Purple的认证逻辑根据用户身份分配不同的角色或带宽限制。

故障排除与风险缓解

常见故障模式

  • 初始页面加载失败: 这几乎总是围墙花园的问题。访客设备尝试从认证前不允许的域加载资源(例如,字体、图片或CSS文件)。在测试设备上使用浏览器的开发者工具来识别被阻止的请求。
  • 无声的认证失败: 如果初始页面加载了,用户进行了认证,但未获得互联网访问权限,问题通常是RADIUS共享秘密不匹配或防火墙阻止了AP与Purple RADIUS服务器之间的UDP端口1812/1813。
  • 重定向时的证书错误: 现代操作系统强制执行严格的HTTPS验证。如果您的围墙花园阻止客户端设备用于验证Purple TLS证书的证书吊销列表(CRL)或在线证书状态协议(OCSP)端点,浏览器将抛出安全警告。确保这些端点被列入白名单。

风险缓解:合规与隐私

部署访客WiFi时,您正在处理个人数据。集成设计必须考虑到隐私法规。

  • GDPR和CCPA: 确保您的Purple初始页面提供清晰的条款和条件以及明确的数据捕获同意机制。有关监管影响的更多背景信息,请参阅我们关于 欧盟AI法案与访客WiFi:营销人员需要了解的内容 的简报。
  • PCI DSS: 访客流量必须与支付处理网络逻辑隔离。验证Aruba Central中分配给访客SSID的VLAN无法路由到您的销售点(POS)基础设施。

投资回报率与业务影响

过渡到Aruba Central与Purple之间的云端管理集成可带来可衡量的商业价值:

  • 降低总拥有成本: 消除本地控制器和本地RADIUS服务器可降低硬件成本和维护开销。
  • 运营敏捷性: 基于组的策略管理和API驱动的配置使IT团队能够在数分钟内部署新站点,而非数天。
  • 可操作的情报: 通过将网络边缘无缝连接到Purple的分析平台,场所可获得关于客流量、停留时间和客户人口统计的即时可见性,从而将成本中心(访客WiFi)转变为创收资产。

收听我们的深度播客以获取更多见解:

Definiciones clave

External Captive Portal Profile

Un objeto de configuración en Aruba Central que define la URL de redirección y los detalles del servidor de autenticación para una plataforma de WiFi para invitados de terceros como Purple.

Este es el punto de integración principal donde los equipos de TI vinculan su red Aruba a los servicios en la nube de Purple.

Walled Garden

Un conjunto de reglas de acceso que permiten el tráfico a direcciones IP o dominios específicos antes de que un usuario se haya autenticado.

Esencial para permitir que los dispositivos de los invitados carguen la splash page de Purple, accedan a proveedores de inicio de sesión social y validen certificados TLS antes de obtener acceso completo a internet.

RADIUS-as-a-Service

Un servidor RADIUS alojado en la nube proporcionado por Purple que gestiona la autenticación y la contabilidad de las sesiones de WiFi de invitados.

Elimina la necesidad de que los equipos de TI de la empresa implementen y mantengan una infraestructura RADIUS local para el acceso de invitados.

Pre-Authentication Role

El estado inicial asignado a un dispositivo de invitado al asociarse con el SSID, que restringe el acceso únicamente a DNS, DHCP y destinos del walled garden.

Garantiza la seguridad al evitar que los dispositivos no autenticados accedan a internet o a la red corporativa.

Group Template

Una estructura de configuración jerárquica en Aruba Central que permite aplicar políticas y configuraciones de SSID de manera uniforme en múltiples puntos de acceso.

El mecanismo fundamental para lograr implementaciones multisitio consistentes y escalables.

RADIUS Accounting

El proceso mediante el cual el punto de acceso envía datos de la sesión (hora de inicio, duración, datos transferidos) al servidor RADIUS.

Crítico para que Purple proporcione análisis precisos sobre el tiempo de permanencia y el consumo de ancho de banda en el panel de WiFi Analytics.

OCSP/CRL Endpoints

Endpoints de Protocolo de Estado de Certificados en Línea y de Lista de Revocación de Certificados utilizados por los navegadores para verificar la validez de un certificado SSL/TLS.

Si el walled garden bloquea estos endpoints, los dispositivos modernos mostrarán advertencias de seguridad en lugar de la splash page de Purple.

OAuth 2.0

El protocolo estándar de la industria para la autorización, utilizado para asegurar el acceso a la API REST de Aruba Central.

Los equipos de TI deben generar credenciales OAuth para programar y automatizar el aprovisionamiento de nuevos sitios y perfiles de Captive Portal.

Ejemplos resueltos

Un hotel de 200 habitaciones está migrando de Aruba Mobility Controllers locales a Aruba Central. Necesitan replicar su integración existente de Purple WiFi, que utiliza una página de inicio personalizada y login social, en 45 puntos de acceso. ¿Cómo debería abordar la configuración el equipo de TI?

El equipo de TI debe crear primero un Grupo dedicado en Aruba Central para el hotel. Dentro de este grupo, configuran un nuevo SSID de invitados con el nivel de seguridad establecido en 'Visitantes'. Luego, deben crear un perfil de Captive Portal externo que apunte a la URL de redireccionamiento de Purple y configurar el endpoint de RADIUS-as-a-Service de Purple como el servidor de autenticación primario. De manera crucial, debido a que utilizan login social, el equipo debe configurar las reglas de acceso del SSID (el walled garden) para permitir explícitamente el tráfico a los dominios de Purple, los endpoints de CDN y los dominios específicos requeridos por los proveedores de identidad social (por ejemplo, Facebook, Google) antes de la autenticación. Finalmente, los AP se asignan al grupo, heredando automáticamente la configuración.

Comentario del examinador: Este enfoque aprovecha correctamente la arquitectura basada en grupos de Aruba Central. Al aplicar la configuración a nivel de grupo en lugar de por AP, la implementación es escalable y consistente. La mención explícita de configurar el walled garden para los dominios de login social demuestra una comprensión del punto de falla más común en las integraciones de Captive Portals administrados en la nube.

Una cadena de tiendas minoristas está implementando Purple WiFi en 150 tiendas administradas por Aruba Central. Quieren un tema de página de inicio diferente para sus tiendas insignia en comparación con sus sucursales estándar, pero desean minimizar la sobrecarga de configuración. ¿Cómo pueden lograr esto?

En lugar de crear Grupos de Aruba Central separados y perfiles de Captive Portal externos independientes para cada tipo de tienda, la cadena puede utilizar una única Plantilla de Grupo y una única URL de redireccionamiento. La plataforma de Purple permite que la URL de redireccionamiento sirva dinámicamente diferentes temas de páginas de inicio basados en los parámetros agregados por el AP de Aruba, como la dirección MAC del AP o el ID del Sitio. El equipo de TI configura un perfil de Captive Portal externo en Central y administra el mapeo de temas por completo dentro de la plataforma de Purple.

Comentario del examinador: Esta solución demuestra un conocimiento avanzado de las capacidades de integración. El uso de redireccionamientos parametrizados reduce la carga de configuración en Aruba Central y centraliza la gestión de la experiencia del invitado dentro de Purple, alineándose con las mejores prácticas para la escala empresarial.

Preguntas de práctica

Q1. Has configurado un perfil de Captive Portal externo en Aruba Central que apunta a Purple. Los invitados se conectan al SSID, pero sus navegadores muestran un error genérico de "No se puede conectar al servidor" en lugar de la splash page. ¿Cuál es la causa más probable?

Sugerencia: Considera qué tráfico se permite antes de que un invitado se autentique con éxito.

Ver respuesta modelo

La causa más probable es una configuración incompleta o faltante del walled garden. Antes de la autenticación, el AP descarta todo el tráfico excepto DNS, DHCP y el tráfico destinado a dominios explícitamente permitidos en las reglas de acceso. Debes asegurarte de que los dominios del Captive Portal de Purple y los endpoints de CDN estén en la lista de permitidos.

Q2. Tu organización está implementando Purple WiFi en 50 oficinas regionales. Quieres asegurarte de que si el servidor RADIUS de Purple no está disponible temporalmente, no se les otorgue a los invitados acceso no autenticado a Internet. ¿Qué ajuste debes configurar en el perfil de Captive Portal externo?

Sugerencia: Busca el parámetro de configuración que dicta el comportamiento cuando el servidor externo falla.

Ver respuesta modelo

Debes establecer el comportamiento de "Captive Portal Failure" en "Deny Internet". Este enfoque de falla cerrada garantiza la seguridad y el cumplimiento al evitar el acceso no autenticado si no se puede establecer comunicación con el servidor RADIUS.

Q3. Después de una implementación exitosa, el equipo de marketing informa que el panel de analíticas de Purple muestra los inicios de sesión de los invitados, pero todas las sesiones muestran una duración de 0 minutos y 0 bytes de datos utilizados. ¿Qué paso de configuración de red se omitió?

Sugerencia: Piensa en cómo se comunican la duración de la sesión y el uso de datos desde el AP al servidor de autenticación.

Ver respuesta modelo

Es probable que no se haya habilitado RADIUS Accounting, o que el puerto de accounting (1813) esté bloqueado por un firewall. El AP utiliza paquetes RADIUS Accounting-Start, Interim-Update y Stop para reportar las métricas de sesión a Purple. Sin estos, Purple sabe que ocurrió un inicio de sesión pero no tiene visibilidad de los detalles de la sesión.

Continúe leyendo esta serie

Sophos Firewall y guest WiFi: configuración de Captive Portal con Purple

Cómo funciona el guest WiFi en la nube de Purple con Sophos Firewall y sus puntos de acceso a través de un Captive Portal externo estándar y RADIUS, y dónde verificar el soporte y encontrar los pasos.

Leer la guía →

Azure AD and Entra ID WiFi Authentication: Integration and Configuration Guide

Esta guía de referencia técnica proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de establecimientos una hoja de ruta práctica para integrar Microsoft Entra ID (Azure AD) con redes WiFi empresariales utilizando RADIUS y 802.1X. Cubre la decisión arquitectónica entre Windows NPS local y RADIUS nativo de la nube, el despliegue de autenticación EAP-TLS basada en certificados a través de Microsoft Intune, y las mejores prácticas operativas para asegurar el acceso inalámbrico en entornos de hotelería, retail y sector público. Para las organizaciones que ya han invertido en el ecosistema de Microsoft 365 y Entra ID, esta guía cierra la brecha entre la gestión de identidad en la nube y la seguridad de la red física.

Leer la guía →

Okta and RADIUS: Extending Your Identity Provider to WiFi Authentication

Esta guía proporciona una referencia técnica completa para los administradores de TI en organizaciones centradas en Okta que desean extender su proveedor de identidad en la nube a la autenticación de WiFi utilizando el agente Okta RADIUS. Cubre la arquitectura de autenticación completa, las compensaciones de la aplicación de MFA, la asignación dinámica de VLAN a través del mapeo de atributos RADIUS y la decisión crítica entre EAP-TTLS basado en contraseñas y EAP-TLS basado en certificados. Los operadores de recintos y los equipos de TI empresariales encontrarán una guía de implementación práctica, casos de estudio del mundo real de la industria hotelera y de retail, y un marco claro para integrar Okta RADIUS junto con soluciones dedicadas de WiFi para invitados.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.