VPN 启动后 Azure VM 无法访问 IMDS 或 WireServer

VM 正常运行，VPN 客户端显示已连接，几分钟后 Azure 代理开始报告状态异常。有时 SSH 还活着，但门户里的 Run Command 不行，于是人们去看代理，而不是看路由表。隧道建立时客户机自身的转发决策变了，而两个平台地址通常最先遭殃。我先把这当成路由症状，而不是代理故障。

症状看起来像代理坏了

下面两个地址都会被当作修复方案提出来，但它们并不是同一个服务。因为其中一个管用就把 /32 复制给另一个，正是临时绕行变成谁也不敢删的永久配置的方式。

有效的顺序是：先确认失败调用真正指向哪个地址，再读客户机如何解析它。其余做法只是多了几步的猜测，以及更长的变更窗口。

168.63.129.16 不是公网目的地

168.63.129.16 是 Azure 的特殊虚拟平台地址，其作用之一是 WireServer，VM 代理用它和底层结构通信。Microsoft 明确记录，代理到 TCP 端口 80 和 32526 的流量必须保持可用。它不是普通互联网主机，也不该被全隧道 VPN 带到远端出口。所以看起来健康的隧道仍然可能让代理饿死。

平台地址文档也指出该地址不受用户定义路由约束，这是 Azure 底层结构的属性，而不是对你客户机的承诺。本地防火墙规则或 VPN 客户端自己的路由策略仍可能切断路径，而这两者都不在 VNet 的路由表里。

如果是代理在报告问题，先检查服务状态和到该地址的路径，再考虑重装任何东西。

169.254.169.254 有自己的规则

169.254.169.254 是 Azure 实例元数据服务的 link-local 地址。发往它的请求有自己的要求：主网卡和主 IP、支持该地址的 DHCP 配置，以及绕过任何 HTTP 代理。把它们送进远端 VPN 出口或任意互联网网关，并不是 Microsoft 描述的访问模型。

代理这一条会抓住那些修好路由却仍看到失败的人。客户机里的 HTTP 代理可能破坏 IMDS，而 ip route get 却返回你预期的接口，所以除了路由还要检查代理例外。

调试时不要把元数据响应粘进支持工单。它们可能带有比事件本身更长寿的凭据和实例细节。

读客户机的策略路由，而不只是主表

在 Linux 客户机上，三条只读命令把层次分开：ip -4 rule show 看策略规则，然后 ip -4 route get 168.63.129.16 和 ip -4 route get 169.254.169.254 看内核实际做出的决定。在 VPN 连接前后各跑一次。两次输出的差异就是你的变更集，它比任何猜测客户端做了什么更有用。

安装策略规则的 VPN 客户端可以不动主表，却仍然重定向这些查询。这就是为什么只改主表的方案在一台主机上看似有效，在下一台上却毫无作用。多网卡客户机会从另一个方向带来同样的问题，因为答案取决于规则选择哪块网卡和哪个源地址。

不要照搬把两条 /32 都指向旧网关的做法。link-local 平台路径和一般 WAN 下一跳是不同的对象，一刀切的例外会掩盖真正的策略冲突。

把管理和恢复分开

你的 SSH 或 RDP 回复也可能被全隧道默认路由捕获，但它指向管理员被观察到的地址，而不是任何平台端点。用成对的请求和回复去诊断它，并在改动 VPN 策略之前保留一条独立恢复通道，比如串行控制台。如果某次部署重启了 VM 且代理报告异常，应检查记录的操作和负责的服务，而不是假定重启是路由变更造成的。

然后分别验证三条流：你真正想要的私有资源、受支持的代理与平台通信，以及管理路径。恢复其中一条并不证明另外两条还活着。

把批准的例外写在客户机网络和 VPN 配置的负责人名下，包括重连和重启时会怎样。Azure UDR 不是客户机的路由表，编辑它并不能修复本地策略规则。