9.2 ICMP、ping 与 traceroute 的证据边界
ping 和 traceroute 可以提供路径证据，却不能单独诊断故障。超时可能来自丢包、过滤、限速、回程异常，或中间设备不回答。本课区分这些工具实际测到了什么，再把网络层结果与同一目标的 TCP、TLS 和 HTTP 检查放在一起。
ICMP 是 IP 协议族中的控制和错误报告协议，消息由 IP 承载，并非独立的“带外通道”。IPv4 的 Protocol 值为 1，ICMPv6 的 Next Header 值为 58；两者的类型与代码空间不同，不能直接互套。
1. ICMP 报告网络状况，也可能丢失
IPv4 中常见的消息包括：
| 类型 | 用途 |
|---|---|
| Echo Request 8 / Echo Reply 0 | ping 的请求与应答 |
| Destination Unreachable 3 | 网络、主机、协议或端口不可达，以及需要分片等，具体含义由 code 区分 |
| Redirect 5 | 建议主机改用另一下一跳，接收策略通常受到限制 |
| Time Exceeded 11 | TTL 耗尽或分片重组超时 |
| Parameter Problem 12 | IPv4 首部字段存在问题 |
ICMP 错误会引用原报文的一部分。IPv4 的基本格式包含原 IP 首部和至少前 8 字节载荷，便于发送端关联原来的流；扩展和实现可以携带更多内容。NAT、防火墙与负载均衡器也需要检查这段引用，不能只看外层 ICMP 地址。RFC 792
ICMP 同样尽力而为，设备可能对生成的错误消息限速，网络策略也可能丢弃它们。没收到错误不代表网络没有故障；收到 unreachable 时，则要核对 type/code 和引用报文是否对应本次探测。
为防止错误循环，IPv4 通常不对 ICMP 错误再产生 ICMP 错误，也不对广播、多播或非首片等报文生成普通错误。ICMPv6 有自己的规则，例如 Packet Too Big 对多播目的有例外，不能把 IPv4 的禁发条件原样照搬。RFC 4443 §2.4
2. ping 检查 Echo 往返，不检查应用健康
下面使用 Linux/iputils 语法。192.0.2.10 是文档地址，实际执行时换成自己的实验目标；检查本机协议栈可使用 127.0.0.1：
ping -c 4 192.0.2.10Echo Reply 说明在当时的路径和策略下，请求与应答完成了往返。它不能证明：
- TCP 443 可连接；
- TLS 证书和域名匹配；
- HTTP 应用正常；
- 大包与小 Echo 包受到相同队列和策略处理；
- 正向与反向路径相同；
- 之后的延迟和丢包仍然稳定。
Echo 超时也不能证明主机宕机。设备可能过滤 Echo，或降低控制面应答优先级，同时继续转发业务流量。ping 很适合回答“这次 Echo 回来了吗”，不负责替整个服务签健康证明。
3. traceroute 用 TTL 或 Hop Limit 逐跳探测
经典 Unix UDP traceroute 向较高的目的端口发送探测，并依次增加 TTL：
- TTL=1 时，第一跳将它减至 0，丢弃报文并可能返回 ICMP Time Exceeded；
- TTL=2 时，探测通常能到第二跳；
- 到达目标后，若 UDP 端口无人监听，目标返回 Port Unreachable，探测据此识别终点。
下面限制为最多 12 跳、每个探测等待 1 秒。Linux 的常见实现支持这些选项，其他系统应查本机手册：
traceroute -m 12 -w 1 192.0.2.10
# 改用 ICMP Echo 或 TCP SYN 探测
traceroute -I -m 12 -w 1 192.0.2.10
traceroute -T -p 443 -m 12 -w 1 192.0.2.10Windows tracert 默认使用 ICMP Echo，到目标后以 Echo Reply 识别终点。TCP SYN 探测通常以目标的 SYN-ACK 或 RST 识别终点；中间设备也可能生成响应，仍需核对目标。TCP traceroute 更接近 HTTPS 的端口策略，却没有完成 TLS 或 HTTP 验证。
4. 跳列表不是完整拓扑图
* 可能表示应答被过滤、限速，探测丢失，或回程不通，不必然表示该路由器停止转发。显示的地址是设备生成 ICMP 时选择的源地址，不一定是探测进入或离开的那个接口。
等价多路径（ECMP）常按流散列。探测的五元组变化时，可能走不同路径，所以同一行出现多个地址不等于一个包在多个路由器间反复跳跃。NAT、MPLS 和隧道还可能隐藏部分跳数，回程也可能与去程不同。
Paris traceroute 等方法会尽量稳定负载均衡使用的字段，减少由探测本身造成的虚假拓扑。即使如此，结果仍只是某个时间、某类探测的观察，不能保证业务流完全经过同一路径。
5. ICMP 与路径 MTU 发现
IPv4 的 Fragmentation Needed 与 ICMPv6 的 Packet Too Big 支持经典 PMTUD，它们不同于 traceroute 使用的 Time Exceeded。完整诊断见8.3。
一概丢弃 ICMP 可能破坏 PMTUD。ICMPv6 还承载邻居发现等基本功能，因此应按类型、代码和接口角色制定规则，对错误引用做校验，并合理限速，不能把所有消息当作可有可无的探测流量。
6. 让多种探测指向同一个目标
下面面向 Linux，依赖 getent、iproute2、iputils、traceroute、netcat 和 curl。先把两个变量改成自己的目标，并确认所选 IPv4 地址确实对应这个主机名。curl 的 --resolve 固定连接地址，同时保留正确的 TLS SNI 和证书域名检查：
TARGET_HOST=example.com
TARGET_IPV4=192.0.2.10
# 对照 DNS 结果与本机路由选择
getent ahostsv4 "$TARGET_HOST"
ip route get "$TARGET_IPV4"
# 对同一 IPv4 地址收集 ICMP 和传输层证据
ping -c 4 "$TARGET_IPV4"
traceroute -m 12 -w 1 "$TARGET_IPV4"
nc -vz -w 3 "$TARGET_IPV4" 443
# 直接访问指定地址上的 HTTPS 服务，保留主机名验证
curl -v --noproxy '*' --connect-timeout 3 --max-time 10 \
--resolve "${TARGET_HOST}:443:${TARGET_IPV4}" "https://${TARGET_HOST}/"nc 成功仅表示 TCP 端口连接成功；curl 还会经历 TLS 和 HTTP。记录源网络、地址族、时间、探测类型及错误，再用抓包或计数器核对。使用代理访问业务时，还需另外检查代理路径，不能把这里的直连结果套过去。
7. 验收问题
- 为什么 ICMP 不属于独立的带外通道？
- ping 成功能证明什么，不能证明什么？
- UDP、ICMP Echo 和 TCP traceroute 通常如何识别终点？
- 同一跳出现多个地址或星号，有哪些可能原因？
- 为什么不能完全阻断 ICMPv6？
下一课进入9.3 NAT、NAPT 与穿透边界。