两个本地 VPN 地址：两个 Azure 对等体，而不是一个

图中分支机构有两条互联网链路和一个 Azure VPN 网关，因此本地网络网关会得到两个公共地址。看起来很整齐，但并不能按图所示的方式工作。每个本地 VPN 设备都是一个独立的对等关系，Microsoft 的多设备设计为每个设备提供自己的本地网络网关资源和自己的连接。向单个资源添加第二个地址不会创建第二个对等体。它创建的资源无法正确描述这两台设备中的任何一台。

误区：一个网关，两个地址

本地网络网关是对远程对等体的描述：一个公共终结点及其后面的专用前缀。没有受支持的方法能让该资源表示「这两台设备中的任意一台」。

同样的混淆也出现在相反方向：两个 Azure 公共 IP 被解读为存在两个 Azure 网关的证据。

先数对象，再数隧道

取两台独立运行的本地设备，各自拥有自己的公共地址并能访问相同的专用网络，再加上一个采用主动-主动模式的路由型 Azure 网关。该 Azure 网关有两个活动实例，各自拥有单独的公共 IP。每台本地设备都连接到这两个实例。这就是全网状结构，对象数量由它决定，而不是由图纸决定。

这段算术足够短，可以直接粘贴到设计文档中：

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

一个连接资源可以承载不止一条底层隧道，因此四条隧道并不意味着四个虚拟网络网关。两个 Azure 公共 IP 与描述远程站点的两个本地网络网关也不是同一类对象。

主动-主动在 Azure 侧增加了什么

主动-主动把 Azure 网关从一个活动实例变为两个，每个都有自己的公共 IP，正是这一点才使全网状结构成为可能。它不会让单个流的吞吐量翻倍。如果两台设备同时转发，它也不会消除本地侧支持等代价多路径的必要性。在预配任何东西之前，先确认网关模式、SKU 和远程设备的能力。

被动备用网关是完全有效的设计；它只是产生不同的隧道数量。

BGP 让两条路径都可用

对于多设备设计，两台本地设备都运行 BGP。为每台分配唯一的 BGP 对等地址，并在相关路径上通告相同的预期专用前缀。专用前缀标识受保护的网络，而公共地址标识加密承载连接的终止位置。混淆两者会产生所有隧道都已建立但路由错误的设计。

规划返回路由以及任何必须容忍两条路径中任意一条的有状态检查。每个终结点上健康的 IKE 会话并不能证明工作负载可以使用每条通告的路由。

基于流的选择不是带宽聚合

Azure 使用基于流地址和端口的哈希为每个流选择一条路径。在稳定状态下，给定 TCP 或 UDP 流的报文通常走同一条隧道，而本地侧可能为返回方向选择另一条隧道。因此两台设备和四条隧道提高的是可用性，而不是单次传输的速度。当厂商幻灯片承诺聚合时，它描述的是另一种功能或一种误解。

如果想看路径如何分散，就用并行流测试；如果想看极限，就用单个流测试。

你实际去掉了哪种冗余

一台设备上的两个 WAN 地址改善了接入链路的选择，但同时共享该设备的电源、软件和故障状态。它们并不等同于两台设备，Azure 侧的任何配置都无法改变这一点。请遵循厂商支持的双 WAN 或集群设计，而不是从地址数量推断冗余。然后再测试：一次移除一条路径，并确认剩余路由以及双向的真实应用交换。

预计会有检测和收敛延迟，并预计某些现有会话会终止。