许多 IT 总监接手的网络架构都如出一辙。一家酒店拥有稳定的光纤线路和合理的防火墙规则，而下一家门店则使用不同的运营商、不同的路由器标准以及没人敢在节假日前夕改动的 VPN。在零售行业，情况往往更为糟糕。新店开设迅速，云应用成倍增加，网络最终变成由 MPLS、宽带、本地临时方案和过多特例拼凑而成的“大杂烩”。
当宾客 WiFi、员工访问、云应用和安全策略都需要在所有场所保持一致时，这种模式就会分崩离析。WAN as a service 代表着一种转变：不再将每个分店当作一个小型的网络项目来运营，而是将广域网连接作为一种托管的、云端交付的服务来使用。对于分布式组织而言，这并非概念炒作，而是维持运营秩序的实际需要。
摆脱传统网络痛点
一个不断壮大的酒店集团通常不会因为无法访问互联网而失败。它的困境在于每个场所的网络表现都各不相同。
一个场所拥有可靠的连接，但宾客与员工流量之间的隔离做得很差。另一个场所有着不错的宾客 WiFi，但访问云端 PMS 或协作工具的速度很慢。第三个场所急需进行调整以支持翻新或临时活动，但网络却依赖于本地设备、运营商的交付周期，以及是否有人记得上一个承包商是如何配置 VPN 的。
这就是核心痛点。孤立来看并不是带宽问题，而是不一致性。
对于零售连锁店来说，情况也类似。收银系统、库存管理、数字标牌、员工设备和宾客访问都在一个从未设计用于大规模集中管理的分支机构网络上相互竞争。IT 团队花费了太多时间来解决本地问题，而没有足够的时间来提升整体网络资产。
为什么这种模式正在改变
市场之所以发生变化，是因为企业希望网络能够表现得更像云基础设施。根据 Market.us 的网络即服务市场统计数据 ，全球 NaaS 市场在 2022 年估值为 115 亿美元，到 2023 年增长至 146 亿美元，预计到 2032 年将达到 1155 亿美元。
这一增长至关重要，因为它反映了企业 IT 团队正在做出更广泛的决策。他们不想再将每个分支机构作为一堆设备、线路和特例来管理。他们需要集中的策略、更干净利落的部署以及可预测的服务交付。
实用规则：如果新增一个场馆仍意味着需要逐个站点重建安全、路由和访问策略，那么您的 WAN 模式正在阻碍业务的发展。
哪些方面最先得到改善
当组织摆脱传统的网络分支机构网络时，最先获得的通常是运营方面的收益：
- 更快速的站点标准化，因为策略存在于中央平台中，而不是取决于本地设备的差异。
- 更清晰的故障排查，因为团队可以查看各个场所的流量路径和系统健康状况。
- 更佳的用户体验，无论是对员工还是访客，因为网络连接不再取决于多年前每个站点的建设水平。
关键点不在于 WANaaS 让网络凭空消失。它没有。它改变了复杂性存在的位置以及必须由谁来管理它。
解构 WAN as a Service（广域网即服务）
如果想要最简单的解释，wan as a service 就是将云消费模式应用于广域网。这与许多团队在电子邮件、身份和基础设施方面已经接受的心态转变是一样的。您不再需要拥有每个站点的每个活动部件，而是开始消费一个从中央控制面处理传输、路由逻辑、可视化以及通常包括安全的服务的模式。
核心架构转变
传统的广域网设计将性能和策略与分支机构硬件紧密绑定。WANaaS 通过采用软件定义模型改变了这一点。WANaaS 平台利用软件定义网络来分离控制面和数据面，从而能够根据实时网络状况，在 MPLS、宽带和 5G 之间实现动态流量路由，正如 Red River 对 WAN as a service 的概述 中所描述的那样。
在实际应用中，这意味着分支机构不再需要孤立地做出每一个决策。策略在中央定义，然后一致应用。服务可以根据应用程序需求、路径质量、弹性要求或业务规则来引导流量。
对于 IT 总监来说，有价值的问题不是架构是否优雅，而是正确的流量是否在没有对每个场所进行手动调整的情况下得到了正确的处理。
这些活动部件实际上在起什么作用
以下三个组件最重要：
底层接入网络 (Access Underlay)
这是您已经熟知的物理连接。光纤、宽带、移动备份或混合连接。WANaaS 并没有消除对线路的需求，而是让它们更容易协同工作。软件定义叠加网络 (Software-Defined Overlay)
这是路径选择、流量引导、分段和弹性逻辑所在的位置。正是它让一个站点能够使用多种连接类型而不会变得混乱。云端管理层
这是许多团队最看重的部分。你将获得中央可视化、统一策略以及比逐个分支机构管理更利于扩展的服务模式。
关于这种运营模式，一个有用的外部视角是 使用 WaaS 优化商业网络 ，它勾勒出了从僵化的、以站点为中心的 WAN 设计向基于服务的管理模式的转变。若要更广泛地了解云交付网络模式，Purple 自身的 网络即服务 指南也同样值得阅读。
将 WANaaS 视为一种运营模式，而非电路替代。如果只是更换传输介质却保留原有的手动流程，你将无法获得核心优势。
哪些行得通，哪些行不通
行得通的是利用 WANaaS 来简化跨多个场所的控制。酒店集团可以在中央优先处理 PMS、支付、语音和员工协作流量，同时保持访客接入的隔离。零售商可以在所有地方推出相同的分支机构策略，而无需逐个门店重建网络设计。
行不通的是指望 WANaaS 单独解决糟糕的应用设计、薄弱的身份控制或不一致的 LAN 标准。它改善了 WAN，但无法消除所有上游和下游的问题。
WANaaS 与 MPLS 及 SD-WAN 的对比
一个季度内开设三家重新装修的物业的酒店集团不需要另一个分支机构设计项目。它需要每个站点快速上线，并在第一天就确保支付、PMS、员工应用和访客 WiFi 运行一致。这就是将 WANaaS 与 MPLS 和 SD-WAN 进行对比的背景。
大多数 IT 团队并非在一张白纸上进行选择。他们通常需要协调多年来逐步累积的 MPLS、自管理 SD-WAN、普通互联网链路以及分支机构安全设备的混合环境。
流量模式也发生了变化。与以星型（Hub-and-Spoke）WAN 设计为默认设置的时期相比，如今的企业将更多的流量直接发送到云和 SaaS 平台。正如 企业 WAN 现状报告 中指出的那样，这种转变与更广泛的 SASE 采纳齐头并进。一旦分支机构流量直接流向 Microsoft 365、云 PMS 平台、协作工具和身份服务，就很难再为通过中心节点回传所有流量寻找合理解释了。
网络架构对比
| 评估标准 | MPLS | DIY SD-WAN | WAN 即服务 |
|---|---|---|---|
| 云端契合度 | 通常围绕中央回传构建 | 若设计得当，能较好地适应云端 | 围绕云交付策略和服务消费而设计 |
| 运营所有权 | 高度依赖运营商和合同，且本地分支机构复杂度高 | 在设计、硬件和生命周期管理方面，内部责任重大 | 更多责任落在服务提供商和云管理层 |
| 新站点敏捷性 | 通常较慢且灵活性较低 | 比 MPLS 更灵活，但部署质量取决于您的团队和工具 | 非常适合在分布式场所进行标准化的分支机构部署 |
| 安全模型 | 历史上与传输分离 | 可以很强，但通常需要多个集成 | 通常构建有集成的安全控制和中央策略 |
| 硬件负担 | 显著的分支和边缘依赖 | 在许多部署中仍然很重 | 在云原生模型中，本地复杂度较低 |
| 最佳适用场景 | 流量可预测且规划周期长的稳定资产 | 希望进行控制并能承担运营开销的团队 | 希望获得托管敏捷性、中央策略和更清晰扩展规模的企业 |
MPLS 仍有一席之地的地方
MPLS 仍然适合某些环境。如果企业拥有高度稳定的站点、漫长的规划周期、严格的运营商关系以及少量可预测的应用，它仍然是有用的。
问题不在于 MPLS 停止了工作。问题在于许多酒店和零售资产在其周围发生了变化。新站点的开设速度更快。更多服务托管在云端。宾客对 WiFi 质量的期望更高。员工越来越多地通过云身份平台进行身份验证，而这些身份决策需要分支网络快速、一致地做出响应。
DIY SD-WAN 在哪些方面有帮助，在哪些方面有弊端
DIY SD-WAN 解决了真正的空白。它为网络团队提供了路径选择、传输灵活性以及对宽带和互联网线路的更好利用。对于拥有强大内部工程能力的企业，这种控制权仍然值得拥有。
但权衡之下是运营重量。您的团队仍必须选择供应商、维护边缘硬件、更新软件、集成防火墙和安全 Web 网关、排除分支机构异常，并保持每个场所的标准一致。在零售连锁或酒店资产中，分支机构的数量增长通常快于网络团队的增长。
如果您正在评估这种额外的控制权是否值得付出支持负担，Purple 关于 分布式企业 SD-WAN 优势 的指南是一个有用的参考点。
MPLS 牺牲了灵活性以换取可预测性。DIY SD-WAN 牺牲了灵活性以换取工程工作量。WANaaS 专为希望拥有中央策略和更快部署速度、而无需拥有堆栈中每个部分的组织而设计。
选择团队能够良好运行的模型
核心决策与其说是关于功能清单，不如说是关于运营模式。
一支能力出众的网络工程团队可能更喜欢设计自己的 SD-WAN、安全堆栈和云集成。如果企业乐意承担生命周期的负担，这种方式完全行得通。但许多酒店集团、零售商和综合用途场馆运营商希望获得不同的结果。他们希望获得一致的分段、更快的站点激活以及更少的特定分支机构例外情况。
一旦 WiFi 接入与身份绑定，这一点就显得尤为重要。如果访客接入使用 OpenRoaming ，而员工接入依赖于 Entra ID 或 Okta 发行的凭据，则不能将 WAN 视为单独的管道层。策略必须从 WAN 延续到场馆边缘，从而使访客流量保持隔离，员工设备继承正确的访问权限，并且云安全控制可以查看他们所需的系统和设备上下文。WANaaS 比拼凑起来的电路和分支机构设备更适合这种模型，因为它为您提供了一种更清晰的方法来跨站点应用策略，然后将其扩展到访客和员工使用的 WiFi 体验。
将安全构建到您的 WAN 架构中
旧的分支机构模型将安全视为在连接就绪后添加的一个层。这种方法会导致配置飘移。一个站点可能获得略有不同的防火墙策略。另一个站点延迟了硬件更新。第三个站点则存在无人妥善记录的例外情况。久而久之，WAN 虽然连接了起来，但并未得到一致的保护。
现代 WANaaS 通过将安全作为服务架构的一部分来改变这一点。
根据 Cloudflare 的 WAN 服务白皮书，现代 WANaaS 作为一种云原生解决方案运行，在每一层都集成了防火墙、DDoS 缓解和零信任协议，同时消除了大部分硬件生命周期负担，并通过单一仪表板提供统一的安全态势。
为什么这在多站点环境中至关重要
酒店、购物中心或医疗保健机构需要的不仅仅是 “安全互联网”。它需要对不同类型的流量进行不同的处理。
访客流量应与业务系统保持隔离。员工设备应根据身份和角色继承策略。支付系统、管理工具、物联网以及第三方租户服务通常需要自己的专属通道。如果这种分段取决于本地分支机构防火墙的手工配置，一致性将无法持久。
WANaaS 从两方面对此进行了改进：
- 策略集中化，确保每个场所不会成为孤立的安全孤岛。
- 集成安全服务，而不是通过一系列独立产品和手动交接进行拼凑。
优秀的安全设计是怎样的
在实践中，强大的 WANaaS 安全通常包括：
- 身份感知访问决策，确保用户和设备不会仅因处于正确的子网而获得广泛的访问权限。
- 流量隔离，将访客、员工、运营系统和租户区分开来。
- 集中检查与监控，以便团队能够统一执行策略并调查问题，而无需单独登录每个分支机构。
这种架构在混合了信任和非信任用户的场所中特别有用。酒店和商场是显而易见的例子，但学生公寓、诊所和住宅建筑也面临同样的问题。一个物理站点可能包含多个信任区域。
分支机构不应仅凭位置来决定安全性。它应该根据身份、角色和流量类型来执行策略。
需要注意的权衡
这需要进行权衡。当您将更多控制权转移到服务商的云平台时，您的可见性和故障排除模式就会发生变化。您的团队需要了解服务商的工具、日志和策略工作流程。如果管理层面成熟且您的流程能够适应它，这就是一个公平的交换。但如果您购买了 WANaaS，却坚持像管理旧的分支机构防火墙资产那样管理每个站点，那就是一个糟糕的交换。
将 WANaaS 与基于身份的 WiFi 访问相结合
访客走进酒店，通过 OpenRoaming 加入 WiFi，打开会员应用程序，并期望它能立即工作。与此同时，前台员工使用绑定到 Entra ID 或 Okta 的证书在员工设备上登录。如果这两个会话落在同一个本地网络上，仅通过 VLAN 标签进行隔离，那么 WAN 所能获取的内容极其有限。它只能看到流量，而看不到意图。
这种差距在分布式场所中非常重要。酒店、零售物业、诊所和综合体建筑通常会投资于更好的 WAN 策略，却将 WiFi 访问决策孤立在分支机构。其结果显而易见：访客获得了不错的自助入网流程，员工获得了独立的身份验证方式，而总部 IT 仍必须维护广泛的网络区域，因为在流量到达 WAN 策略引擎之前，身份信息就已经丢失了。
更好的设计是将身份标识从设备加入 WiFi 的那一刻起，就带入到整个 WAN 和云安全堆栈所使用的策略模型中。Purple 非常符合这种模式，因为它支持通过 OpenRoaming 和 Passpoint 进行无密码访客接入，以及与 Entra ID、Okta 和 Google Workspace 绑定的基于证书的员工接入。WiFi 平台首先对用户进行分类。然后，WANaaS 利用该分类来应用正确的路径、检查和访问控制。
如何将身份扩展到 WAN 边缘
在实践中，工作流程应如下所示：
在 WiFi 上对用户进行身份验证
- 访客用户通过 OpenRoaming 或 Passpoint 加入。
- 员工用户使用与 Entra ID 或 Okta 绑定的证书或支持目录的方法进行身份验证。
在接入层分配角色
- 访客
- 员工
- 承包商
- IoT 或共享设备
将该角色传递给网络策略
- 根据您的 WLAN 和 WANaaS 堆栈，将经过身份验证的角色映射到 VLAN、SGT、VXLAN 分段或等效的策略标签。
- 保持每个场所的映射一致。
根据身份（而不仅是 SSID）应用 WANaaS 策略
- 访客流量流向具有网页过滤和速率策略的本地互联网分流。
- 员工流量流向为员工访问定义的私有应用程序、SaaS 控制和检查点。
- 运营设备遵循一条具有更严格东西向限制的独立路由。
集中记录身份和策略决定
- 服务台应该能够快速回答三个问题。谁连接了？他们被分配了什么角色？这触发了哪个 WAN 策略？
这就是许多 WANaaS 项目中缺失的环节。
一个实际的策略示例
一个 OpenRoaming 访客不应该仅仅落入“访客 WiFi”。对于现代运营来说，这个标签太模糊了。该会话应该映射到 WAN 架构中定义的策略对象，例如：
- 身份源： Purple OpenRoaming 身份验证
- 角色： 访客
- 网络分段： 仅限访客互联网
- WAN 策略： 本地分流、DNS 过滤、带宽上限、阻止访问私有 RFC1918 范围、禁止向场所系统进行横向移动
- 日志记录： 会话开始、场所、设备类别、应用的策略
使用托管平板电脑的员工应遵循不同的路径：
- 身份源： 通过 Purple 进行的基于 Entra ID 或 Okta 证书的身份验证
- 角色： 员工
- 网络分段： 员工安全访问
- WAN policy: Route to business apps, allow approved SaaS, inspect traffic according to company policy, block access to guest and IoT segments
- Logging: User identity, device posture if available, application access events, policy changes
That is how WAN-level segmentation reaches the WiFi edge in a usable way. The WLAN decides who the user is. The WANaaS platform decides what that identity is allowed to do across sites, cloud services, and internet breakout.
What IT teams need to standardise
The hard part is rarely authentication itself. The hard part is policy consistency.
If one hotel maps staff to VLAN 20, another maps them to VLAN 40, and a third relies on a local firewall object nobody documented, the WANaaS provider cannot enforce a clean identity-based model across the estate. Standard role definitions matter more than perfect circuit uniformity. A retail chain with 300 stores is usually better served by four or five well-governed identity classes than by dozens of site-specific exceptions.
Teams evaluating branch architecture often hit this point when comparing local SD-WAN policy with cloud-managed WAN controls. These SD-WAN use cases for distributed venues are a useful reference for how application and access policy play out at site level.
The trade-off to plan for
Identity-based enforcement improves control, but it also raises the quality bar for integration. WLAN, identity provider, NAC or policy engine, and WANaaS must agree on role names, policy tags, and failure handling. If Entra ID is unavailable, what happens to staff onboarding? If OpenRoaming succeeds but the policy tag fails to sync, does the user fall into a restricted holding policy or gain broad internet access by mistake?
Good designs answer those questions early. They define a fallback policy, keep role mapping simple, and test onboarding from the user perspective, not just from the admin console.
If Purple identifies the user and the WANaaS platform cannot consume that identity in a consistent way, you have better WiFi onboarding but not better network control.
That is why identity-based WiFi access should be designed as part of the WAN architecture, not attached later as a branch feature.
WANaaS in Action Across Your Venues
The architecture matters because of what it fixes on the ground. Different sectors hit different problems, but the pattern is consistent. Distributed venues need central control without flattening every local requirement.
Hospitality
酒店集团通常希望同时实现三个目标。无缝的宾客入网、安全的员工接入以及各分店之间一致的应用性能。
借助 WANaaS，该集团可以在所有酒店应用统一的路由和分段模型，同时适应本地线路的可用性。宾客流量得以干净利落地分流，员工流量安全地接入业务系统，而总部 IT 团队无需单独调整每个场所。如果您正在评估 SD-WAN 和云管理 WAN 模式在运营上的契合度，这些 适用于分布式场所的 SD-WAN 使用案例 将为您提供有用的背景信息。
零售业
零售店会迅速淘汰脆弱的网络。支付流量不能干等宾客浏览网页变慢。数字标牌、会员应用、手持设备和云库存工具都需要可预测的处理方式。
这里行之有效的是应用感知策略与严格分段的结合。WANaaS 可以优先处理业务关键流量，同时保留可用的宾客体验。而给每个门店提供宽带互联网访问，并寄希望于本地设备来维持秩序，则是行不通的。
医疗保健
诊所和门诊场所需要的不仅仅是互联网可达性。他们需要对核心应用的可靠访问、对临床和非临床流量的清晰隔离，以及更简单的运营监管。
当医疗保健资产分布在许多本地 IT 力量薄弱的小型场所时，WANaaS 模型可以提供帮助。中央团队可以标准化策略、降低分支机构的复杂性，并避免将每个诊所都变成一次性的设计。
住宅与多租户
对于传统的分支机构思维来说，租房建设（Build-to-rent）、学生公寓和综合体物业是很棘手的，因为一栋大楼的行为可能像许多个独立的网络。居民想要家一样的体验。员工需要受管访问。共享系统和传统设备仍需要控制。
一个优秀的 WANaaS 设计可以支持单租户隔离、清晰的访问边界和集中管理。重要的启示是，这些环境不“仅仅是 WiFi 项目”。它们需要 WAN、身份识别和分段协同工作。
最强大的场所网络不仅仅是连接各个站点。它们在各个物业之间保持一致的信任模型。
规划向 WANaaS 的迁移
最成功的 WANaaS 迁移始于业务摩擦，而非产品演示。如果您从供应商的功能表开始，就会遗漏对您的资产至关重要的运营问题。
从您已有的资产开始
按业务关键性、用户类型、访问方式和支持负担来审核站点。旗舰酒店、小型零售分店和医疗诊所今天可能都位于同一个 WAN 上，但它们对中断、延迟或策略错误的容忍度是不同的。
梳理每个场所的真实运行情况：
- 流量行为，覆盖访客、员工、运营和第三方使用情况
- 用户、设备和遗留设备的身份验证路径
- 分支机构依赖关系，例如本地防火墙、VPN 或运营商管理的分界点
从运营角度定义成功
保持目标务实。优秀的迁移计划通常将成功定义为：更少的本地特例、更干净的新场所入网流程、更强的细分隔离以及更快的故障隔离。
直接提问：新项目能否直接继承标准网络设计，而无需开展定制化工程？员工身份变更能否干净地同步到访问策略中？访客和运营流量能否在不增加本地规则蔓延的情况下保持隔离？
仔细选择服务模式
WANaaS 提供商之间差异巨大。有些在传输灵活性方面表现强劲，但在身份集成方面较弱；另一些拥有坚实的安全框架，但运营工具却很繁琐。
在做出承诺之前，请检查：
- 策略模型。它能否表达您运行的信任域和用户类型？
- 可见性。您的团队能否获得实用的监控和排障数据？
- 集成。它能否与您的 WLAN、身份提供商以及云应用程序干净地对齐？
- 部署方式。提供商是否支持分阶段采用，而无需进行高风险的硬切换？
在几个具有代表性的场所进行短期试点，通常比听一场天花乱坠的销售演示能学到更多。选择拥有不同线路类型、不同用户组合以及至少有一个棘手遗留依赖关系的站点。如果该模式在这些站点行得通，那么它就有可能很好地进行规模化扩展。
如果您正在评估酒店、零售店、医疗机构或多租户场所中，访客 WiFi、员工身份和 WAN 策略应该如何协同工作， Purple 是一个很好的切入点。它专注于无密码访客访问、基于身份的员工连接以及集中策略控制，这使它在您试图将 WiFi 访问决策与更广泛的 WANaaS 和零信任设计相连接时非常有用。
