[解决方案] 中心辐射式和 vWAN 架构中的检查模式

**发布时间:** 2025-07-08 **厂商:** AZURE **类型:** TECH-BLOG **原始链接:** https://techcommunity.microsoft.com/blog/azurenetworkingblog/inspection-patterns-in-hub-and-spoke-and-vwan-architectures/4430491 --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] 中心辐射式和 vWAN 架构中的检查模式 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 本文档详细描述了Azure的Hub-and-Spoke和vWAN架构中的检查模式，这些模式旨在处理网络流量检查，以满足安全、合规和性能需求。核心内容包括在多Hub或Virtual Hub（VHub）环境中，实现对东西向（east-west）和南北向（north-south）流量的检查。**关键术语**如**VNet Peering**、**User-Defined Routes (UDRs)** 和 **Routing Intent** 被用于优化流量路径，避免不必要的检查。 该解决方案解决的问题包括：网络安全风险、合规要求（如流量检查）和性能瓶颈（如延迟敏感应用）。适用场景涵盖企业级网络架构，尤其在多区域部署中，需要连接本地环境（via ExpressRoute）和Azure资源。行业需求主要针对云原生应用、金融和医疗等领域。技术原理基于Azure的虚拟网络路由机制，利用**UDRs**和**Routing Intent**强制流量通过防火墙进行检查，同时支持冗余设计以提升可靠性。 ## 实施步骤 1. **规划架构基础** - 部署两个Hub VNets或VHubs，并确保它们与本地环境通过ExpressRoute连接。理由：提供冗余和优化路径，避免单点故障。技术原理：利用VNet Peering建立Hub间连接，确保流量优先使用内部路由而非ExpressRoute。 2. **配置检查选项** - 对于Hub-and-Spoke，选择具体选项（如Full Inspection）。应用UDRs在Spoke VNets和Gateway Subnet上，设置下一跳为防火墙。逻辑衔接：这确保所有流量（如Spoke ↔ Spoke）经检查后转发。 - 对于vWAN，启用Routing Intent而不需UDRs。理由：简化路由管理，直接在VHub中处理流量检查。 3. **集成管理和优化** - 使用Azure Virtual Network Manager (AVNM)创建Connectivity Configurations（如Mesh topology）。理由：在规模化环境中，集中管理UDRs和Peering以减少复杂性。技术原理：AVNM的Mesh配置优先于自定义路由，实现选择性检查。 - 测试并验证流量路径，使用连接性表监控Inspected状态。逻辑衔接：通过此步骤，确保实施符合安全要求并优化性能。 ## 方案客户价值 - **简化网络管理**：通过AVNM实现集中式UDRs管理和Peering，相比传统手动配置，显著减少操作复杂性，帮助客户在多Hub环境中高效扩展。 - **提升安全与合规**：全流量检查选项确保东西向和南北向流量均受检（如On-premises ↔ Azure），满足行业合规需求，相比传统方案减少安全漏洞风险。 - **优化性能和成本**：选择性检查（如Spoke ↔ Spoke在信任区 bypass）降低延迟和检查开销，实现类似“成本降低通过路由优化”的间接收益；与传统方案相比，避免双重检查，改善数据传输效率。 ## 涉及的相关产品 - **Azure Virtual Network Manager (AVNM)**：用于集中管理VNet Peering和UDRs，在解决方案中简化大规模网络配置。 - **Azure Firewall**：作为流量检查的核心组件，处理南北向和东西向流量，确保安全合规。 - **ExpressRoute**：连接Azure与本地环境，提供高带宽低延迟路径，支持冗余设计。 - **Routing Intent (vWAN)**：在vWAN架构中，用于自动路由流量至防火墙，无需额外UDRs配置。 ## 技术评估 - **先进性**：解决方案利用AVNM和Routing Intent等Azure独有功能，实现自动化路由管理，领先于传统Hub-and-Spoke的手动配置，适用于动态云环境。 - **可行性**：设计高度可扩展，但依赖Azure生态；在多区域部署中易于实施，通过ExpressRoute确保高可用性。 - **适用范围**：适合大规模企业网络，但可能受限于第三方NVA在VHub中的兼容性（如不支持多种NVA部署）。优势包括优化流量路径和简化管理；限制在于vWAN不支持绕过On-premises检查，需结合客户环境评估。 - **优势和局限性**：优势在于冗余设计和灵活检查选项，提升安全性；局限性包括潜在的配置复杂性（如UDRs管理）和依赖Azure特定功能，可能增加学习曲线。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # Hub-and-Spoke 和 vWAN 架构中的检查模式 **原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/inspection-patterns-in-hub-and-spoke-and-vwan-architectures/4430491](https://techcommunity.microsoft.com/blog/azurenetworkingblog/inspection-patterns-in-hub-and-spoke-and-vwan-architectures/4430491) **发布时间:** 2025-07-08 **厂商:** AZURE **类型:** TECH-BLOG --- Azure Networking Blog # Hub-and-Spoke 和 vWAN 架构中的检查模式 2025 年 7 月 08 日 By [shruthi_nair​](<javascript:void\(0\)>) [Mays_Algebary​](<javascript:void\(0\)>) 检查在网络架构中扮演着至关重要的角色，每个客户可能有独特的检查需求。本文探讨了 Hub-and-Spoke 架构和虚拟广域网 (vWAN) 拓扑中的常见检查场景。 我们将介绍设计方法，假设设置有两个 Hub 或虚拟 Hub (VHub) 通过 ExpressRoute 连接到本地环境。Hub 或 VHub 的具体区域并不关键，因为相同的设计原则可以跨区域应用。 ##### **场景 1: Hub-and-Spoke 检查模式** 在 Hub-and-Spoke 场景中，基础架构假设有两个 Hub 虚拟网络 (VNet)。每个 Hub VNet 与其本地 Spoke VNet 以及另一个 Hub VNet (Hub2-VNet) 进行对等互连。此外，两个 Hub VNet 都连接到本地和远程 ExpressRoute 电路，以确保冗余。 **注意：** - _在 Hub-and-Spoke 场景中，Hub 之间通过 ExpressRoute 电路的虚拟网络连接被有意禁用。这确保了 Hub 间流量使用 VNet 对等互连，提供更优化的路径，而不是穿越 ExpressRoute 电路。_ - _在场景 1 中，我们呈现两种实现方法：传统方法和使用 [Azure Virtual Network Manager](<https://learn.microsoft.com/en-us/azure/virtual-network-manager/overview>) (AVNM) 的替代方案。_ **选项 1: 完全检查** 一种广泛采用的设计模式是检查所有流量，包括东西向和南北向流量，以满足安全和合规要求。这可以使用传统的 Hub-and-Spoke 拓扑结合 VNet 对等互连和用户定义路由 (UDRs)，或通过 AVNM 结合连接性配置和集中 UDR 管理来实现。 在传统方法中： - VNet 对等互连用于连接每个 Spoke 到其本地 Hub，以及在两个 Hub 之间建立连接。 - UDRs 将流量定向到防火墙作为下一跳，确保在到达目的地前进行检查。 - 这些 UDRs 应用于 Spoke VNet、Gateway 子网和 Firewall 子网（特别是在跨区域场景），如下图所示。 **Hub and Spoke: 完全检查** 随着环境规模增长，手动管理单个 UDRs 和 VNet 对等互连可能会变得复杂。为了简化部署和持续管理，您可以使用 AVNM。 使用 AVNM： - 使用 Hub-and-Spoke 连接性配置来管理单个 Hub 中的路由。 - 使用 Mesh 连接性配置在两个 Hub 之间建立互连。 - AVNM 还启用集中创建、分配和管理 UDRs，从而简化大规模网络配置。 **Hub and Spoke (AVNM): 完全检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ✅ Spoke ↔ Spoke | ✅ Spoke ↔ Internet | ✅ **选项 2: Azure VNet 之间选择性检查** 在某些场景中，不需要或不希望进行完全流量检查。这可能是由于基于信任区域的网络分段，例如，受信任 VNet 之间的流量可能不需要检查。其他原因包括高容量数据复制、延迟敏感应用或减少检查开销和成本。 在此设计中，VNet 被分组到受信任和不受信任区域。受信任 VNet 可以存在于同一 Hub 或不同 Hub 中。要绕过受信任 VNet 之间的检查，您可以使用 VNet 对等互连或 AVNM Mesh 连接性拓扑直接连接它们。 需要注意的是，UDRs 仍按完全检查模型 (选项 1) 所述使用和配置。但是，当受信任 VNet 直接连接时，系统路由 (由 VNet 对等互连或 Mesh 连接性创建) 会优先于自定义 UDRs。因此，受信任 VNet 之间的流量绕过防火墙并直接流动。相比之下，到或从不受信任区域的流量 **Hub and Spoke: Azure VNet 之间选择性检查** **Hub and Spoke (AVNM): Azure VNet 之间选择性检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ✅ Spoke ↔ Internet | ✅ Spoke ↔ Spoke (相同区域) | ❌ Spoke ↔ Spoke (跨区域) | ✅ **选项 3: 无本地环境检查** 在某些情况下，如果本地或共址站点已有防火墙检查来自 Azure 的流量，客户通常希望避免双重检查。为了在上述设计中支持这一点， destined 到本地环境的流量不会路由通过 Azure 中的防火墙。对于应用于 Spoke VNet 的 UDRs，确保“Propagate Gateway Routes”设置为 true，从而允许流量到 **Hub and Spoke: 无本地环境检查** **Hub and Spoke (AVNM): 无本地环境检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ❌ Spoke ↔ Spoke | ✅ Spoke ↔ Internet | ✅ **选项 4: 仅 Internet 检查** 虽然不推荐，但有些客户选择仅检查 Internet 定向流量，并允许私有流量不经检查。在此情况下，Spoke VNet 可以使用 VNet 对等互连或 AVNM Mesh 连接性直接连接。要确保本地环境流量避免检查，在应用于 Spoke VNet 的 UDRs 中将“Propagate Gateway Routes”设置为 true。这允许流量到 **Hub and Spoke: 仅 Internet 检查** **Hub and Spoke (AVNM): 仅 Internet 检查** ##### **场景 2: vWAN 检查选项** 现在我们探讨使用 vWAN 拓扑的检查选项。 在所有场景中，基础架构假设有两个虚拟 Hub (VHub)，每个 VHub 连接到其各自的本地 Spoke VNet。vWAN 提供两个 VHub 之间的默认连接性，每个 VHub 还连接到本地和远程 ExpressRoute 电路以实现冗余。 需要注意的是，此讨论聚焦于使用路由意图 (Routing Intent) 的 vWAN 中的检查。因此，在此模型中，不支持绕过到本地环境的流量检查。 **选项 1: 完全检查** 如前所述，检查所有流量，包括东西向和南北向流量，是为了满足合规和安全需求的一种常见做法。在此设计中，启用 [路由意图](<https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies>) 可以检查私有流量和 Internet 定向流量。与 Hub-and-Spoke 拓扑不同，此方法不需要任何 UDR 配置。 **vWAN: 完全检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ✅ Spoke ↔ Spoke | ✅ Spoke ↔ Internet | ✅ **选项 2: 使用不同防火墙类型进行流量检查** - **在 VHub 内使用不同防火墙类型进行流量检查** 有些客户需要针对不同流量流使用特定防火墙，例如，使用 Azure Firewall 检查东西向流量，同时依赖第三方防火墙进行南北向检查。在 vWAN 中，可以在同一 VHub 内部署 Azure Firewall 和第三方网络虚拟设备 (NVA)。然而，截至目前，在同一 VHub 中部署两种不同的第三方 NVA 不受支持。此行为可能在未来改变，因此建议监控 [已知限制](<https://learn.microsoft.com/en-us/azure/virtual-wan/how-to-routing-policies#knownlimitations>) 部分以获取更新。通过此设计，您可以使用路由意图轻松控制哪个防火墙处理东西向还是南北向流量，从而无需 UDRs。 **vWAN: 在 VHub 内使用不同防火墙类型进行流量检查** - **当 VHub 限制适用时，在 Spoke VNet 中部署第三方防火墙** 如果您要使用的第三方防火墙在 VHub 中不受支持，或者 VHub 中的托管防火墙缺少某些所需的特性（与可部署在常规 VNet 中的版本相比），您可以在 Spoke VNet 中部署第三方防火墙，同时在 VHub 中使用 Azure Firewall。 在此设计中，部署在 Spoke VNet 中的第三方防火墙处理 Internet 定向流量，而 VHub 中的 Azure Firewall 检查东西向流量。这通过将第三方防火墙 VNet 与 VHub 进行对等互连，以及直接与 Spoke VNet 进行对等互连来实现。这些 Spoke VNet 也连接到 VHub，如下图所示。在 Spoke VNet 中需要 UDRs 来转发 Internet 定向流量到第三方防火墙 VNet。然而，东西向流量路由使用路由意图功能处理，通过 Azure Firewall 而不需 UDRs。 **vWAN: 当 VHub 限制适用时，在 Spoke VNet 中部署第三方防火墙** **注意：** _虽然第三方防火墙 VNet 不需要连接到 VHub 以实现流量流，但这样做有助于管理便利和本地环境可达性。_ **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ✅ Inspected using Azure Firewall Spoke ↔ Spoke | ✅ Inspected using Azure Firewall Spoke ↔ Internet | ✅ Inspected using Third Party Firewall **选项 3: Azure VNet 之间选择性检查** 类似于 Hub-and-Spoke 拓扑，有些场景中完全流量检查并不理想。这可能是由于 Azure VNet 被分段到受信任和不受信任区域，其中受信任 VNet 之间的检查没有必要。其他原因包括特定 VNet 之间的大量数据复制或延迟敏感应用，需要最小化检查延迟和相关成本。 在此设计中，受信任和不受信任 VNet 可以位于同一 VHub 或不同 VHub 中。路由意图保持启用，以检查受信任和不受信任 VNet 之间的流量，以及 Internet 定向流量。要绕过受信任 VNet 之间的检查，您可以使用 VNet 对等互连或 AVNM Mesh 连接性直接连接它们。 与 Hub-and-Spoke 模型不同，此设计不需要 UDR 配置。因为受信任 VNet 直接连接，VNet 对等互连的系统路由优先于通过 VHub 学习的路由。到不受信任区域的流量将继续 **vWAN: Azure VNet 之间选择性检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ✅ Spoke ↔ Internet | ✅ Spoke ↔ Spoke (相同区域) | ❌ Spoke ↔ Spoke (跨区域) | ✅ **选项 4: 仅 Internet 检查** 虽然不推荐，但有些客户选择仅检查 Internet 定向流量并绕过私有流量检查。在此设计中，您仅在路由意图中启用 Internet 检查选项，因此私有流量完全绕过防火墙。VHub 直接管理内部和跨 VHub 路由。 **vWAN: 仅 Internet 检查** **连接性检查表** **连接性场景** | **已检查** ---|--- 本地环境 ↔ Azure | ❌ Spoke ↔ Internet | ✅ Spoke ↔ Spoke | ❌ 更新于 2025 年 7 月 08 日 版本 3.0 <!-- AI_TASK_END: AI全文翻译 -->