Azure NVA 检查：为什么回程经过另一台防火墙

一条从分支到 Azure 的流，即使两个方向的路由都配置正确，仍然可能失败，因为两个方向走了不同的设备。请求经 VPN 离开分支，落到 NVA A 并到达工作负载。回程从工作负载发出，匹配到指向 NVA B 的路由，就在那里断掉。图里每条路由都有效，但 TCP 会话仍然断了。

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

这个缺口就是本文的全部主题：路由收敛与会话状态归属是两个不同的问题，在图上却长得一模一样。

Route Server 实际编程的是什么

Azure Route Server 与受支持的 BGP 发言者建立对等，学习它们的路由，并把路由编程进虚拟网络的有效路由。这是控制面的工作。它不读取厂商防火墙的会话表，也不知道是哪台设备放行了某个连接。两条等价的下一跳，对这套网络结构来说只是到达同一前缀的两条路，它会任选其一。

因此学会一条路由只能证明可达性，不能证明另一端的设备见过这条流。

设计之前先读两个方向

先写下每个方向实际存在的引导方式，而不是你打算实现的方式。更具体的 BGP 路由、用户定义路由和网关行为都在竞争，胜者按目的地决定，而不是按会话决定。NVA 上的默认路由并不意味着每个私有前缀都会经过它。

一个有用的检查是：对某个具体的工作负载 IP，分别问两个方向解析到哪条下一跳。如果答案指向两台不同的设备，无论问题是否已经暴露，你都已经有不对称问题。

状态住在哪里

有状态防火墙放行连接后，会保留一条以五元组为键的表项。回程必须回到持有该表项的设备，或者那台设备必须通过其他方式取得状态。Azure 数据面不会在设备之间转发表项。要么把流量引回持有者，要么设备通过厂商机制共享状态，要么这个设计根本行不通。

这就是为什么两台健康的 NVA 不是检查的健康检查。健康关乎可达性；检查关乎哪台实例持有会话。

受支持的 HA 模型及其承诺

Microsoft's guidance on Virtual WAN 路由意图 的指南描述了双角色连接和防火墙 NVA 的受限行为：直接路由可以绕过中心正常的对称强制。要把这些说明读成对所选拓扑的约束，而不是对双活设计的禁止。会同步状态或按流引导的厂商设备对可以支持。两条等价路径却两者都不做的设备对则不支持。

然后定义节点故障时现有会话会怎样。路由收敛能在数秒内恢复新流的可达性，而旧的防火墙状态直接消失。客户端重连可能是被记录在案的结果，这个决定要在事故前做，而不是事故中做。

信任它之前该测什么

Test with inspection enabled and 工作负载的访问策略 的情况下测试，因为两者都可能掩盖不对称。两个方向各发一条新的授权流，确认同一台设备看到了两半。然后跑持续流量并触发已批准的故障切换，观察已建立的会话是存活还是重连。

把每条流与处理它的设备关联起来。如果回程从没回到某台 NVA，那台 NVA 上的抓包几乎说明不了什么。

最后，把方案写成三行独立的内容：路由归属、流量引导、会话状态归属。前两项解决、第三项靠假设时，设计就会崩。