Azure 虚拟 WAN 可让公司简化其全球连接，以便充分利用 Azure 全球网络的规模。 本文为希望从现有的客户管理的中心辐射拓扑迁移到利用 Azure 托管的 虚拟 WAN 中心设计的公司提供技术详细信息。
若要了解 Azure 虚拟 WAN 为那些采用以云为中心的新式企业级全球网络的企业带来的好处，请参阅全球传输网络体系结构和虚拟 WAN。
插图：Azure 虚拟 WAN
数千客户已采用 Azure 中心辐射连接模型，以利用 Azure 网络的默认传递路由行为来构建简单且可缩放的云网络。 Azure 虚拟 WAN 基于这些概念，并引入了新功能。新功能不仅允许本地位置和 Azure 之间的全球连接拓扑，还允许客户利用大规模的 Azure 网络来扩展其现有的全球网络。
本文介绍如何将客户管理的现有中心辐射型环境迁移到基于 Azure 虚拟 WAN 的拓扑。
场景
Contoso 是一家全球金融组织，在欧洲和亚洲设有办事处。 他们计划将现有应用程序从本地数据中心迁移到Azure，并基于客户托管的中心辐射体系结构（包括用于混合连接的区域中心虚拟网络）构建了基础设计。 在迁移到基于云的技术的过程中，网络团队的任务是确保针对不断发展的业务优化其连接。
下图显示了现有全球网络的概览性视图，其中包括与多个 Azure 区域的连接。
插图：Contoso 的现有网络拓扑
从现有网络拓扑中可了解以下几点：
已在多个区域使用了中心辐射型拓扑，其中包括用于连回到公共专用广域网 (WAN) 的 ExpressRoute 线路。
其中一些站点还将 VPN 隧道与 Azure 直接连接，以访问云中托管的应用程序。
要求
网络团队的任务是提供一个全球网络模型，该模型可以支持 Contoso 向云的迁移，且必须在成本、规模和性能方面进行优化。 总而言之，需要满足以下要求：
- 为总部 (HQ) 和分支机构提供云托管应用程序的优化路径。
- 消除对现有本地部署的数据中心 (DC) 进行 VPN 终止的依赖，同时保留下列连接路径：
- 分支机构到 VNet：通过 VPN 连接的办公室必须能够访问已迁移到本地 Azure 区域云端的应用程序。
- 分支到中心，再到中心到 VNet：通过 VPN 连接的办公室必须能够访问已迁移到远程 Azure 区域云中的应用程序。
- 分支到分支：连接区域 VPN 的办事处必须能够相互通信，且能够与连接 ExpressRoute 的 HQ/DC 站点通信。
- 分支到中心再到分支：全球异地分布并通过 VPN 连接的办公室必须能够彼此通信，并与任何通过 ExpressRoute 连接的总部/数据中心（HQ/DC）站点通信。
- 分支机构到互联网：已连接的站点必须能够与互联网通信。 必须筛选并记录此流量。
- VNet-to-VNet：同一区域中的辐射状虚拟网络之间必须能够相互通信。
- VNet 到 Hub 再到 Hub 到 VNet：不同区域中的辐射型虚拟网络之间必须能够相互通信。
- 使 Contoso 漫游用户（笔记本电脑和手机）无需连接公司网络即可访问公司资源。
Azure 虚拟 WAN 体系结构
下图显示了更新后的目标拓扑的概览性视图，该拓扑使用 Azure 虚拟 WAN 来满足上一部分详述的要求。
插图：Azure 虚拟 WAN 体系结构
摘要：
- 欧洲 HQ 仍连接 ExpressRoute，而欧洲本地 DC 已完全迁移到 Azure，现已停用。
- 亚洲 DC 和 HQ 仍连接专用 WAN。 Azure 虚拟 WAN 现用于扩展本地运营商网络并提供全球连接。
- 在中国东部 2 和中国北部 3 这两个 Azure 区域中部署了 Azure 虚拟 WAN 中心，作为通过 ExpressRoute 和 VPN 连接的设备的连接枢纽。
- 中心还为使用多种客户端的漫游用户提供通过 OpenVPN 连接到全局网状网络的 VPN 终结，使其不仅能够访问已迁移到 Azure 的应用程序，还能够访问仍保留在本地环境中的任何资源。
- Azure 虚拟 WAN 所提供虚拟网络内资源的 Internet 连接能力。
远程站点的互联网连接也由 Azure 虚拟 WAN 提供。 通过合作伙伴集成，支持互联网本地分流，以优化对 Microsoft 365 等 SaaS 服务的访问。
迁移到虚拟 WAN
本部分介绍迁移到 Azure 虚拟 WAN 的各个步骤。
步骤 1：单区域客户管理的中心辐射型架构
下图显示 Azure 虚拟 WAN 推出之前 Contoso 的单区域拓扑：
图 1：单区域手动轮辐式拓扑
按照中心辐射型方法，客户管理的中心虚拟网络包含几个功能块：
- 共享服务（多个辐条所需的任何通用功能）。 示例：Contoso 在基础结构即服务 (IaaS) 虚拟机上使用 Windows Server 域控制器。
- IP/路由防火墙服务由第三方网络虚拟设备提供，可实现辐射点之间的第 3 层 IP 路由。
- Internet 入口/出口服务，其中包括用于入站 HTTPS 请求的 Azure 应用程序网关，以及在虚拟机上运行且用于已筛选的 Internet 资源出站访问的第三方代理服务。
- ExpressRoute 和 VPN 虚拟网关，用于连接到本地网络。
步骤 2：部署虚拟 WAN 中心
在每个区域中部署虚拟 WAN 中心。 按以下文章所述，使用 VPN 和 ExpressRoute 功能设置虚拟 WAN 中心：
注意
若要启用本文所述的某些流量路径，Azure 虚拟 WAN 必须使用标准 SKU。
图 2：从客户管理的中心辐射型网络迁移到 虚拟 WAN
步骤 3：将远程站点（ExpressRoute 和 VPN）连接到虚拟 WAN
将虚拟 WAN 中心连接到现有 ExpressRoute 线路，并通过 Internet 在任何远程分支上设置站点到站点 VPN。
图 3：从客户管理的中心辐射型拓扑迁移到虚拟 WAN
此时，本地网络设备将开始接收路由，这些路由表明分配给虚拟 WAN 托管中心 VNet 的 IP 地址空间。 在此阶段，连接 VPN 的远程分支将在辐射虚拟网络中显示两条指向任何现有应用程序的路径。 这些设备应配置为继续使用指向客户托管中心的隧道，以确保转换阶段的对称路由。
步骤 4：通过虚拟 WAN 测试混合连接
在将托管的 虚拟 WAN 中心用于生产环境连接之前，我们建议您先设置一个测试用分支虚拟网络和 虚拟 WAN VNet 连接。 继续执行后续步骤之前，通过 ExpressRoute 和站点到站点 VPN 验证此测试环境的连接是否正常工作。
图 4：从客户管理的中心辐射型拓扑迁移到虚拟 WAN
在此阶段，必须认识到，原来的客户管理的中心虚拟网络和新的虚拟 WAN 中心都连接到同一条 ExpressRoute 线路。 因此，我们有一条可用于使两种环境中的分支进行通信的通信路径。 例如，来自连接到客户管理中心虚拟网络的分支的流量会遍历用于 ExpressRoute 线路的 MSEE 设备，以访问通过 VNet 连接连接到新虚拟 WAN 中心的任何分支。 这样就可以在步骤 5 中分阶段迁移分支。
步骤 5：将连接转换到虚拟 WAN 中心
图 5：从客户管理的中心辐射型拓扑迁移到虚拟 WAN 中心
a. 删除从辐射型虚拟网络到旧的客户管理中心网络的现有对等互连。 在完成 a-c 步骤之前，将无法访问辐射型虚拟网络中的应用程序。
b. 通过 VNet 连接将辐射型虚拟网络连接到 虚拟 WAN 中心。
c. 删除先前在辐射虚拟网络中用于辐射虚拟网络之间通信的任何用户定义路由 (UDR)。 虚拟 WAN 中心内提供的动态路由现已启用此路径。
d. 客户托管中心内的现有 ExpressRoute 和 VPN 网关现已停用，以便执行下一个步骤 (e)。
e. 通过新的 VNet 连接将旧的客户托管中心（中心虚拟网络）连接到虚拟 WAN 中心。
步骤 6：旧中心网络变为共享服务分支网络
现已重新设计了 Azure 网络，使虚拟 WAN 中心成为了新拓扑的中心点。
图 6：从客户管理的中心辐射型拓扑迁移到 虚拟 WAN
由于虚拟 WAN 中心是托管实体，且不允许部署虚拟机之类的自定义资源，因此共享服务功能块现以辐射虚拟网络形式存在，该网络通过 Azure 应用程序网关或网络虚拟设备托管 Internet 入口等功能。 现在，共享服务环境与后端虚拟机之间的流量在虚拟 WAN 托管的中心内传输。
步骤 7：优化本地连接以充分利用虚拟 WAN
在此阶段，Contoso 基本已将业务应用程序迁移到 Azure 云，仅少量旧版应用程序保留在本地 DC。
图 7：从客户管理的中心辐射拓扑迁移到虚拟 WAN
为利用 Azure 虚拟 WAN 的全部功能，Contoso 决定停用其旧的本地 VPN 连接。 任何仍需访问总部或数据中心网络的分支机构，都能够利用 Azure 虚拟 WAN 的内置中转路由，通过 Azure 全球网络传送流量。
注意
对于希望利用 Azure 主干网提供 ExpressRoute 到 ExpressRoute 的传输（图 7 中未显示）的客户，ExpressRoute Global Reach 是必需的。
最终状态体系结构和流量路径
图：双区域虚拟 WAN
本节通过介绍一些示例流量来概述此拓扑如何满足初始要求。
路径 1
路径 1 显示流量从亚洲的 S2S VPN 连接分支流向中国北部 3 区域的 Azure VNet。
流量按如下方式路由：
亚洲分支机构通过启用了 S2S BGP 的高弹性隧道连接到中国北部 3 的 虚拟 WAN 中心。
亚洲虚拟 WAN 中心将流量本地路由到连接的 VNet。
路径 2
路径 2 显示了从通过 ExpressRoute 连接的欧洲总部到中国北部 3 区域中的 Azure VNet 的流量流向。
流量按如下方式路由：
欧洲总部通过 ExpressRoute 线路接入中国东部 2 虚拟 WAN 中心。
虚拟 WAN 中心间全局连接使流量能够中转到远程区域中连接的 VNet。
路径 3
路径 3 显示了从连接到专用 WAN 的亚洲本地 DC 到连接欧洲 S2S 的分支的通信流。
流量按如下方式路由：
亚洲 DC 连接到本地专用 WAN 运营商。
ExpressRoute 线路在本地终结于专用广域网，并连接到中国北部 3 虚拟 WAN 中心。
虚拟 WAN 中心之间的全球连接可实现流量传输。
路径 4
路径 4 显示流量从中国北部 3 区域的 Azure VNet 流向中国东部 2 区域的 Azure VNet。
流量按如下方式路由：
- 虚拟 WAN 中心到中心的全球连接支持所有已连接的 Azure VNet 之间的原生中转，而无需用户进一步配置。
路径 5
路径 5 显示了从漫游 VPN（P2S）用户流向中国东部 2 区域中 Azure VNet 的流量流向。
流量按如下方式路由：
笔记本电脑和移动设备用户使用 OpenVPN 客户端来透明连接到中国东部的 P2S VPN 网关。
中国东部 2 虚拟 WAN 中心将流量在本地路由到已连接的 VNet。
通过 Azure 防火墙的安全和策略控制
Contoso 现已按照本文前面部分讨论的要求验证了所有分支与 VNet 之间的连接。 为满足对安全控制和网络隔离的要求，他们需要继续通过中心网络来分离和记录流量。 以前，此功能是由网络虚拟设备 (NVA) 执行的。 Contoso 还希望停用其现有的代理服务，并利用原生 Azure 服务对出站 Internet 流量进行筛选。
插图：虚拟 WAN（安全虚拟中心）中的 Azure 防火墙
若要将 Azure 防火墙引入虚拟 WAN 中心以启用统一的策略控制点，需要执行以下高级步骤。 有关此过程的详细信息以及安全虚拟中心的概念，请参阅 Azure 防火墙管理器。
- 创建 Azure 防火墙策略。
- 将防火墙策略链接到 Azure 虚拟 WAN 中心。 此步骤允许现有的虚拟 WAN 中心充当安全虚拟中心，并部署所需的 Azure 防火墙资源。
注意
存在与使用安全虚拟中心（包括区域间流量）相关的约束。 有关详细信息，请参阅防火墙管理器 - 已知问题。
以下路径显示了通过使用 Azure 安全虚拟中心启用的连接路径：
路径 6
路径 6 显示了同一区域中 VNet 之间的安全通信流。
流量按如下方式路由：
连接到同一安全虚拟中心的虚拟网络现通过 Azure 防火墙路由流量。
Azure 防火墙可将策略应用这些流量流。
路径 7
路径 7 显示了 Azure VNet 到 Internet 或第三方安全服务的通信流。
流量按如下方式路由：
连接到安全虚拟中心的虚拟网络使用安全中心作为 Internet 访问的中心点，可以将流量发送到 Internet 上的公共目标位置。
可使用 Azure 防火墙 FQDN 规则以本地方式筛选此流量，也可将其发送到第三方安全服务进行检查。
路径 8
路径 8 显示了从分支到 Internet 或第三方安全服务的流量流向。
流量按如下方式路由：
连接到安全虚拟中心的分支使用安全中心作为 Internet 访问的中心点，可以将流量发送到 Internet 上的公共目标位置。
可使用 Azure 防火墙 FQDN 规则以本地方式筛选此流量，也可将其发送到第三方安全服务进行检查。
后续步骤
- 详细了解 Azure 虚拟 WAN。