Azure P2S VPN 回程流量只通一个方向

隧道图标是绿色的，NSG 看起来是放行的，有效路由看起来也没问题，但 VM 仍然无法向已连接的客户端发起反向连接。通常的假设是：一条能用的点对站点隧道是对称的——客户端能到 VM，VM 就能到客户端。这个假设本身就是推理上的错误，而不是配置错误。隧道可能只承载单向的非请求流量而丢弃另一向，修复方式取决于丢在哪一层。

误区：隧道连上了就是双向的

VPN 隧道是一条策略路径，不是一根线缆。每个方向都要与选择器、路由和过滤器匹配，其中任何一项都可能放行一个方向而阻断另一个方向。

实践中这种不对称非常普遍，所以方向应该放在第一项测试，而不是最后一项。客户端发起连接、网关跟踪流状态、回包沿已建立的状态返回；而由 VM 主动发起的新流没有这种状态，只能依赖返回路径被显式路由并放行。一旦缺少这条路径，连接尝试在任何应用看到之前就已经失败。

先测方向，再测可达性

选定一个客户端地址、一个 VM 地址和一种协议。从客户端发起连接并记录结果；再从 VM 发起同样的测试并记录。如果前者成功而后者失败，说明客户端地址池、网关关联以及客户端到 VNet 的路径都是正常的。

下一步是取证，而不是加规则。检查 VM 子网上的 NSG 双向规则，读取 VM 网卡上的有效路由，并在客户端发包时在 VM 上抓包。请求到达但没有响应，说明是过滤或回程路由问题；请求根本没到，说明是路径问题。不要因为 ping 失败就断定 VM 不可达，因为 ICMP 策略可能丢弃回包，而 TCP 仍然正常。

IKEv2 点对站点的回程路径是常见嫌疑

本文所依据的 Azure 报告中，客户端可以通过 IKEv2 访问 VM，但 VM 到客户端的入站 ICMP 一直失败，直到把网关隧道类型切换为 OpenVPN。报告者称微软确认了 IKEv2 点对站点路径的限制：除非由客户端发起会话，否则从 VM 到客户端的回程流量不会对称路由。IKEv2 依赖流量选择器，而该场景下网关没有遵守回程方向。

这并不说明 OpenVPN 在总体上就是更好的隧道类型，只是说明在这个工作负载的测试矩阵里，隧道类型是一个变量。

切换隧道类型是一次服务变更，而不是拨个开关。每个客户端都需要兼容的配置文件，网关可能还需要不同的证书或身份验证设置。用一个测试客户端和一个测试 VM 复现单向现象，按已批准的窗口切换类型，然后重跑同样的方向测试。如果切换后现象依旧，说明隧道类型不是原因，你在不碰生产的前提下缩小了问题范围。

误区：广播发现能跨越 VNet 边界

第二个假设因为另一个无关原因而不成立。Azure 虚拟网络不承载广播流量，因此 VM 无法通过站点到站点或点对站点连接收到来自本地网络的广播帧。依赖广播寻找对端的应用，例如老式文件浏览或某些设备发现协议，无论路由怎么写都永远看不到远端。

用 DNS 名称、目录服务或显式对端列表替代广播发现。如果应用没有单播替代方案，需要改变的是发现机制，而不是把隧道开得更宽。

该改什么，以及如何证明

如果方向测试只在 IKEv2 上失败，记录网关隧道类型、客户端地址池和具体的 ICMP 或 TCP 测试，然后为受影响客户端评估一份获批的 OpenVPN 配置。如果在所有隧道类型上都失败，就排查回程路径：客户端地址必须能从 VM 子网路由，任何用户定义路由都必须指向有效的下一跳，客户端防火墙必须接受入站流量。把 NSG 和路由证据附到工单里。

用应用来验证，而不是用 ping。变更后 ICMP 能通，并不能说明服务端口、身份验证或名称解析是否正常。重连之后再测一遍，因为拿到不同地址池地址的客户端可能改变结果；客户端休眠再唤醒后再测一遍，因为恢复的会话正是一向行为最容易复现的地方。