Ping 不是证据：测试两个站点之间的路径

隧道是通的，网关之间互相应答，可一个站点的用户仍然打不开另一个站点的文件共享。有人从网关 ping 一下，拿到回包，就宣布网络健康。那个回包只是穿过了两台从来不是问题的设备。有用的测试从需要该服务的那台主机开始，使用应用实际使用的协议，并复现它失败时的条件。其余的一切，都只是给一条没人在走的路径亮绿灯。

从需要该服务的客户端开始

测试之前先写下四件事：客户端地址、目的地址、主机名和应用端口。然后确认该服务在自己的站点上从旁边一台主机访问是正常的。没有这条基线，你无法区分隧道坏了还是服务坏了，而这类工单里有一半是后者。

试试文档里写的主机名，并在服务允许时对同一端口做一次直连地址检查。名称解析失败和解析出的地址不可达，会把你引向不同的排查方向。如果你用 IP 替代主机名，不要为了让它能用就关掉 HTTPS 身份校验；证书告警是信息，不是障碍。

在每个边缘上走一遍路径

先看客户端选中的路由，再看网关为该目的地选中的路由，然后看每个边缘的计数或限定范围的抓包。你要找两个事实：请求有没有到达远端局域网，以及有没有回包。接口计数包含其他所有流量，所以要按精确时间戳和地址对来对照，而不是看图线形状。在错误的边缘抓包比不抓更糟，因为它看起来像证据。

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

如果请求出现在远端边缘，后面却没有回包，问题就在对端：防火墙、缺失的回程路由，或者不接受该源地址的主机。如果请求根本没出现，那就是本地路由或隧道选择器没有承载它，对端还不值得查。

使用应用实际使用的协议

ICMP 是很弱的探针。它可能被过滤、被限速，或者由与服务不同的策略处理，这让它的成功和失败都变得模棱两可。要测真实端口，并尽可能测真实的协议握手。

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

完成一次 TCP 握手只能证明该端口可达且策略放行。它不能证明应用可用：认证、上传或某个具体的 API 调用仍然可能失败。要测用户真正执行的操作，用无害的等价操作，而不是反复提交真实交易。

复现失败时的条件

只在大传输时出现的失败是尺寸问题，不是连通性问题。发送一个设置了 don't-fragment 位的大包，看它停在哪里。小请求成功而大请求卡住时，隧道 MTU 和网关上的 MSS 处理就是下一个嫌疑点。

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

如果只有一个子网失败，就看流量选择器、路由通告和该子网的回程网关。如果只有主机名失败，就顺着 DNS 查，包括客户端用了哪个解析器，以及从该站点能否看到远端的视图。三种不同的故障、三种不同的修法，而 ping 测试一种都分不出来。

修好之后，重复同一个测试

用完全相同的客户端、目的地、端口和负载再跑一遍。然后重连，或者按设计演练切换路径，因为只在原隧道实例存活期间有效的修复并没有被验证。让测试绑定真实的源、真实的目的地和真实的操作，而不是仪表盘上一个绿色指示灯。

记下这四项基线值和结果。下次出现同样症状时，就能从证据开始，而不是从 ping 开始。