云正在改变基础结构的设计方式（包括防火墙的设计方式），因为网络不再是物理网络，也不再处于虚拟 LAN 中。 并非物理网络的所有功能都可在虚拟网络 (VNet) 中使用。 例如，浮动 IP 地址或广播流量就无法使用，这会影响 HA 体系结构的实现。 为了在虚拟网络中实现高可用性 (HA) 体系结构，我们可以/必须以某种方式实现用于网络虚拟设备 (NVA) 的负载均衡器。 本指南介绍了使用第三方虚拟设备在 Azure 中设计 HA 防火墙 (FW) 的结构化方法。
设计高可用 NVA 的选项
在部署 HA 体系结构时，以下几个选项可提供故障转移：
- Azure API 托管的路由表： 此选项使用两个路由表（一个主动，一个被动）切换在 VNet/子网上运行的所有服务的活动网关 IP。
- Azure API 托管的浮动 IP： 此选项对防火墙使用可在主动和备用防火墙之间移动的辅助 IP 地址。
- 负载均衡器托管： 此选项使用 Azure 负载均衡器充当子网的网关 IP，然后将流量转发到主动防火墙。 它甚至可以采用主动-主动模式转发流量，以提供真正的负载均衡。
前两个选项的问题是故障转移本身速度缓慢。 防火墙必须指导故障转移，这实质上是通过新的部署“重新配置” Azure 服务。 流量流会停止几分钟，具体取决于部署完成的速度。 此外，无法实现两个防火墙同时运行的主动-主动配置。
因此，第三个选择最佳。 由于负载均衡器几乎可以立即转移到备用防火墙（主动-被动模式），或者只是从发生故障的防火墙移除负载（主动-主动模式），因此停机时间降到了最低。 但不能只使用负载均衡器作为“默认网关”，因为它们会影响流量流，而 TCP 数据包需要有状态。
双向防火墙
在下图中，两个防火墙（FW-1 和 FW-2）在前，然后是外部负载均衡器和后端服务器 S1。
此体系结构是一个用于入站流量的简单设置。 数据包到达负载均衡器，负载均衡器从其配置中选择目标防火墙。 然后，所选防火墙会将流量发送到后端 (web) 服务器。 如果 FW-1 启用了 SNAT，则服务器 S1 将看到来自 FW-1 内部 IP 的流量，因此也会将它对数据包的回复发送给 FW-1。 在这种情况下，故障转移可以快速地用于 FW-2。 对于出站流量，可以在内部端添加另一个负载均衡器。 当服务器 S1 发起流量时，将应用相同的原则。 流量到达内部 LB (iLB)，后者选择一个防火墙用于执行 NAT 转换以实现外部解析：
三向防火墙
将另一个接口添加到防火墙时出现问题，需要在内部区域之间禁用 NAT 转换。 在这种情况下，请参阅子网 B 和子网 C：
内部区域（子网 B 和子网 C）之间的 L3 路由都将在没有 NAT 的情况下进行负载平衡。 通过查看流量流（包括其他视图中的负载均衡器）可以更清除地了解这一设置。 该图显示内部负载均衡器 [iLB] 与防火墙上特定 NIC 连接的视图：
对于 L3 流量（没有 NAT），S2 会将 S1 的 IP 地址作为源地址。 然后 S2 将子网 B（S1-IP 所属的子网）的返回流量发送到子网 C 的 iLB。 由于子网 B 中的 iLB 和子网 C 中 iLB 不会同步其会话状态，根据负载均衡算法，流量可以在 FW-2 上结束。 默认情况下，FW-2 不知道初始（绿色）数据包的任何内容，因此会断开连接。
某些防火墙供应商试图在防火墙之间保持连接状态，但要保持最新的连接状态，需要几乎即时同步才能实现。 请咨询你的防火墙供应商是否推荐这种设置。
处理此问题的最佳方法是消除此问题。 在上面的示例中，此解决方案意味着要消除子网 C，从而获得虚拟化 Vnet 的优势。
使用网络安全组隔离子网中的主机
当一个子网中有两个 VM 时，可以应用 NSG 来隔离这两者之间的流量。 默认情况下，完全允许 VNet 内部的流量。 在 NSG 上添加“全部拒绝”规则，将所有 VM 彼此隔离。
VNet 使用相同的后端（虚拟）路由器
VNet/子网使用 Azure 中的单个后端路由器系统，因此无需为每个子网指定路由器 IP。 路由目标可以是同一 VNET 中的任何位置，甚至可以是外部。
利用虚拟化网络可以控制每个子网中的路由。 这些路由还可以指向另一个子网中的单个 IP。 在上图中，这是子网 D 中的 iLB，它对两个防火墙进行负载均衡。 例如，当 S1 发起流量（绿色）时，它将被负载均衡到 FW-1。 FW-1 然后会连接到 S2（仍为绿色）。 S2 会将响应流量发送到 S1 的 IP 上（禁用 NAT 时）。 由于路由表，S2 会使用同一 iLB IP 作为其网关。 ILB 可能会将流量与初始会话匹配，因此它会始终将此流量指向 FW-1。 然后，FW 1 将其发送到 S1，建立同步流量流。
要使此设置有效，FW 需要具有一个内置路由表，将子网 B 和子网 C 指向其默认子网网关。 该子网网关是该 VNET 的子网范围内的第一个逻辑上可用的 IP。
对反向代理服务的影响
部署反向代理服务时，通常需将其部署到 FW 后面。 你也可以将其与 FW 并排部署，实际上通过 FW 路由流量。 这种设置的优势是反向代理服务可以看到连接客户端原始 IP：
对于此配置，子网 E 上的路由表需要通过内部负载均衡器指向子网 B 和子网 C。 某些反向代理服务具有内置防火墙，因此可删除此网络流中的所有 FW。 内置防火墙从反向代理直接指向子网 B/C 服务器。
在这种情况下，反向代理上还需要 SNAT，以避免流过返回流量以及防火墙拒绝流向子网 A 的返回流量。
VPN/ER
Azure 通过 Azure 虚拟网络网关提供启用了 BGP 的/高度可用的 VPN/ER 服务。 大多数架构师都将这些服务用于后端或非面向 Internet 的连接。 此设置意味着，路由表还需要在这些连接后面容纳子网。 虽然与子网 B/C 连接的差别不大，但还是具有针对返回流量的设计；完成图片：
例如，在此体系结构中，从子网 B 到子网 X 的流量到达网关时，会被发送到 iLB，后者又将该流量发送到任一防火墙。 防火墙内的内部路由会将流量发送回子网网关（子网 D 中的第一个可用 IP）。 无需将流量直接发送到网关设备，因为子网 D 中的其他路由会让子网 X 的路由将其发送到“虚拟网络网关”。 Azure 网络会负责实际的路由。
从子网 X 返回的流量将被转发到子网 D 中的 iLB。 GatewaySubnet 还将有一个自定义路由，该路由将子网 B-C 指向 iLB。 子网 D 不经过 iLB。 这会被视为常规 VNET 间路由。
虽然图中未显示，但加入一个子网 A 的路由将其指向 iLB 对于子网 B/C/D/网关来说是有意义的。 这种安排可以避免使用“常规” VNET 路由绕过防火墙。 根据 Azure 网络堆栈，这里的子网 A 只是 VNET 中的另一个子网。 虽然你会将子网 A 视为 DMZ/Internet/等，但它不会区别对待。
总结
简而言之，在具有多种接口（虚拟或物理）的本地（基于物理/VLAN 的）网络中处理防火墙的方式与在 Azure 中的方式不同。 如有必要，你仍然可以（在一定程度上），但有更好的方法来确保你可以最大限度地减少故障转移停机时间；进行主动-主动模式的实现和获得干净的路由表。
若要详细了解如何使用负载均衡器作为所有流量的网关，请参阅高可用性端口概述。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Roelf Zomerman | 高级云解决方案架构师
后续步骤
了解有关组件技术的详细信息：
相关资源
探索相关体系结构：