Azure IP 流验证说允许，但 VPN 仍然失败

站点到站点隧道已连接，VM 状态正常，但本地客户端什么都收不到。你打开 Network Watcher，运行 IP 流验证，它显示 Access allowed，于是工单被当作 VPN 问题关闭。这个结果并不是它看起来的意思，因为 IP 流验证只评估你所描述流的安全规则，从不检验 Azure 是否有通往本地前缀的路由。

筛选问题和路由问题是两回事，Network Watcher 用不同的工具分别回答。知道自己问的是哪一个，就是诊断的大部分。

IP 流验证究竟决定了什么

IP 流验证接收 VM、网络接口、方向、五元组值和协议，然后报告该流在 NSG 和安全管理员规则下的判定。它只处理 TCP 和 UDP，因此不是 ICMP 规则测试器，被阻断的 ping 不能证明服务的任何问题。要给它真实的流，而不是猜测。从本地到数据库端口的入站连接，与 VM 发起的出站连接，是两种不同的描述。

如果网关做地址转换，请使用到达你所评估边界的源地址，而不是客户端配置里的地址。也要按原样理解结果。Access allowed 只表示数据包若到达，筛选层会放行，仅此而已。

它无法告诉你 Azure 选择了哪条路由、来宾防火墙是否放行该端口，或者是否有进程在监听。这些都在其他层。

下一跳和有效路由补充了什么

下一跳回答转发问题：对这个目标，Azure 选择哪种下一跳类型、在哪个地址、来自哪张路由表。有效路由列出网卡实际拥有的内容。两者都运行，你就能得到绿色 IP 流验证留下空白的那段 Azure 侧路径。

Microsoft 的 IP 流验证概述 直接说明了筛选范围，而下一跳和路由诊断页面覆盖转发一侧。写结论时引用正确的那一页。

这些命令短到可以直接在 shell 中运行。az network nic show-effective-route-table 列出应用到该接口的路由。az network watcher show-next-hop 给出源和目标后返回选中的跳。把你关心的前缀与那张表对照，然后确认哪条记录胜出。

从 VM 网卡走一遍回程

要从目标 VM 的网卡出发，针对本地客户端前缀，而不是针对互联网。回程正是站点到站点故障藏身之处，因为隧道状态检查只会报告安全关联已建立。

如果缺少预期路由，检查网关配置提供的远端前缀、VNet 连接设计以及任何路由传播设置。本地网络网关对象描述的是本地一侧；它的存在并不能证明每条所需前缀都存在于网卡上并被优先选择。这是不同的事实，而门户摘要里只会出现其中一个。

读下一跳类型，而不是照抄示例

受管 VPN 网关路径通常把 VirtualNetworkGateway 显示为下一跳类型。VirtualAppliance 描述的是另一种转发设计，通常是防火墙或网络虚拟设备。

不要因为旧论坛回答用过那种类型，就创建指向猜测的 VPN 端点的设备路由。如果用户定义的路由覆盖了预期路径，先找到它的归属和用途再改动。第二块网卡也会改变来宾使用的接口，移除它可能修不好这条路由，反而弄坏另一项服务。

转向仍失败的边界

当筛选和路由都符合设计时，故障在别处。检查来宾自身的路由表、防火墙，以及监听是否绑定到预期地址。然后检查 VPN 的受保护流量选择器和本地回复路径。每一项都是独立测试，有独立结果。

以一次被允许的应用请求和两端的观察收尾。allow 结果和正确的下一跳是两条证据，而不是连接成功的证明。