<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] Hub-and-Spoke 与 Azure Virtual WAN 之间的连接选项
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# Azure Virtual WAN 与 Hub-and-Spoke 拓扑连接选项的竞争分析
## 解决方案概述
本文档讨论了从传统 Hub-and-Spoke 拓扑迁移到 Azure Virtual WAN 的连接选项,核心目标是为客户提供临时互连策略,以实现无缝迁移。**Azure Virtual WAN** 作为 Azure 的全球网络服务,解决了传统拓扑在扩展性、可管理性上的痛点,适用于大规模混合云环境和企业级网络迁移场景。背景包括:在迁移过程中,确保现有 Spoke vNets 与 Virtual WAN Hub 的临时共存,同时减少中断。技术原理基于 Azure 的路由意图(routing intent)和路由策略(如 Secured Virtual Hub),取代了传统的路由表方法,提供更高效的流量管理和安全控制。该方案在云计算竞争中,相对于 AWS Transit Gateway 或 GCP Network Connectivity Center,具有更强的全球骨干网集成和自动化路由优势,但需考虑特定区域的延迟问题。
## 实施步骤
1. **准备迁移环境**
- 确保目标 Virtual WAN Hub 配置了必要组件(如 Firewall、SD-WAN 或 VPN),并验证现有 vNet 的依赖(如 DNS 或 Active Directory)。
- 对于每个场景,禁用 Use Remote Gateway 配置,以避免路由冲突。理由:这确保了流量正确导向 Virtual WAN Hub,同时维持原有连接。技术原理涉及 Azure 的路由策略,避免 BGP 冲突。
2. **选择并配置连接选项**
- **场景 1(ExpressRoute Hairpinning)**:将 ExpressRoute 电路连接到 Hub 和 Virtual WAN Hub,启用 _Allow Traffic from remote Virtual WAN Networks_ 和 _Allow Traffic from non-Virtual WAN Networks_。详细路径:Spoke vNet → vNet Hub Firewall → ExpressRoute Gateway → MSEE Hairpin → vHub。理由:利用 Azure 骨干网减少外部跳跃,但需激活特定功能以确保路由交换。
- **场景 2(构建虚拟隧道)**:在 vNet Hub 和 vHub 上部署 VPN Gateway 或 SD-WAN NVA,建立 IPSec 隧道。使用 BGP 或静态路由(后者的限制为 ASN 必须为 65515)。路径:Spoke vNet → vNet Hub SD-WAN NVA → 隧道 → vHub Firewall。理由:提供低延迟连接,逻辑上通过 ECMP 平衡多隧道流量。
- **场景 3(vNet Peering 和 vHub 连接共存)**:迁移 Spoke vNet 到 vHub,同时保持与 vNet Hub 的 peering,并配置 UDR 以路由到 vHub。路径:Migrated vNet → vHub Firewall → vHub SD-WAN NVA。理由:启用 Gateway Propagation 以学习 vHub 路由,确保流量对称。
- **场景 4(Transit 虚拟网络)**:为分散式 vNets 创建 Transit vNet,配置静态路由或 BGP Peering。步骤包括:(1) 建立 peering 到 Transit vNet;(2) 移除 ExpressRoute Gateway;(3) 创建 vNet 连接到 vHub。路径:Migrated vNet → Transit Firewall → vHub。理由:最小化停机,通过 Next Hop IP 支持确保流量对称性。
3. **完成迁移并验证**
- 逐步断开原有连接(如 ExpressRoute),并监控流量路径以确认低延迟和高可用性。理由:通过路由总结和 ECMP 优化,确保迁移后环境稳定。逻辑衔接:每个步骤依赖前一级的路由配置,以避免循环或中断。
## 方案客户价值
- **提升网络扩展性和可靠性**:Azure Virtual WAN 方案通过临时连接减少迁移中断,实现业务连续性,与传统 Hub-and-Spoke 相比,可在全球范围内降低管理复杂度,避免单点故障。例如,场景 1 和 2 保持流量在 Microsoft 骨干网内,相比传统拓扑的外部 CPE 路由,显著减少延迟和安全风险。
- **成本优化和性能提升**:场景 3 和 4 无虚拟隧道限制,相比传统方案,可实现无额外吞吐量瓶颈,潜在量化收益如降低延迟(相对于场景 1 的高延迟),通过路由意图自动化管理减少行政开销。相比竞品如 AWS 的手动路由配置,Azure 的内置路由策略提供更高效率,但需权衡额外 NVA 成本。
- **安全与合规优势**:利用 Secured Virtual Hub,确保流量加密和策略控制,相比传统拓扑的静态路由,Azure 方案在混合云环境中提供更强的安全隔离,适用于金融和医疗行业需求。
## 涉及的相关产品
- **Azure Virtual WAN**:作为核心产品,提供全球网络中心和路由意图功能,用于迁移过程中的 Hub 互连。
- **ExpressRoute**:连接 Hub-and-Spoke 与 Virtual WAN,实现高带宽低延迟传输,但需配置 hairpinning 以支持流量交换。
- **VPN Gateway 或 SD-WAN NVA**:在场景 2 中构建虚拟隧道,确保 IPSec 连接;SD-WAN NVA 提供动态路由优化。
- **Azure Firewall**:在多个场景中用作流量控制和安全网关,确保从 Spoke 到 vHub 的路径安全。
## 技术评估
Azure 方案在先进性上领先于传统 Hub-and-Spoke,通过路由意图和 Secured Virtual Hub 提升自动化和安全性,可行性高,适用于大规模迁移场景。优势包括:全球骨干网集成减少延迟(场景 2 和 3),以及灵活的路由策略,支持混合拓扑共存。适用范围广,但限于短期迁移,不适合长期使用。限制:场景 1 的高延迟和单点故障风险(需冗余 MSEE),场景 2 的行政开销和吞吐量限制,场景 4 的额外成本和复杂性。相比 AWS Transit Gateway,Azure 提供更强的防火墙集成,但可能在自定义 ASN 支持上落后于某些竞品;总体上,方案的可行性取决于客户网络规模和容忍度。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 中心辐射 (Hub-and-Spoke) 与 Azure Virtual WAN 之间的连接选项
**原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/connectivity-options-between-hub-and-spoke-and-azure-virtual-wan/4437383](https://techcommunity.microsoft.com/blog/azurenetworkingblog/connectivity-options-between-hub-and-spoke-and-azure-virtual-wan/4437383)
**发布时间:** 2025-07-29
**厂商:** AZURE
**类型:** TECH-BLOG
---

Azure Networking Blog
# 中心辐射 (Hub-and-Spoke) 与 Azure Virtual WAN 之间的连接选项
2025 年 7 月 29 日
## 目录
* 概述
* 场景 1 – 使用 ExpressRoute 电路进行流量 hairpinning
* 场景 2 – 构建虚拟隧道 (SD-WAN 或 IPSec)
* 场景 3 – vNet Peering 与 vHub 连接共存
* 场景 4 – 用于去中心化 vNet 的中转虚拟网络
* 结论
* 奖励内容
### 概述
本文将讨论将中心辐射 (Hub-and-Spoke) 网络与 Azure Virtual WAN 互连的各种选项,针对迁移场景。文章目标是扩展更多选项,帮助客户将现有中心辐射 (Hub-and-Spoke) 拓扑迁移到 Azure Virtual WAN。
你可以查看全面文章 [迁移到 Azure Virtual WAN](<https://learn.microsoft.com/en-us/azure/virtual-wan/migrate-from-hub-spoke-topology>),以了解迁移过程中的多项考虑。本文重点仅放在连接性上,以促进迁移。因此,需要注意的是,这里列出的互连选项旨在短期使用,确保两种拓扑临时共存,同时在辐 (Spoke) vNet 上迁移工作负载,最终目标是完成迁移后断开两者。
本文主要讨论使用 Secured Virtual Hub 的场景;适用的例外情况会注明。假设使用路由意图和路由策略,取代之前使用路由表来保护 Virtual Hub 的方法。有关更多信息,请参考:[如何配置 Azure Virtual WAN Hub 的路由意图和路由策略](<https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies>)。
### 场景 1 – 使用 ExpressRoute 电路进行流量 hairpinning
在开始迁移前,确保目标 Virtual WAN Hub (vHub) 包含所有必要组件。对于已配置防火墙、SD-WAN、VPN (点到站点或站点到站点) 的现有 vHub,确认这些元素也在目标 Virtual WAN 上存在并正确配置。此外,对于任何已迁移的 Spoke,如果存在依赖(如共享服务,包括 DNS、Active Directory 和其他服务),可以保持与原始 Hub vNet 的 vNet peering。但必须确保 peering 配置中禁用“使用远程网关”选项,因为一旦连接到 vHub,vNet 连接需要启用“使用远程网关”。
在此场景中,中心辐射 (Hub-and-Spoke) 与 Virtual WAN Hub 之间的流量通过连接到两个环境的 ExpressRoute 电路实现。当单个电路连接到两个环境时,路由将在两者之间交换,并在 MSEE (Microsoft Enterprise Edge) 路由器处进行 hairpinning。
此场景类似于文章中描述的方法:[迁移到 Azure Virtual WAN](<https://learn.microsoft.com/en-us/azure/virtual-wan/migrate-from-hub-spoke-topology>)。

连接流:
来源 | 目的地 | 数据路径
---|---|---
Spoke vNet | 已迁移 Spokes vNets | 1\. vNet Hub 防火墙 2\. vNet ExpressRoute 网关 3\. MSEE via Hairpin 4\. vHub ExpressRoute 网关 5\. vHub 防火墙
Spoke vNet | 分支 (VPN/SD-WAN) | 1\. vNet Hub 防火墙 2\. vNet SD-WAN NVA 或 VPN 网关
Spoke vNet | 本地数据中心 | 1\. vNet Hub 防火墙 2\. ExpressRoute 网关 3\. ExpressRoute 电路 (MSEE) 4\. 提供商/客户
已迁移 vNet | 分支 (VPN/SD-WAN) | 1\. vHub 防火墙 2\. vHub SD-WAN NVA 或 VPN 网关
已迁移 vNet | 本地数据中心 | 1\. vNet Hub 防火墙 2\. vNet ExpressRoute 网关 3\. ExpressRoute 电路 (MSEE) 4\. 提供商/客户
注意: 连接还考虑返回流量
#### 优点
* 流量保持在 Microsoft 主干网中,不会通过提供商或客户 CPE。
* Azure 平台提供的内置路由 (这可配置,请查看考虑事项)。
#### 缺点
* 预期高延迟。vNET Hub 与 vHub 之间的流量会穿过 Azure 区域外的 MSEE 路由器,在云交换设施中,增加延迟,因为距离区域较远。
* 单点故障。由于 MSEE 位于边缘位置,该位置出现故障可能影响通信。为确保冗余,可以在同一都市区域的不同边缘位置使用第二个 MSEE,以实现冗余并降低延迟。此外,在不同都市区域的第二个 MSEE 也可提供冗余,但可能导致延迟增加。
#### 考虑事项
* 新功能已引入以阻止 MSEE hairpin。为启用此场景,需要在 vNET Hub 侧激活 _Allow Traffic from remote Virtual WAN Networks_,并在 Virtual WAN Hub 侧激活 _Allow Traffic from non-Virtual WAN Networks_。有关更多细节,请参考此文章:[ExpressRoute 上虚拟网络之间连接性的自定义控件](<https://techcommunity.microsoft.com/t5/azure-networking-blog/customisation-controls-for-connectivity-between-virtual-networks/ba-p/4147722>)。
### 场景 2 – 构建虚拟隧道 (SD-WAN 或 IPSec)
针对此选项,目标 vHub 的先决条件与之前相同,在开始迁移前应用。然而,与使用 ExpressRoute 中转不同,在此场景中,你在现有 vNET Hub 与 vHub 之间建立直接虚拟隧道以实现通信。有几种实现方式,包括:
1. 在 vNET Hub 和 vHub 上使用 Azure 原生 VPN 网关建立 IPSec 隧道。当 vNET Hub VPN 网关配置为 Active/Active 时,最多可创建四个隧道 (默认情况下,vHub VPN 网关已是 Active/Active)。实施时,客户可以使用 BGP 或静态路由。但如果 vNET VPN 网关是唯一网关,则可以使用自定义 ASN 而非 65515。如果存在其他网关,如 ExpressRoute 或 Azure Route Server,则 ASN 必须设置为 65515。由于 vHub VPN 网关当前不允许自定义 ASN (默认 ASN 为 65515),因此此设置需要静态路由。
2. 使用第三方 NVA 建立两侧之间的 SD-WAN 连接或 IPSec 隧道。
使用此选项,可以采用静态或 BGP 路由,其中 BGP 将提供更好的 vHub 集成和更少的行政工作。

连接流:
来源 | 目的地 | 数据路径
---|---|---
Spoke vNet | 已迁移 Spokes vNets | 1\. vNet Hub 防火墙 2\. vNet Hub SD-WAN NVA 或 VPN 网关 3\. vHub Hub SD-WAN NVA 或 VPN 网关 4\. vHub 防火墙
Spoke vNet | 分支 (VPN/SD-WAN) | 1\. vNet Hub 防火墙 2\. vNet Hub SD-WAN NVA 或 VPN 网关
Spoke vNet | 本地数据中心 | 1\. vNet Hub 防火墙 2\. ExpressRoute 网关 3\. MSEE Hairpin 4\. 提供商/客户
已迁移 vNet | 分支 (VPN/SD-WAN) | 1\. vHub 防火墙 2\. SD-WAN NVA 或 VPN 网关
已迁移 vNet | 本地数据中心 | 1\. vNet Hub 防火墙 2\. ExpressRoute 网关 3\. MSEE Hairpin 4\. 提供商/客户
注意: 连接还考虑返回流量
#### 优点
* 流量保持在区域内的 Microsoft 主干网中,从而比选项 1 具有更低延迟。
#### 缺点
* 使用静态路由时会增加行政开销,并管理额外网络组件。
* 添加新 VPN 网关或第三方 NVA 以构建虚拟隧道的成本。
* 根据所用虚拟隧道技术的类型,吞吐量可能受限。通过添加多个隧道 (需要 BGP + ECMP 来平衡流量) 可以缓解此限制。请注意,Azure 允许最多八个隧道,这是针对相同网络的不同下一跳的最大编程路由数。
### 场景 3 – vNet Peering 与 vHub 连接共存
在此场景中,原本连接到 vNet Hub 的 Spoke vNet 被迁移到 vHub,同时保持与 vNet Hub 的现有 peering,但禁用“使用远程网关”配置。这允许已迁移 vNets 保留与源 vNet Hub 的连接,同时连接到 vHub。连接到 vHub 需要“使用远程网关”,这会将所有指向本地环境的流量导向 vHub。
要通过 vHub 与其他 Spoke 连接,已迁移 vNet 需要一个 UDR,其中包含指向 vNet Spoke 前缀的路由,使用 vNet Hub 防火墙作为下一跳。对于连续前缀,使用路由汇总;如果不是,则输入特定前缀。此外,在 UDR 中启用网关传播,以便已迁移 Spoke vNets 可以从 vHub 学习路由 (RFC 1918、默认路由或两者)。

连接流:
来源 | 目的地 | 数据路径
---|---|---
Spoke vNet | 已迁移 Spokes vNet | 1\. vNet Hub 防火墙
Spoke vNet | 分支 (VPN/SD-WAN) | 1\. vNet Hub 防火墙 2\. vNet SD-WAN NVA 或 VPN 网关
Spoke vNet | 本地数据中心 | 1\. vNet Hub 防火墙 2\. ExpressRoute 网关 3\. ExpressRoute 电路 (MSEE) 4\. 提供商/客户
已迁移 vNet | 分支 (VPN/SD-WAN) | 1\. vHub 防火墙 2\. vHub SD-WAN NVA 或 VPN 网关
已迁移 vNet | 本地数据中心 | 1\. vHub 防火墙 2\. vHub ExpressRoute 网关 3\. ExpressRoute 电路 (MSEE) 4\. 提供商/客户
注意: 连接意味着返回流量
#### 优点
* 流量保持在区域内的 Microsoft 主干网中,从而比选项 1 具有更低延迟。
* 与选项 2 相比,没有虚拟隧道强加的吞吐量限制。
吞吐量将受 VM 大小限制。
#### 缺点
* 需要调整 UDR 以通过 vNet Hub 到达 Spoke vNets,从而增加行政开销。
### 场景 4 – 用于去中心化 vNet 的中转虚拟网络
此用例涉及去中心化虚拟网络模型,其中每个客户都有 ExpressRoute 网关,用于连接本地系统。虚拟网络之间的流量使用虚拟网络 peering 管理,根据客户的具体连接需求。每个虚拟网络都有自己的网关,这会阻止它们直接连接到虚拟 Hub,因为需要启用远程网关选项。
如果客户能容忍从已迁移 vNet 中删除 ExpressRoute 网关带来的停机时间,他们可以选择直接将 vNet 连接到 vHub,从而简化解决方案。此过程通常需要约 45 分钟,不包括回滚程序 (还需要额外 45 分钟),这可能使大多数客户无法接受。
然而,具有现有 Azure 工作负载的客户通常希望最小化停机时间。如下图所示,他们可以创建一个配备防火墙或具有路由能力的 Network Virtual Appliance (NVA) 的中转 vNet。这允许已迁移 vNet 建立常规 peering,从而在不造成重大中断的情况下保持连接。
本文部分中说明的解决方案在 vNet 连接级别向中转 vNet 使用静态路由传播,现在需要非 Secured-Virtual WAN hubs (请注意,静态路由传播支持已在 Virtual WAN 路线图中)。
或者,你可以使用防火墙或 NVA 的 BGP peering 来编程已迁移 vNets 的摘要前缀。对于使用 BGP 的防火墙实现,建议利用 [Virtual WAN 的下一跳 IP 支持](<https://learn.microsoft.com/en-us/azure/virtual-wan/next-hop-ip>),其中流量通过负载均衡功能确保流量对称。在该场景中,你也可以利用 Secured-vHubs。
迁移过程还需要调整已迁移 vNET 的路由,以便流量通过 vHUB 流向本地系统。这包括在从中转 vNet 到 vHub 的连接中使用静态路由来广告摘要路由,通过中转 vNET 中的防火墙确保返回流量并正确广告到本地环境。一旦路由配置完成,就可以删除 ExpressRoute 连接。然后,客户可以继续步骤 2,以进行最终调整并完成与 vHub 的完全集成
1. 删除 ExpressRoute 网关。
2. 创建 vNet 到 vHub 的连接,这将允许特定已迁移 vNet 前缀广告到 vHub,并向下泄漏到 ExpressRoute。一旦完成步骤 2,流量应开始通过 vNET 连接流向 vHub。
3. 删除到中转 vNET 的 vNet peering。

连接流:
来源 | 目的地 | 数据路径
---|---|---
vNet1/VNet2 | 已迁移 Spokes vNet | 1\. 直接 vNet peering
vNet1/VNet2 | 分支 (VPN/SD-WAN) | 1\. ExpressRoute 网关 2\. ExpressRoute 电路 (MSEE) 3\. 提供商/客户 4\. VPN/SD-WAN
vNet1/VNet2 | 本地数据中心 | 1\. ExpressRoute 网关 2\. ExpressRoute 电路 (MSEE) 3\. 提供商/客户
已迁移 vNet (步骤 1) | 分支 (VPN/SD-WAN) | 1\. 中转防火墙 2\. vHub SD-WAN NVA 或 VPN 网关
已迁移 vNet (步骤 1) | 本地数据中心 | 1\. 中转防火墙 2\. vHub ExpressRoute 网关 3\. ExpressRoute 电路 (MSEE) 4\. 提供商/客户
已迁移 vNet (步骤 2) | 分支 (VPN/SD-WAN) | 1\. vHub SD-WAN NVA 或 VPN 网关
已迁移 vNet (步骤 2) | 本地数据中心 | 1\. vHub ExpressRoute 网关 2\. ExpressRoute 电路 (MSEE) 3\. 提供商/客户
注意: 连接意味着返回流量
#### 优点
* 流量保持在 Microsoft 主干网中,确保最小延迟。
* 与选项 2 解决方案 (虚拟隧道) 不同,没有相同的吞吐量限制。
#### 缺点
* 维护额外中转虚拟网络的行政开销,包括用户定义路由管理和 vHub vNet 连接静态路由配置。
* 运行中转 vNet 中的任何额外防火墙 (FWs) 或网络虚拟设备 (NVAs) 带来的成本。
### 结论
本文概述了从中心辐射 (Hub-and-Spoke) 网络迁移到 Azure Virtual WAN 的四种策略——ExpressRoute hairpinning、VPN 或 SD-WAN 虚拟隧道、vNet peering 与 vHub 连接,以及用于去中心化 vNets 的中转虚拟网络——突出了它们的优点、缺点和行政考虑。评估哪种方法最适合你的需求时,请权衡每个场景的优缺点。
### 奖励内容
本文相关的图表以 Excalidraw 格式提供,在
更新于 2025 年 7 月 29 日
版本 2.0
<!-- AI_TASK_END: AI全文翻译 -->