Azure P2S：VNet 变更后一台 Windows 客户端缺少路由

两台笔记本连接到同一个 Azure 点到站点网关，只有一台能访问新接入的 VNet。两者都显示 Connected，因此认证不是差异所在，真正的差异是各自持有的目标路由。先从失败的客户端入手，对比同一个目标，然后才判断缺口属于网关包还是本机路由表。

从失败的客户端入手，而不是从网关入手

在归咎笔记本之前先确认拓扑。检查哪些 VNet 连接到了网关所在的 VNet，以及新网络是直接对等还是通过单独的站点到站点隧道到达。如果新 VNet 根本没有接入网关 VNet，任何客户端包都无法路由过去，那么能正常工作的那台笔记本才是需要解释的异常。把答案记下来，因为它决定了你是在排查客户端还是网关。

拓扑确认无误后，把两台笔记本并排比较。相同的网关、相同的地址池、相同的协议和相同的客户端版本才是你想要的对比；其他任何差异都会成为之后必须排除的第二个变量。

用 route print 对比同一个目标

选一个被允许的资源 IP，对两台笔记本各比较两次：断开时一次，连接后一次。在 Windows 上，route print -4 会列出 IPv4 路由，包括目标前缀、接口、下一跳和度量值。记录真正会在该目标上胜出的那一行，而不是去数包含 VPN 字样的条目。

选路先看最长前缀，再看度量值，因此更具体的本机路由可能压过隧道路由，却看起来并没有错。如果目标地址位于 10.24.0.0/16 之内，健康的客户端会在 VPN 接口上显示匹配的路由，而失败的客户端会把同一个地址发给默认网关。

冲突的本机前缀也会造成同样的现象。在添加任何东西之前，先判断你属于哪种情况：完全没有隧道路由，还是隧道路由输给了更具体的路由。

TTL expired 不是路由分发缺陷

返回 TTL expired in transit 的 ping 说明数据包用尽了跳数配额，通常意味着转发环路，而不是 VPN 驱动损坏。Windows 的 ping 接受最高 255 的 TTL，提高该值并不能修复环路，只会让同一个错误推迟出现。把这条消息当作路径现象，而不是路由分发的证据。

用 tracert -4 10.24.1.10 查看路径在哪里重复。如果同样的两跳反复出现，就去找一条把隧道流量送回隧道、或送入本地路由器再转发回来的路由。

在拥有该包的网关上重新生成

Microsoft 的文档指出，相关拓扑变更后必须重新下载并安装 Windows 客户端包。从服务该配置文件的 Azure 网关获取当前包，然后用该客户端受支持的流程应用它。替换无关 VPN 应用的可执行文件，与重新生成网关专属设置并不是同一个操作。重新下载包的成本很低，猜测本机路由则不然。

重新连接并再次读取原目标的路由。把变更前后的行连同变更记录一起保留，结果会比一句“重装了客户端”精确得多。

Azure P2S 路由场景把直接对等的 VNet 与通过其他隧道到达的网络区分开来，而新包无法让对等关系变成可传递。某些 Windows 站点到站点或 BGP 场景还需要手工配置的远程路由，因此刷新包并不是通用的路由分发机制。

让临时路由保持临时

手工路由可以用来隔离缺失的客户端路由，但要按照真实设计来写：route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42，不加持久化标志，让它在重启后消失。接口索引和下一跳要从已连接的 VPN 适配器上取，而不是靠猜。

不要把实验性路由留成永久的竞争所有者。将来的配置文件更新可能用不同的度量值加入同一前缀，届时手工条目会悄悄决定哪条路径胜出。把删除步骤写进变更记录。

正确路由生效后，测试目标应用而不是 ping。如果数据包能到达 Azure 但服务仍然失败，就检查网络安全组和返回路径，因为这些与笔记本是否学到了前缀是两回事。