为什么一个 VPN 资源能用，另一个却超时

一个私有服务能通过隧道加载，下一个却超时，于是人很容易想重建整个客户端配置。能用的那个服务作为对照比作为推倒重来的理由更有价值。它只证明一个目的地、一个端口和一条授权路径被满足了，除此之外什么也没证明。

同一网关上的两个服务可能走不同的地址族、不同的子网和不同的策略。

把能用的流和失败的流分开

把每个服务当作自己的流，而不是 VPN 的症状。一个示意客户端可以在 172.20.4.15:443 上打开 portal.corp.example，却仍然到不了 172.20.9.40:5432 上的数据库，因为那是两条规则集下的两个目的地。改动任何东西之前，把两行都写下来，包括端口和协议，因为允许某个主机上 TCP 443 的规则，对同一主机上的 TCP 5432 什么也没说。

要调查的是失败的那一行。能用的那一行只告诉你基线在哪里，而它会成为每次改动后的对照点。

先比较地址，再比较名字

用应用真正使用的策略去解析每个完整名称，然后记录它选中的地址族。一个名字可能返回 IPv6 地址，另一个返回 IPv4，而缓存里的旧答案可能把请求发到与私有服务毫无关系的公网地址。

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

这次查询回答的是一个狭窄的问题：在当前的表和策略规则下，这台主机会为那个目的地选哪条路由。到 172.20.4.0/24 的路由并不覆盖 172.20.9.0/24，而第二个网络管理器或更具体的本地路由可能悄悄压过隧道。在命名空间内重做查询，或者在与应用不同时带上应用使用的标记。还要记录数据包从哪个接口离开，因为路由表可能写的是一个接口，而策略路由却把流量从另一个接口送出去。

匹配的路由是必要条件，不是许可。它只说明数据包有地方可去，至于防火墙、授权服务或主机本身是否接受，它什么也没说。

协议和响应阶段会告诉你它停在哪

ping 有回应并不能证明数据库端口是开的，一个成功的 HTTPS 页面也不授权同一台机器上的文件共享。记录实际返回了什么，而不是把每种失败都压成一个类别。超时、重置、TLS 身份错误和应用层拒绝，各自指向不同的层。

这个区分很重要，因为修法不同。沉默通常意味着路径上的路由、防火墙或地址转换问题。立刻重置说明有东西到达了主机并拒绝了端口。证书错误意味着连接到了但名字不匹配，这是配置问题而不是可达性问题。应用拒绝意味着网络完成了它的工作，身份随后被拒绝了。

当资源通过网关发布时，把目的地看到的源地址与客户端认为自己使用的源地址作比较。由网关自己发起的请求可能成功，而同一个请求从客户端发出却失败，因为两者来自不同的地址，遇到不同的规则。

只改一个变量，再跑两个请求

身份是人最后去看的地方，也是正确拒绝最先出现的地方。VPN 登录、目录组和应用账号是三个可能彼此分离的身份。能进门户从不意味着能进它背后的数据库，一个目录里的名字也不会在另一个目录里造出一行。如果服务在用户预期范围之外，那个拒绝就是系统在正常工作。

请资源所有者确认预期的权限，而不是加一条宽路由或把某个组打开来试。为了证明一个观点而放宽网络，正是临时诊断变成长期暴露的方式，而且它会毁掉你一开始的对照。每轮迭代只证明一处不匹配就够了：缺一条路由、地址族不对、端口被挡或缺少组成员资格。

每次改动之后，重跑两个请求并把输出并排留着。当失败的服务在自己的策略下能工作，而能用的服务和那些你仍然预期的拒绝都表现得和之前一模一样时，调查就结束了。