本文介绍用于在 Azure 中部署一组网络虚拟设备（NVA）以实现高可用性的最常见选项。 NVA 通常用于控制按不同安全级别分类的网络段之间的流量流，例如，在 De-Militarized 区域（DMZ）虚拟网络和公共 Internet 之间，或将外部位置连接到 Azure，例如 VPN 或 SDWAN（Software-Defined WAN）设备。
有许多设计模式，其中 NVA 用于检查不同安全区域之间的流量，例如：
- 检查从虚拟机流出到 Internet 的出口流量并防止数据外泄。
- 检查从 Internet 到虚拟机的入口流量并防止攻击。
- 若要筛选 Azure 中虚拟机之间的流量，以防止横向移动受损的系统。
- 若要筛选本地系统和 Azure 虚拟机之间的流量，如果它们被视为属于不同的安全级别。 （例如，如果 Azure 托管外围网络和本地内部应用程序。
- 从外部位置（如本地网络或其他公有云）终止 VPN 或 SDWAN 隧道。
NVA 有许多示例，包括以下内容等：
- 网络防火墙
- 第 4 层反向代理
- IPsec VPN 终结点
- SDWAN 设备
- 具有 Web 应用程序防火墙功能的基于 Web 的反向代理
- Internet 代理以限制可从 Azure 访问哪些 Internet 页面
- 第 7 层负载均衡器
所有这些 NVA 都可以在 Azure 设计中插入本文中所述的模式。 即使是 Azure 第一方网络虚拟设备（例如 Azure 防火墙 和 Azure 应用程序网关）， 使用本文后面介绍的设计。 从设计角度和排查网络问题时，了解这些选项至关重要。
要回答的第一个问题是为什么需要网络虚拟设备的高可用性。 原因是这些设备控制网段之间的通信。 如果它们不可用，则网络流量无法流动，应用程序停止工作。 计划和计划外中断偶尔会降低 NVA 实例（与 Azure 或任何其他云中的其他任何虚拟机一样）。 即使这些 NVA 配置了高级托管磁盘，以在 Azure 中提供单实例 SLA，这些实例也会关闭。 因此，高度可用的应用程序至少需要第二个 NVA，以确保连接。
先决条件： 本文假定你基本了解 Azure 网络、Azure 负载均衡器，以及 虚拟网络流量路由（UDR）。
选择将网络虚拟设备部署到 Azure VNet 的最佳选项时，需要考虑的最重要方面是 NVA 供应商是否审查并验证了该特定设计。 供应商还必须提供在 Azure 中集成 NVA 所需的所需的 NVA 配置。 如果 NVA 供应商为 NVA 提供不同的替代项作为支持的 NVA 设计选项，则这些因素可能会影响决策：
- 收敛时间：每个设计需要多长时间才能将流量从失败的 NVA 实例中移开？
- 拓扑支持：每个设计选项支持哪些 NVA 配置？ 具有 n+1 冗余的主动/主动/备用、横向扩展 NVA 群集？
- 流量对称性：特定设计是否强制 NVA 对数据包执行源网络地址转换（SNAT），以避免非对称路由？ 还是以其他方式强制实施流量对称？
本文档中的以下部分介绍了用于将 NVA 集成到中心辐射网络的最常见体系结构。
注释
本文重点介绍 中心 & 辐射设计。 虚拟 WAN 未涵盖，因为虚拟 WAN 在部署 NVA 的方式上更具规范性，具体取决于虚拟 WAN 中心是否支持特定的 NVA。 有关详细信息，请参阅虚拟 WAN 中心 网络虚拟设备。
HA 体系结构概述
以下体系结构描述了高度可用 NVA 所需的资源和配置：
| 解决方案 | 优点 | 注意事项 |
|---|---|---|
| Azure 负载均衡器 | 支持主动/主动、主动/备用以及具有良好收敛时间的横向扩展 NVA | NVA 需要为运行状况探测提供端口，尤其是用于主动/备用部署。 对于需要流量对称的有状态设备（例如防火墙），流向/流出 Internet 需要 SNAT |
| Azure 路由服务器 | NVA 需要支持 BGP。 支持主动/主动、主动/备用和横向扩展 NVA。 | 流量对称性还需要 SNAT |
| 网关负载均衡器 | 保证没有 SNAT 的流量对称性。 NVA 可以跨租户共享。 良好的收敛时间。 支持主动/主动、主动/备用和横向扩展 NVA。 | 支持流向/传出 Internet，无 East-West 流 |
| 更改 PIP/UDR | NVA 不需要特殊功能。 保证对称流量 | 仅适用于主动/被动设计。 1-2 分钟的高收敛时间 |
负载均衡器设计
此设计使用两个 Azure 负载均衡器向网络其余部分公开 NVA 群集。 此方法经常用于有状态和无状态 NVA：
- 内部负载均衡器用于将内部流量从 Azure 和本地重定向到 NVA。 此内部负载均衡器配置了 HA 端口规则，以便每个 TCP/UDP 端口都重定向到 NVA 实例。
- 公共负载均衡器向 Internet 公开 NVA。 由于 HA 端口 适用于入站流量，因此需要在专用负载均衡规则中打开每个单独的 TCP/UDP 端口。
下图描述了从 Internet 到辐射 VNet 中的应用程序服务器的数据包在遍历防火墙 NVA 以控制来自公共 Internet 的流量（也称为南北流量）的跃点序列：
使用 Azure 负载均衡器集成ALB InternetInternet 流量
下载该架构的 Visio 文件。
通过 NVA 将辐射中的流量发送到公共 Internet 的机制是一种 User-Defined 路由，用于 0.0.0.0/0，其中包含内部负载均衡器 IP 地址的下一跃点。
对于 Azure 与公共 Internet 之间的流量，流量流的每个方向都会跨越不同的 Azure 负载均衡器。 即使防火墙 NVA 对公共网络和内部网络都有单个 NIC，也会发生这种情况，因为入口数据包通过公共 ALB，出口数据包通过内部 ALB。 由于流通过不同负载均衡器的两个方向，因此如果需要流量对称，与大多数防火墙一样，源网络地址转换（SNAT）需要由 NVA 实例执行，以吸引返回流量并避免流量不对称。
可以使用与负载均衡器相同的设计来检查 Azure 与本地网络（东部/西部）之间的流量，其中只涉及内部负载均衡器：
通过 NVA 在辐射之间发送流量的机制完全相同，因此没有提供其他关系图。 在上面的示例关系图中，由于 spoke1 不知道 spoke2 的范围，0.0.0.0/0 UDR 会将地址为辐射 2 的流量发送到 NVA 的内部 Azure 负载均衡器。
对于本地网络与 Azure 之间或 Azure 虚拟机之间的流量，内部 Azure 负载均衡器在单 NIC NVA 中保证流量对称：当流量流的两个方向遍历同一 Azure 负载均衡器时，负载均衡器将选择相同的 NVA 实例。 对于每个通信意义上都有内部负载均衡器的双 NIC NVA，则必须通过 SNAT 提供流量对称性，如上面的南北示例所示。
在此设计中，双 NIC NVA 面临的另一个挑战是向负载均衡器的运行状况检查发送回复。 Azure 负载均衡器始终使用与源相同的 IP 地址进行运行状况检查（168.63.129.16）。 NVA 需要能够将答案发送到从接收的同一接口上的此 IP 地址的运行状况检查。 这通常需要作系统中的多个路由表，因为基于目标的路由会始终通过同一 NIC 将回复发送到运行状况检查。
Azure 负载均衡器在单个 NVA 中断中具有很好的收敛时间。 由于 运行状况探测 可以每隔 5 秒发送一次，并且需要 3 个失败的探测才能将后端实例声明出服务，因此 Azure 负载均衡器通常需要 10-15 秒才能将流量聚合到其他 NVA 实例。
此设置支持主动/主动和主动/备用配置。 对于活动/备用配置，NVA 实例需要提供 TCP/UDP 端口或 HTTP 终结点，该终结点仅响应活动角色中的实例的负载均衡器运行状况探测。
使用 L7 负载均衡器
安全设备的此设计的特殊情况是将 Azure 公共负载均衡器替换为第 7 层负载均衡器，例如 Azure 应用程序网关（可以将其视为自己的 NVA）。 在这种情况下，NVA 只需要内部负载均衡器来接收来自工作负荷系统的流量。 双 NIC 设备有时会使用此机制，以避免 Azure 负载均衡器的运行状况检查出现路由问题，如前一部分所述。 此设计的一个限制是，它仅支持第 7 层负载均衡器支持的第 7 层协议，通常是 HTTP（S）。
NVA 应采用第 7 层负载均衡器不支持的协议的入站流量，并可能采用所有出口流量。 有关将 Azure 防火墙用作 NVA 的进一步详细信息，将 Azure 应用程序网关用作第 7 层 Web 反向代理时，请参阅 虚拟网络的防火墙和应用程序网关。
Azure 路由服务器
Azure 路由服务器 是一项服务，允许 NVA 通过边界网关协议（BGP）与 Azure SDN 交互。 NVA 不仅了解 Azure VNet 中存在哪些 IP 前缀，而且还能够在 Azure 中虚拟机的有效路由表中注入路由。
使用 Azure 路由服务器集成ARS InternetInternet 流量
在上图中，每个 NVA 实例通过 BGP 与 Azure 路由服务器对等互连。 辐射子网中不需要路由表，因为 Azure 路由服务器会计划 NVA 播发的路由。 如果在 Azure 虚拟机中对两个或多个路由进行编程，则它们使用相等成本多路径（ECMP）为每个流量流选择一个 NVA 实例。 因此，如果流量对称性是必需的，SNAT 是此设计中的一项。
此插入方法同时支持主动/主动（所有 NVA 将相同的路由播发到 Azure 路由服务器），以及活动/备用（一个 NVA 播发的路由的 AS 路径比另一个路由短）。 Azure 路由服务器最多支持 8 个 BGP 相邻。 因此，如果使用活动 NVA 的横向扩展群集，此设计最多支持 8 个 NVA 实例。
收敛时间在此设置中非常快，并且受 BGP 相邻的 keepalive 和 holdtime 计时器的影响。 虽然 Azure 路由服务器具有默认保留和保持时间计时器（分别为 60 秒和 180 秒），但 NVA 可以在 BGP 相邻建立期间协商较低的计时器。 设置这些计时器太低可能会导致 BGP 不稳定。
此设计是需要与 Azure 路由交互的 NVA 的最常见选项，例如 SDWAN 或 IPsec NVA，这些 NVA 通常具有良好的 BGP 支持，并且需要了解在 Azure VNet 中配置的前缀，或者通过 ExpressRoute 专用对等互连播发某些路由。 这种类型的设备通常是无状态的，因此流量对称性不是问题，因此不需要 SNAT。
网关负载均衡器
Azure 网关负载均衡器 是将数据路径中插入 NVA 的新方式，无需使用 User-Defined 路由来引导流量。 对于通过 Azure 负载均衡器或公共 IP 地址公开其工作负荷的虚拟机，入站和出站流量可以透明地重定向到位于不同 VNet 中的 NVA 群集。 下图描述了当工作负荷通过 Azure 负载均衡器公开应用程序时，数据包针对来自公共 Internet 的入站流量所遵循的路径：
使用网关负载均衡器集成GWLB InternetInternet 流量
此 NVA 注入方法的主要优点之一是源网络地址转换（SNAT）不需要保证流量对称性。 此设计选项的另一个好处是，同一 NVA 可用于检查进出不同 VNet 的流量，从而从 NVA 的角度来看实现多租户。 NVA VNet 和工作负荷 VNet 之间不需要 VNet 对等互连，工作负荷 VNet 中不需要 User-Defined 路由，这极大地简化了配置。
网关负载均衡器的服务注入可用于传入 Azure 公共负载均衡器的入站流（及其返回流量），以及源自 Azure 的出站流。 East-West Azure 虚拟机之间的流量无法利用网关负载均衡器进行 NVA 注入。
在 NVA 群集中，Azure 负载均衡器运行状况检查探测用于检测单个 NVA 实例故障，实现快速收敛时间（10-15 秒）。
更改 PIP-UDR
此设计背后的想法是具有无需 NVA 冗余的设置，并在 NVA 遭受停机时对其进行修改。 下图显示了 Azure 公共 IP 地址如何关联到活动 NVA （NVA1），辐射中的 User-Defined 路由将活动 NVA 的 IP 地址作为下一跃点（10.0.0.37）。
使用移动 PIP/UDRPIP/UDR InternetInternet 流量
如果活动 NVA 不可用，备用 NVA 将调用 Azure API 以重新映射公共 IP 地址，辐射 User-Defined 路由本身（或移动专用 IP 地址）。 这些 API 调用可能需要几分钟才能生效，这就是为什么此设计提供了本文档中所有选项最差的收敛时间。
此设计的另一个限制是仅支持活动/备用配置，这可能会导致可伸缩性问题：如果需要增加 NVA 支持的带宽，此设计的唯一选项是纵向扩展这两个实例。
此设计的一个好处是，无需源网络地址转换（SNAT）才能保证流量对称，因为在任何给定时间点只有一个 NVA 处于活动状态。
供稿人
本文由Microsoft维护。 它最初是由以下贡献者撰写的。
主要作者：
- 基思·迈尔 |首席云解决方案架构师
- Telmo Sampaio | 首席服务工程经理
- 何塞·雷诺 |首席工程师
要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
- 了解如何使用 Azure 防火墙 实现安全的混合网络。
- 外围网络 - 云采用框架
- 云外围网络 - 云采用框架