Cisco Meraki 与 Purple WiFi 的集成
本指南提供了在 Cisco Meraki 基础设施上部署 Purple WiFi 的权威技术参考，涵盖了双层集成架构——Dashboard API 配置和 Captive Portal API 身份验证——以及逐步的 RADIUS 和欢迎页面配置。专为需要从功能性访客 WiFi 部署转向战略性访客智能平台的网络工程师和 IT 经理设计，并提供来自实际企业部署（包括比利时麦当劳、哈罗德百货和 AGS 机场）的可衡量的投资回报率结果。
Listen to this guide
View podcast transcript
执行摘要
Cisco Meraki 是数千家企业场所（酒店、零售连锁、体育场馆和公共设施）首选的网络基础设施骨干。其云管理架构实现了大规模运营的简单性，但其原生的访客 WiFi 功能远不能满足现代场所运营者的需求：第一方数据采集、符合 GDPR 的同意管理、实时客流分析以及营销自动化集成。Purple WiFi 果断地弥补了这一差距。
Purple 与 Meraki 的集成在两个技术层面运作。Meraki Dashboard API 实现了自动化批量配置——一次性将 Meraki 组织中数百个接入点导入 Purple Portal。Meraki Captive Portal API 结合 RADIUS 身份验证，提供面向访客的体验：一个完全品牌化的欢迎页面、灵活的身份验证选项以及馈送至 Purple 分析引擎的会话记账。对于回头客，PurpleConnex（SecurePass）SSID 利用 Hotspot 2.0（Passpoint，IEEE 802.11u）实现无缝自动重连，消除了重复认证的摩擦。
该集成的部署已达到大规模应用：比利时麦当劳、加拿大沃尔玛、哈罗德百货（60万次登录，投资回报率达 57 倍），以及 AGS 机场（投资回报率 842%）。对于任何管理 Meraki 资产并希望从访客 WiFi 中展示可衡量业务价值的 IT 团队而言，此集成是实现该目标的操作效率最高的路径。
技术深度解析
集成架构
Purple 与 Meraki 的集成最好理解为两个并行的 API 关系，在网络堆栈的不同层运行。第一个是通过 Meraki Dashboard REST API 实现的管理面集成，专门用于配置和设置。第二个是通过 Meraki Captive Portal API 和 RADIUS 协议实现的数据面集成，控制实时的访客身份验证流程。
管理面：Dashboard API 配置
Meraki 在 api.meraki.com/api/v1 公开了一套全面的 REST API。Purple 的硬件导入向导使用组织范围的 API 密钥对此 API 进行身份验证，然后枚举 Meraki 组织内的所有网络、SSID 和接入点。这使网络工程师能够在一次批处理操作中导入 50 个站点的 300 多个接入点——否则每个设备都需要手动输入。Purple 的双向集成能力还允许平台将 Captive Portal、围墙花园和 RADIUS 配置推送回 Meraki，进一步减少手动配置开销。
要生成所需的 API 密钥，请在 Meraki 仪表板中导航至组织 > API 和 Webhooks > API 密钥，然后选择生成 API 密钥。应将此密钥视为有特权的凭据——将其存储在密钥管理系统中，并按照您组织的标准凭据生命周期进行轮换。
数据面：Captive Portal API 和 RADIUS
访客身份验证流程使用 Meraki 的 Captive Portal API 的登录模式。当访客连接到访客 SSID 时，Meraki 的访问控制引擎会拦截第一个 HTTP 请求，并发出 302 重定向至 Purple 托管的欢迎页面 URL。欢迎页面由 Purple 的 CDN 基础设施提供；围墙花园配置确保在身份验证完成之前可以访问 Purple 的域名。
访客在欢迎页面上完成身份验证后，Purple 的平台向 Meraki AP 发送 RADIUS Access-Accept 消息（端口 1812）。然后 Meraki 授予设备完整的网络访问权限。端口 1813 上的 RADIUS 记账消息每 4 分钟提供会话开始、中间更新和会话结束事件，将其馈送至 Purple 的分析引擎，从而准确计算停留时间、会话时长和重复访问。
身份验证方法
Purple 的 Captive Portal 支持多种身份验证机制，每种机制具有不同的数据采集含义：
| 方法 | 采集的数据 | GDPR 同意 | 推荐用例 |
|---|---|---|---|
| 社交登录（Facebook、Google） | 姓名、邮箱、个人资料数据 | 内嵌同意复选框 | 酒店业、零售忠诚度 |
| 邮箱表单 | 邮箱、自定义字段 | 内嵌同意复选框 | 任何场所，最大数据控制 |
| 短信验证 | 手机号码 | 内嵌同意复选框 | 高安全性或年龄限制场所 |
| 点击通过（仅服务条款） | 设备 MAC、会话数据 | 条款接受 | 低摩擦公共访问 |
PurpleConnex：SecurePass 和 Hotspot 2.0
PurpleConnex 是与主要访客 SSID 一起部署的第二个 SSID。它被配置为 WPA2 Enterprise 网络，使用 Purple 的 RadSec RADIUS 服务器（rad1-secure.purple.ai 和 rad2-secure.purple.ai），端口 2083，TLS 传输。在此 SSID 上启用了 Hotspot 2.0（Passpoint），广告 securewifi.purple.ai 域和 Purple 漫游联盟 OI。当回头客的设备先前已下载 Purple Passpoint 配置文件时，它将自动关联到 PurpleConnex 并静默认证——无需欢迎页面，无需手动登录。这在酒店环境中尤其重要，例如入住的客人停留多晚，不应在每次设备重连时都要求重新认证。
Hotspot 2.0 配置还解决了 iOS 14 和 Android 10 以上版本引入的 MAC 地址随机化挑战。由于 PurpleConnex 的身份验证是基于凭据而非 MAC 的，即使设备在每次连接尝试时提供不同的随机化 MAC 地址，Purple 也能保持一致的访客身份记录。
实施指南
部署前检查表
在开始配置之前，请确认以下先决条件已到位。您的 Meraki 组织必须启用 API 访问——这是在组织 > 设置 > 仪表板 API 访问下的组织级设置。您需要一个已创建场所和配置好 SSID 的 Purple Portal 帐户。在操作 Meraki 仪表板之前，从 Purple Portal 获取以下值：RADIUS 服务器主机名和共享密钥、自定义欢迎页面 URL、身份验证后重定向 URL，以及当前的围墙花园域白名单。
步骤 1：生成 Meraki API 密钥并导入接入点
在 Meraki 仪表板中，导航至组织 > API 和 Webhooks > API 密钥，并生成新的 API 密钥。立即复制此密钥——它只显示一次。在 Purple Portal 中，导航至场所管理 > 导入硬件 > 第三方 API，选择 Cisco Meraki，并粘贴您的 API 密钥。Purple 将枚举您的整个接入点资产。选择您希望与每个 Purple 场所关联的接入点，并确认导入。
步骤 2：配置访客 SSID — 访问控制
在 Meraki 仪表板中，导航至无线 > 访问控制。从下拉菜单中选择您的访客 SSID，并应用以下设置：
| 参数 | 值 |
|---|---|
| SSID 状态 | 启用 |
| 安全 | 开放 |
| 欢迎页面 | 使用我的 RADIUS 服务器进行登录 |
| Captive Portal 强度 | 阻止所有访问，直到登录完成 |
| 围墙花园 | 启用（添加所有 Purple 域名条目） |
| 同时登录 | 允许 |
| 控制器断开连接行为 | 默认 |
| 客户端 IP 和 VLAN | Meraki DHCP（NAT 模式） |
| 数据载体检测 | 禁用 |
在RADIUS 服务器下，添加两个身份验证服务器（主服务器和辅助服务器），端口 1812，使用 Purple Portal 中的共享密钥。添加相应的记账服务器，端口 1813。将记账中间间隔设置为4 分钟，服务器超时设置为5 秒，重试计数设置为3。
在高级 RADIUS 设置下，将 Called-Station-ID 和 NAS-ID 均设置为AP MAC 地址。从这些字段中删除任何其他值。
步骤 3：配置欢迎页面
导航至无线 > 欢迎页面。输入 Purple Portal 中的自定义欢迎页面 URL。将欢迎页面后的重定向目标设置为您选择的 URL——通常为您的场所网站或特定的促销着陆页。保存更改。
步骤 4：配置 PurpleConnex（SecurePass SSID）
创建一个名为PurpleConnex的新 SSID。将安全设置为WPA2 Enterprise。禁用 Wi-Fi 个人网络（WPN）。在 RADIUS 服务器下，添加 rad1-secure.purple.ai 和 rad2-secure.purple.ai，端口 2083，启用 RadSec（RADIUS over TLS），共享密钥为 radsec。将 RadSec TLS 空闲超时设置为 15 分钟。禁用 RADIUS CoA 支持。启用 RADIUS 代理。
导航至无线 > Hotspot 2.0。选择 PurpleConnex SSID 并按如下方式配置：
| 参数 | 值 |
|---|---|
| Hotspot 2.0 | 启用 |
| 运营商名称 | PURPLE:GB |
| 网络类型 | 免费公共网络 |
| 域列表 | securewifi.purple.ai |
| 漫游联盟 OI | 5A03BA0000, 004096 |
| NAI 域 | securewifi.purple.ai（EAP-TTLS / PAP） |
步骤 5：验证和测试
在宣布部署完成之前，从独立网段上的用户设备测试完整的访客旅程。验证欢迎页面是否正确加载，所有身份验证方法是否正常工作，身份验证后网络访问是否在 3-5 秒内被授予，以及会话数据是否在 5 分钟内出现在 Purple 分析仪表板中。通过下载 Passpoint 配置文件并在第二次访问时确认无缝重连，测试 PurpleConnex 的自动重连流程。
最佳实践
网络分段和 PCI DSS 合规性。 访客 WiFi 流量应隔离在专用 VLAN 上，并设置防火墙规则以防止横向移动到企业内部网络段。如果您的场所在同一物理网络基础设施上处理支付卡数据，则需要正式的 PCI DSS 范围界定评估。Meraki 的 NAT 模式在 AP 级别提供客户端隔离，但交换层的 VLAN 分段是 PCI 范围管理的适当控制措施。
GDPR 和 CCPA 数据治理。 Purple 的 Captive Portal 在身份验证点提供了一个同意机制，捕获对营销通信的明确选择加入。确保您的 Purple Portal 数据保留设置与您组织的数据治理策略保持一致。Purple 的平台原生支持数据主体访问请求和擦除权工作流，这相对于定制的 Captive Portal 解决方案是一个实质性的合规优势。
围墙花园维护。 围墙花园域名列表是一个动态的配置项。Purple 的 CDN 和平台基础设施可能会随时间变化，过期的围墙花园将导致欢迎页面体验中断。订阅 Purple 的发行说明，并将围墙花园列表作为标准变更管理流程的一部分进行审查。
冗余和故障转移。 Purple 为访客 SSID 和 PurpleConnex 提供了两个 RADIUS 服务器端点。应始终配置两者。在 Purple 平台中断的情况下，将 Meraki 的控制器断开连接行为设置为默认——这允许先前已认证的会话继续进行，而新的认证将排队重试。
Wi-Fi 6 和吞吐量优化。 对于体育场馆和会议中心等高密度场所，Meraki 的 Wi-Fi 6（802.11ax）接入点提供了并发访客会话所需的吞吐量空间。Purple 的集成不受硬件代际影响——RADIUS 和 Captive Portal 配置在 Meraki 所有 AP 产品代际中完全相同。
故障排除和风险缓解
下表总结了 Meraki 和 Purple 部署中常见的故障模式、其根本原因及建议的补救措施。
| 症状 | 根本原因 | 补救措施 |
|---|---|---|
| 欢迎页面未能加载（空白或损坏） | 围墙花园不完整 | 将所有 Purple 域名条目添加到围墙花园白名单 |
| 身份验证成功但未授予网络访问权限 | RADIUS 超时设置过低 | 将服务器超时设置为 5 秒，重试计数设置为 3 |
| 分析中无每个 AP 的数据 | NAS-ID / Called-Station-ID 配置错误 | 在高级 RADIUS 设置中将这两个字段设为 AP MAC 地址 |
| 峰值负载时出现间歇性认证失败 | 仅配置单个 RADIUS 服务器 | 添加 Purple 的主 RADIUS 端点和辅助 RADIUS 端点 |
| PurpleConnex 不自动连接 | Hotspot 2.0 配置错误 | 验证漫游联盟 OI 和 NAI 域设置 |
| 回头客被提示重新认证 | 未部署 PurpleConnex SSID | 部署带有 Passpoint 配置的 PurpleConnex SSID |
| 未捕获 GDPR 同意 | 欢迎页面同意字段被禁用 | 在 Purple Portal 欢迎页面编辑器中启用营销选择加入字段 |
MAC 地址随机化。 现代 iOS 和 Android 设备默认提供随机化 MAC 地址。这影响了 Purple 在访客 SSID 上识别回头客的能力。PurpleConnex / SecurePass 解决方案通过使用基于凭据的身份验证而非基于 MAC 的识别来解决此问题。对于无法部署 PurpleConnex 的场所，Purple 的平台使用会话元数据进行概率匹配，以部分缓解该影响。
Meraki 固件兼容性。 确保您的 Meraki AP 运行的固件版本支持 PurpleConnex 所需的 Hotspot 2.0 和 RadSec 功能。对于生产部署，建议使用 Meraki 的稳定固件通道；不应在实时访客 WiFi 环境中使用 Beta 固件。
投资回报率和业务影响
在 Meraki 资产上部署 Purple 的业务案例已在多个垂直领域的实际部署中得到充分验证。以下结果摘自已发布的 Purple 案例研究。
| 机构 | 行业 | 成果 |
|---|---|---|
| 哈罗德百货 | 奢侈品零售 | 60 万次 WiFi 登录，投资回报率达 57 倍 |
| AGS 机场 | 旅运交通 | 通过分级带宽收入实现 842% 的投资回报率 |
| 比利时麦当劳 | 快餐店 | 部署 Purple + Cisco Meraki + Socialspot 在线 |
| 加拿大沃尔玛 | 大型零售 | 使用 Purple 和 Cisco 的企业级访客 WiFi |
| 迈阿密热火队（Kaseya中心） | 体育娱乐 | 290,000 次连接，平均每月 28,000 次 |
| c2c 铁路 | 交通运输 | 81,601 名 WiFi 用户，投资回报率 151% |
投资回报率的机制很直接。Purple 将访客 WiFi 认证事件转化为第一方数据档案——电子邮件地址、人口统计信息、访问频率、停留时间和行为模式。这些数据通过 Purple 的 API 连接器直接输入 CRM 和营销自动化平台，从而能够开展有针对性的活动，这些活动在转化率和每次获取成本方面明显优于第三方受众数据。
对于入住率为 70%、每个房间平均 1.8 位客人的 200 间客房酒店，在 Meraki 资产上部署 Purple 通常每天可捕获 250-300 个新的第一方档案。按照行业标准的电子邮件营销转化率 3-5%，以及平均增量预订价值 150 英镑，仅电子邮件再营销带来的年度收入通常在第一运营年内就超过了 Purple 平台许可的总成本。
自动化 Meraki 配置带来的运营效率提升是一个次要但有意义的收益。对于管理 50 个站点的多站点运营商来说，将手动配置时间（预计每个站点 3-4 小时）减少到 30 分钟以内，代表了工程资源成本的实质节约。
Key Definitions
Captive Portal
一种基于 Web 的身份验证网关，拦截访客设备的初始 HTTP 请求，并将其重定向到登录或条款接受页面，然后才授予网络访问权限。在 Meraki-Purple 集成中，Captive Portal 由 Purple 托管，并通过在 Meraki 仪表板中配置的自定义欢迎页面 URL 提供。
IT 团队在 Meraki 仪表板中配置欢迎页面设置时会遇到这个问题。选择点击通过（仅接受条款）还是登录（RADIUS 身份验证）决定了部署所提供的数据采集和安全级别。
RADIUS（远程身份验证拨入用户服务）
一种网络协议（RFC 2865），为网络访问提供集中化的身份验证、授权和记账（AAA）。在 Meraki-Purple 集成中，Purple 运行 RADIUS 服务器，接收来自 Meraki AP 的身份验证请求（端口 1812），并返回 Access-Accept 或 Access-Reject 响应。记账数据发送到端口 1813。
RADIUS 是访客身份验证流程的骨干。网络工程师需要在 Meraki 访问控制设置中配置 RADIUS 服务器的 IP 地址、共享密钥和端口号。RADIUS 配置不当是访客身份验证失败的最常见原因。
围墙花园
一个网络目的地列表（IP 地址、域名或 CIDR 块），访客设备在完成 Captive Portal 身份验证之前可以访问。在 Meraki-Purple 集成中，围墙花园必须包括 Purple 欢迎页面所需的所有域——CDN 资产、身份验证提供商端点以及 Purple 平台本身。
IT 团队必须将此列表作为动态配置项来维护。不完整的围墙花园会导致访客欢迎页面体验中断。Purple 在其支持文档中发布并维护当前所需域名的白名单。
RadSec（RADIUS over TLS）
RADIUS 协议的一种扩展（RFC 6614），通过 TLS 加密的 TCP 连接传输 RADIUS 消息，为身份验证流量提供机密性和完整性。Purple 的 PurpleConnex SSID 使用端口 2083 上的 RadSec，取代访客 SSID RADIUS 配置使用的标准 UDP 传输。
PurpleConnex SecurePass SSID 需要 RadSec。网络工程师必须在 Meraki 的 RADIUS 服务器配置中启用 RadSec，并使用端口 2083 而不是标准的 1812/1813。未能启用 RadSec 将阻止 PurpleConnex 身份验证功能。
Hotspot 2.0 / Passpoint（IEEE 802.11u）
一项 Wi-Fi 联盟认证计划，基于 IEEE 802.11u 标准，支持自动、安全的网络发现和关联。具有 Passpoint 配置文件的设备将无需用户干预自动连接到兼容网络，使用基于 EAP 的身份验证而非 Captive Portal。
在 Meraki-Purple 集成中，Hotspot 2.0 在 PurpleConnex SSID 上配置，以便为回头客实现无缝自动重连。这在酒店业和零售环境中尤其有价值，因为重复的身份验证摩擦会降低客人满意度。
NAS-ID（网络访问服务器标识符）
一个 RADIUS 属性（属性 32），用于标识发送身份验证请求的网络访问服务器——在此上下文中，即 Meraki 接入点。Purple 使用 NAS-ID 将访客会话归因到特定的物理接入点，从而实现楼层级别的定位分析。
这是 Meraki-Purple 部署中最常配置错误的参数之一。必须在 Meraki 高级 RADIUS 设置中将其设置为 AP MAC 地址。任何其他值（如 SSID 名称或静态字符串）将阻止 Purple 生成每个 AP 的分析。
Meraki Dashboard API
Cisco Meraki 提供的一种 RESTful API，允许对 Meraki 云管理平台进行编程访问。它支持跨组织、网络、设备和配置对象的读取和写入操作。Purple 使用此 API 在配置阶段导入接入点数据并推送 SSID/RADIUS 配置。
IT 团队需要从 Meraki 仪表板（组织 > API 和 Webhooks）生成 API 密钥，并提供给 Purple Portal 的硬件导入向导。此密钥应被视为有特权的凭据并安全存储。
GDPR（通用数据保护条例）
欧盟法规 2016/679，规范欧盟居民个人数据的收集、处理和存储。在访客 WiFi 的背景下，GDPR 要求场所在通过 Captive Portal 收集个人数据（如电子邮件地址）之前获得明确的知情同意，并为数据主体提供访问、更正或删除其数据的机制。
Purple 是首批实现 GDPR 合规的 WiFi 提供商之一。Purple 的 Captive Portal 在身份验证点提供了一个同意机制，并且该平台原生支持数据主体访问请求和擦除权工作流程。IT 团队应确保 Purple Portal 的数据保留设置与其组织的数据治理策略保持一致。
PurpleConnex（SecurePass）
Purple 的无缝重连解决方案，实现为第二个 SSID，配置了 WPA2 Enterprise 安全、RadSec RADIUS 传输和 Hotspot 2.0（Passpoint）广告。设备已下载 Purple Passpoint 配置文件的回头客将自动关联到 PurpleConnex，而无需看到 Captive Portal。
PurpleConnex 与主要访客 SSID 一起部署，并且对首次来访者不可见。它解决了两个关键挑战：回头客的重复身份验证摩擦，以及 iOS 14 和 Android 10 以上版本的 MAC 地址随机化问题，后者破坏了主要 SSID 上基于 MAC 的访客识别。
Called-Station-ID（RADIUS 属性 30）
一个 RADIUS 属性，用于标识客户端连接的接入点或网络访问服务器，通常表示为 AP 的 MAC 地址。Purple 使用此属性与 NAS-ID 结合，将访客会话映射到特定的物理接入点以进行定位分析。
必须在 Meraki 高级 RADIUS 设置中设置为 AP MAC 地址。此属性与 NAS-ID 协同工作——两者必须正确配置，Purple 的楼层级分析才能准确运行。
Worked Examples
一家拥有250间客房、分布在英国12 个物业的四星级酒店集团，已部署了完整的 Cisco Meraki 资产（MR46 和 MR57 AP、MX68 安全设备）。他们目前提供开放式的访客 WiFi，没有 Captive Portal。IT 总监希望实施 Purple WiFi，以捕获访客的电子邮件地址用于酒店的 CRM，遵守 GDPR，并生成关于高峰时段网络使用情况的分析。部署必须在对现有客人最小干扰的情况下完成，且不得要求对 12 个物业中任何一个进行现场工程师访问。应如何构建此部署？
部署应分三个阶段进行，利用 Meraki Dashboard API 对所有 12 个物业进行远程、零接触配置。
第一阶段：配置（第 1 天，远程） 生成一个限定在酒店集团 Meraki 组织范围内的 Meraki API 密钥。在 Purple Portal 中，使用第三方 API 选项的硬件导入向导，一次性批量导入所有 12 个网络中的所有接入点。将每个网络分配到对应的 Purple 场所。对于这种规模的资产，此操作通常在 20 分钟内即可完成。
第二阶段：SSID 和 RADIUS 配置（第 1-2 天，通过 Meraki 仪表板远程进行） 对于每个 Meraki 网络，将现有访客 SSID 配置为使用“使用我的 RADIUS 服务器进行登录”的欢迎页面类型。添加 Purple 主 RADIUS 服务器和辅助 RADIUS 服务器，端口 1812 和 1813，并使用 Purple Portal 中的共享密钥。将 Captive Portal 强度设置为阻止所有访问，启用包含 Purple 域白名单的围墙花园，并配置自定义欢迎页面 URL。将 NAS-ID 和 Called-Station-ID 设置为 AP MAC 地址。由于 Meraki 的仪表板支持配置模板，一个模板可以同时应用于所有 12 个网络，从而将每个站点的配置时间缩短至零。
第三阶段：PurpleConnex 部署（第 2-3 天，远程） 在每个网络上创建 PurpleConnex SSID，使用 WPA2 Enterprise 和 RadSec RADIUS 配置。启用 Hotspot 2.0，并配置 Purple 运营商名称和域名设置。此 SSID 对未经验证的客人是不可见的——它将在后续访问时自动静默连接回头客。
验证： 在向所有 12 个物业推出配置之前，使用一个 4G 连接的移动设备在一个物业远程测试完整的访客旅程。在上线后的 24 小时内，监控 Purple 分析仪表板中的会话数据摄入情况。
整个部署可在 2-3 天的工程时间内完成，无需现场访问，充分利用了 Meraki 的云管理和 Purple 的 API 配置。
一个可容纳 6 万人的足球场，在广场、看台和包厢内使用 Cisco Meraki MR45 接入点。他们希望部署 Purple WiFi 来收集球迷数据，在比赛期间进行场内调查，并与现有的 Salesforce CRM 集成。主要问题是规模：在比赛日，预计有高达 3.5 万个并发 WiFi 会话。体育场的 IT 团队担心在高峰负载下 RADIUS 身份验证的性能。应该如何针对高并发环境优化 RADIUS 配置？
对于高并发的体育场部署，RADIUS 配置需要特别关注冗余、超时参数和会话管理。
用于扩展的 RADIUS 服务器配置： 在资产中的每个 Meraki AP 和 MX 上配置两个 Purple RADIUS 端点（主服务器和辅助服务器）。对于体育场部署，这是不可协商的——单个 RADIUS 服务器配置将创建一个单点故障，在开球时并发连接尝试达到高峰时，会导致身份验证失败。
将 RADIUS 服务器超时设置为 5 秒，重试计数设置为 3。这为每个身份验证尝试在故障切换到辅助服务器之前提供最多 15 秒的时间，这在正常条件下对于云托管的 RADIUS 服务来说是足够的。在体育场环境中，不要将超时时间降低到 5 秒以下——并发负载带来的额外延迟意味着激进的超时值会导致错误失败。
将记账中间间隔设置为 4 分钟。这为每个活跃会话每 4 分钟生成一条 RADIUS Accounting-Interim-Update 消息，Purple 使用这些消息计算停留时间。在拥有 3.5 万个并发会话的体育场中，这会生成大约每秒 145 条记账消息——完全在 Purple 的平台容量之内。
SSID 和网络分段： 在具有足够大的 DHCP 范围的专用 VLAN 上部署访客 SSID。对于 6 万人的场地，建议使用 /16 子网（65,534 个地址）。确保 DHCP 租约时间设置为与预期会话持续时间相匹配——对于 2 小时的比赛，3 小时的租约是合适的。过短的租约时间会导致不必要的 DHCP 波动，并增加身份验证基础设施的负载。
Salesforce CRM 集成： Purple 的平台支持原生的 Salesforce 连接器集成。在 Purple Portal 中配置 CRM 连接器，以实时将新的访客档案和会话事件推送到 Salesforce。将 Purple 的数据字段（电子邮件、访问次数、停留时间、身份验证方法）映射到相应的 Salesforce 联系人和活动成员对象。这使体育场的营销团队能够在终场哨响后的几分钟内触发自动化的赛后电子邮件活动。
场内调查： Purple 的 MicroSurvey 功能可在身份验证后触发，在欢迎页面重定向中显示 1-3 个问题的调查。对于体育场部署，将调查配置为对随机抽样的 20% 已认证客人触发，以避免调查疲劳，同时保持统计显著性。
Practice Questions
Q1. 一家拥有 80 家门店的零售连锁店在其整个资产中部署了 Cisco Meraki MR33 接入点。他们希望实施 Purple WiFi，但其安全团队对为访客访问部署开放式 SSID 表示担忧。安全团队认为所有 SSID 至少应使用 WPA2 加密。您如何应对这一担忧？访客 WiFi 部署的正确安全架构是什么？
Hint: 考虑链路层加密（WPA2）与应用层身份验证（Captive Portal + RADIUS）的区别。还要考虑 PurpleConnex SSID 提供了什么。
View model answer
安全团队的担忧原则上是有道理的，但反映了两项不同安全目标的混淆。WPA2 加密保护客户端设备与接入点之间的无线链路——防止在无线介质上窃听。然而，对于公共访客网络，WPA2 Personal（PSK）提供的实际安全性很小，因为预共享密钥顾名思义是所有客人公开知道的。知道 PSK 的任何访客都可以使用被动捕获攻击解密其他客人的流量。
正确的架构是：将访客 SSID 部署为开放式（无 WPA2），并使用 Captive Portal 进行身份验证。这是公共访客 WiFi 的行业标准方法，因为它允许 Captive Portal 在客人到达欢迎页面之前无需知道密码就能运行。安全模型依赖于应用层控制（欢迎页面上的 HTTPS、RADIUS 身份验证、VLAN 隔离），而不是链路层加密。
对于需要加密传输的客人，PurpleConnex SSID 提供了 WPA2 Enterprise 安全性和 RadSec RADIUS——这是真正安全的，因为每个客户端都从其 EAP 凭据中获得唯一的加密密钥。拥有 PurpleConnex Passpoint 配置文件的回头客将自动连接到此加密 SSID。
因此，完整的安全架构是：用于首次访客入门的开放式 SSID（Captive Portal + RADIUS 身份验证 + VLAN 隔离）+ 用于回头客的 WPA2 Enterprise PurpleConnex SSID（RadSec + Passpoint）。这既满足了访客体验要求，也满足了安全团队对回头客的加密要求。
Q2. 一个会议中心正在其 Meraki 资产上首次部署 Purple WiFi。上线三周后，营销团队报告称 Purple 分析仪表板显示了总会话数，但没有每个房间或每个区域的数据——所有会话似乎都归因于一个位置。进行配置的网络工程师已离开该组织。最可能的原因是什么？您如何诊断并解决？
Hint: 考虑 Purple 使用哪个 RADIUS 属性将会话映射到物理位置，以及该属性的默认 Meraki 配置是什么。
View model answer
最可能的原因是 NAS-ID 和/或 Called-Station-ID RADIUS 属性未配置为使用 AP MAC 地址。当这些字段设置为静态字符串、SSID 名称或保留默认值时，资产中的每个接入点在其 RADIUS 消息中发送相同的标识符。Purple 的分析引擎从所有 AP 接收到相同的位置标识符，无法区分它们，从而导致所有会话归因于一个（或未知）位置。
诊断：在 Meraki 仪表板中，导航到访客 SSID 的无线 > 访问控制。滚动到高级 RADIUS 设置。检查 Called-Station-ID 和 NAS-ID 的值。如果任一字段显示的不是 AP MAC 地址——例如 SSID 名称、静态字符串或多个值——这就是根本原因。
解决：将 Called-Station-ID 和 NAS-ID 都设置为仅使用 AP MAC 地址。从这些字段中删除任何其他值。保存配置。注意，此更改对新会话生效——现有的活跃会话不会追溯重新归因。配置更改后的 5-10 分钟内，Purple 分析仪表板中的新会话数据应开始显示每个 AP 的归因。
如果在纠正 RADIUS 属性配置后问题仍然存在，请验证 Purple Portal 是否导入了正确的 AP MAC 地址并与正确的平面图区域关联。如果 AP 是在配置平面图之前导入的，则可能需要在 Purple Portal 的场所管理设置中更新 MAC 到区域的映射。
Q3. 一家拥有 500 张床位的 NHS 医院信托基金希望在其现有的 Cisco Meraki 基础设施上部署 Purple WiFi，以提供患者和访客 WiFi。关键要求是：数据采集符合 GDPR 合规性、内容过滤以屏蔽患者网络上的不当内容、长期住院患者（多天入院）的无缝连接，以及通过 API 与其现有患者参与平台集成。Purple 的哪些功能和 Meraki 配置元素分别满足这些要求？
Hint: 考虑 Purple 的合规功能、Purple Shield DNS 过滤、用于长期住院患者的 PurpleConnex，以及 Purple 的 API/连接器功能用于患者参与平台集成。
View model answer
每个要求都对应特定的 Purple 功能和 Meraki 配置组合：
GDPR 合规性： Purple 的 Captive Portal 在身份验证时提供同意机制，捕获对数据处理的明确选择加入。Purple Portal 的数据治理设置允许配置符合 NHS 数据治理策略的数据保留期限。Purple 原生支持数据主体访问请求和擦除权。欢迎页面应配置为清晰、朴素的语言同意措辞——而不是隐藏在条款与条件中——以满足 GDPR 对知情、明确同意的要求。
内容过滤： Purple Shield 是 Purple 的云原生 DNS 过滤服务。它在基础设施层面运行，在 DNS 查询解析之前进行过滤，并可以配置适合患者环境的基于类别的拦截（成人内容、赌博、恶意软件等）。这在 Purple Portal 中配置，无需额外硬件即可应用于访客 SSID 上的所有已验证会话。
长期住院患者的无缝连接： 部署带有 Hotspot 2.0（Passpoint）配置的 PurpleConnex。一旦患者完成一次身份验证并下载了 Passpoint 配置文件，他们的设备将在后续关联时自动连接——包括设备从睡眠中唤醒、在病房之间移动或短暂断开后重新连接。这消除了每日重新身份验证的摩擦，这是医院 WiFi 部署中的常见投诉。
患者参与平台集成： Purple 的平台公开了一个 REST API，并支持预先构建的主要 CRM 和参与平台连接器。配置 Purple Portal 的 API 连接器，将已验证的会话事件（如果登录时捕获的患者 ID、会话开始/结束、病房级位置数据）实时推送到患者参与平台。如果参与平台不在 Purple 的预构建连接器库中，REST API 允许自定义集成开发。