VPN 已连接但某个服务失败：分段定位

在 VPN 工单里，「已连接」是信息量最少的事实。它只记录两端完成了握手，对查询过的名字、数据包从哪个接口发出、包有多大、对端是否接受，一概不提。所以同一台笔记本上其他应用都正常，却可能只有一个服务失败。按顺序走完各阶段，第一个失败点就会指出故障。

从名字开始，而不是从隧道

先解析再路由，因为错误的答案会让之后每项测试都失去意义。用系统解析器查询该名字，再把结果与应用实际使用的地址对比。私有名字返回公网地址，说明查询发到了没资格回答它的解析器。解析失败的名字属于同一类，只是更响亮。

resolvectl query host.internal
getent hosts host.internal

自带安全 DNS 设置的浏览器会在这里失败，而系统其余部分正常。所以只涉及浏览器的问题首先属于这个阶段，然后才轮到有人去动路由。两条命令都要比对而不是只比一条，因为 getent 走 NSS 路径，解析器查询不走。

问内核它选了哪条路径

路由表是一种优先顺序，内核选中的路径并不总是拓扑图上的那条。直接针对目标地址问它。回答会给出接口、下一跳和将要使用的源地址。数据包可能带着对端拒绝的源地址从隧道出去，而物理表中更具体的条目可能改从 Wi-Fi 接口发出。

ip route get 10.20.30.40
ip -brief address show

按这个顺序读 dev、via 和 src 三个字段，因为每一个都排除一种不同的怀疑。这个阶段还负责客户端安装的状态，因为异常退出后防火墙规则和路由可能残留。所以「没有隧道就没有网络」和「客户端不运行就没有网络」是同一类故障，而不是两类。

测试数据包大小

大传输卡住时小回复却能返回，首先指向路径 MTU。从隧道内部发出一个置位 do-not-fragment 的探测，就能把这个阶段与其他阶段分开。逐步加大载荷直到探测失败，就得到了关键数字。

ping -M do -s 1400 10.20.30.40

小探测能通、而目录列表或上传卡住，正是这个阶段的特征。工单描述听起来像凭据或防火墙规则，其实两者都不是。

这个数字是路径的属性而不是客户端的，所以办公网络下可用的值在移动链路上可能失败。把探测命令随工单保留，因为下一个人需要同样的测量。如果更小的载荷能通过，修法是 clamp 或降低隧道 MTU，而不是换新加密算法。

测试远端

按地址测试目标，然后看那里有什么在监听。连接被拒绝和连接从不回应是两种不同的结论。前者说明有东西在运行但不服务该端口，后者说明什么都没返回。默认情况下两者都不是客户端问题。

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

通过隧道能到达的东西，不可能是只监听 127.0.0.1 的服务，因为监听者根本看不到数据包。当远端主机的防火墙放行办公子网、却拒绝隧道地址池时，结果看起来像客户端故障，其实不是。网页流量正常而远程桌面或文件共享断掉，通常就落在这一阶段，无论用户怎么描述。

把工单对应到一个阶段

大多数报告会归入五种形态之一，每种形态对应一个阶段。只有一个站点能通过隧道访问，是名字解析结果或与源地址绑定的策略。不走隧道时更新失败但浏览正常，是那个客户端的名字或路由问题。

提供商客户端一启动就全部中断，是已安装的状态，也就是路由和防火墙问题。其余都正常而某个服务不可达，是远端问题。传输几秒后就卡住，是数据包大小问题。先匹配形态再跑命令，因为它决定先收集哪些证据。

把产生第一个失败的阶段连同命令输出一起记录。说明源地址有误并附上路由行的工单值得处理，而只说 VPN 坏了的工单不值得。