Azure S2S VPN 显示已连接却没有流量：先读 IKE 日志

门户显示 Connected，隧道有运行时间计数器，而从虚拟机发出的 trace 死在第二跳。连接状态描述的是 IKE 和 IPsec 协商，而不是数据包能否穿过任意一侧的策略层。这类工单多数由两种故障造成，而两者都不是改一条 Azure 路由能修好的。两种故障都已经写在网关生成的日志里，所以我不从路由表、而是从日志入手。

Connected 究竟证明了什么

站点到站点连接处于已连接状态，只说明 第 1 阶段和第 2 阶段已完成、安全关联已建立。这是关于协商的陈述：双方就某个提议达成一致、交换密钥并装好了这一对 SA。它既不说流量选择器是否与你以为受保护的子网一致，也不说对端在解密后会不会把数据包路由到别处。隧道可以挂上几周，同时把每一个有意义的流都丢掉，而这正是让人去重建一个健康网关的那种现象。

最该先查的两种故障是：对端提议 AH 而不是 ESP；虚拟网络编址落在网关不会视为内部的地址空间里。

动路由之前先打开导出的日志

在门户中打开虚拟网络网关，对该连接运行 VPN troubleshoot，然后下载它生成的包并解压。里面有 IKE 日志，包含第 1、2 阶段的交换内容，带时间戳、可按纯文本阅读。不要从头往下读，直接搜 transform 那一行，因为关键条目通常在几百行之后。如果你没有门户权限，开启诊断设置后同样的诊断信息会出现在网关的日志目标里。

其中两条记录承载了大部分价值。第一条大意是 expected ESP with combined authentication and cipher, received AH。第二条是 IKE 交换期间的 invalid payload 错误，通常意味着提议字段格式错误或不受支持。

两条记录描述的都是本地设备提议了什么，所以都属于对端一侧的设置。重建 Azure 一侧并不会改变防火墙发出的提议，硬要这么做正是这套流程里最常被浪费的一小时。在对端把第 2 阶段设为带组合认证与加密的 ESP，让设备自行协商算法，然后检查某个名为 combined mode 之类的厂商复选框是否在底下悄悄选了 AH 提议。

确认虚拟网络的地址空间

网关期望虚拟网络位于私有地址段。编址落在公网块里的网络，例如以 111.x 开头，隧道可能照样起来，但 Azure 拒绝把那段空间视为内部，于是连接看着健康，却没有任何流被接受。在花一下午折腾选择器之前，先确认地址空间。如果这套编址是旧分配留下的硬性要求，解决办法是改地址规划，而不是换一个网关。

趁你还在地址空间面板里，把与本地地址段的重叠记录下来，因为重叠的前缀会造成另一种故障，从客户端看却很像。

两个方向都核对前缀

本地网络网关资源里保存着本地前缀，它们必须与远端设备真正保护的子网一致。一个包含设备会丢弃的地址的汇总，会让部分流通过、部分流失败，读起来像间歇性路由故障，而不是配置不一致。远端也要看：一端列 /16，另一端列出它里面的三个 /24，这就是典型的部分故障。两份清单都不能单独作准，所以要并排比对，而不是相信你手头看得到的那一份。

前缀改动不一定被自动接住，所以要计划重新保存或重建连接对象，然后确认新前缀在两侧都出现。

测路径，不要只 ping

区分隧道通与路由通的 trace 长这样：第一跳是本地网关，接着几跳不回应，然后远端主机回话。如果 trace 根本到不了主机，就测应用真正使用的 TCP 端口，因为 ICMP 被过滤得太常见，ping 失败几乎说明不了问题。再从远端主机朝 Azure 里的虚拟机做同样的 trace。两个结果的非对称，是找出缺失回程路由或只放行单向规则最快的方法。

把对端提议、两侧地址空间和连接创建时间写进工单，下一位工程师才知道哪些值被重建过、哪些从来没动过。

如果日志回来是空的，网关可能根本没有在终结你的连接。确认本地网络网关上的对端地址与你在读日志的那台设备一致，因为同一订阅里的两个网关在重建时很容易弄混。这个错误要耗掉一天，而且在任何日志里都不留痕迹。