浅挖路由跟踪工具的原理

发现问题

在实验《ICMP协议简介》中前半部分一切正常，直到最后使用pc0 tracert pc1的部分出现了一个小插曲：在到达目的主机前的路由中的确是通过设置TTL跳数来达到超时目的（返回TYPE为0x0b），但是在最后到达目的主机时，目的主机应答并返回了（TYPE：0x00reply）这与预期的“端口错误”不符。

调整实验

一开始我觉得可能存在实验失误或者配置问题，于是多次重复试验后，依旧得到相同的结果。带着疑虑，我把实验环境由Packet Tracer虚拟环境搬到了现实的物理环境。

如图为PC机使用WiFi接入校园网后所分配的IP地址：

使用ping命令测试本机与10.16.164.72的连通性，并使用抓包工具抓包：

如图所示，抓包工具抓到了4对request（TYPE：8）与reply（TYPE：0）

使用tracert命令测试到达10.16.164.72经过的路由：

如图所示：到达目的主机前我们收到的ICMP均显示Time-to-live exceeded（TYPE：11）。到达目的主机时，我们主机所收到的ICMP均为reply（TYPE：0），这与ping命令如出一辙。

怀揣着疑问我在微软官方Docs文档中找到了如下解释

新的猜想

猜测

根据如上实验，结合微软官方解释文档，我大胆猜测可能时如下两种情况中的一种或两种：
1.tracert 和 traceroute 本质上是两种不同的命令工具，应用不不同的场景和硬件平台。
2.tracert经过某次更新升级放弃了旧的实现方法。

验证

很快第二种猜测就被我放弃了，因为我检索了microsoft-docs中所有关于tracert和icmp的所有词条，都没有发现tracert关于此方法的update。Google亦是如此。

为了验证第一种猜测，我使用如下三台主机接入同一网络进行实验：

1）网络环境配置过程略过…
2）Windows测试同上，不再赘述…
3）Unix环境测试：
使用traceroute命令测试到达10.16.164.72经过的路由：

如上图：在到达目的主机前收到的ICMP依旧是熟悉的Time-to-live exceeded（TYPE：11）
精彩的部分在下图：

如上图所示：在到达目的主机时收到的ICMP终于出现了盼望已久的的Port unreachable（TYPE：3Code：3）
4）Linux环境下同Unix几乎相同，不在赘述…

借助强大的检索引擎我在某站发现了如下词条：

为了验证这一词条，我使用命令icmp and udp过滤不相关协议，在Windows平台和类Unix平台分别出现了如下两种现象：

上图为Windos平台下，显示结果为没有任何数据包。

上图为类Unix平台下，显示结果过滤后（ICMP and UDP）跟过滤前（ICMP）相同。

得到结论

二者都用于探测数据包从源到目的经过路由的IP，但两者探测的方法却有差别。
结合其他验证得到如下不同点：
（一）tracert是应用在windows下。目标节点reply
此诊断工具通过向目标发送 Internet 控制消息协议 (ICMP) 回送请求，以增量方式增加 (TTL) 字段值，确定目标采用的路径。 沿路径的每个路由器都需要在转发前将 IP 数据包中的 TTL 减 1。 实际上，TTL 是最大链接计数器。 当数据包上的 TTL 达到 0 时，路由器预期会向源计算机返回"ICMP 时间超出"消息。
此命令通过发送 TTL 为 1 的第一条回显请求消息，然后在每个后续传输中将 TTL 递增 1，直到目标响应或达到最大跃点数，确定路径。 默认情况下，最大跃点数为 30，可以使用 /h 参数指定 。 通过检查中间路由器返回的 ICMP 时间"超出时间"消息和目标返回的回显答复消息来确定路径。 但是，对于 TTL 值过期的数据包，某些路由器不会返回"超过时间"消息，并且 对 tracert 命令不可见 。 在这种情况下，将显示一行星号 (*) 跳跃点。 显示的路径是源主机和目标之间的路径中路由器的近端/侧路由器接口列表。 近端接口是距离路径中的发送主机最近的路由器接口。

（二）traceroute则是应用在linux/BSD/router/UNIX下，基于UDP协议的路由探测。目标节点“端口不可达”
主叫方首先发出TTL=1的数据包，第一个路由器将TTL减1得0后就不再继续转发此数据包，而是返回一个ICMP逾时报文，主叫方从逾时报文中即可提取出数据包所经过的第一个路由器地址。然后又发出一个TTL=2的ICMP数据包，可获得第二个路由器地址，依次递增TTL便获取了沿途所有路由器地址。
需要注意的是，并不是所有路由器都会如实返回ICMP超时报文。出于安全性考虑，大多数防火墙以及启用了防火墙功能的路由器缺省配置为不返回各种ICMP报文，其余路由器或交换机也可被管理员主动修改配置变为不返回ICMP报文。因此Traceroute程序不一定能拿全所有的沿途路由器地址。所以，当某个TTL值的数据包得不到响应时，并不能停止这一追踪过程，程序仍然会把TTL递增而发出下一个数据包。一直达到预设或用参数指定的追踪限制（maximum_hops）才结束追踪。
依据上述原理，利用了UDP数据包的Traceroute程序在数据包到达真正的目的主机时，就可能因为该主机没有提供UDP服务而简单将数据包抛弃，并不返回任何信息。为了解决这个问题，Traceroute故意使用了一个大于30000的端口号，因UDP协定规定端口号必须小于30000，所以目标主机收到数据包后唯一能做的事就是返回一个“端口不可达”的ICMP报文，于是主叫方就将端口不可达报文当作跟踪结束的标志。

除了使用UDP外，也有使用TCP代替的实现方法。

重返PacketTracer

把视线放回原本的实验环境，如何才能获得我们预期的TYPE：0x03呢？我想到了两种方法：
1）.为PC安装traceroute工具
结果发现软件中的PC是无法连接到外部网络的，无法安装相关网络工具，更无法向其发送数据
2）.寻找一个默认支持traceroute的终端设备

我翻遍了如上所有的PC类终端，要么只有CMD命令行要么就干脆啥命令行也没有。

达成目的

难道真没有办法了吗？在我冥思苦想的过程中，猛地想起了一个远在天边近在眼前的玩意：router。
于是第三种方法诞生了：使用原实验中的拓扑图，曲线救国：Router0 traceroute PC1：

如上图所示我在第4、5、6个返回的伴随着UDP的ICMP包中抓到了期望已久的（TYPE：3）。
当然，不仅是路由器，在思科的软件中我发现大部分支持CLI的设备都支持traceroute~！

参考资料

microsoft-docs、Traceroute-WIKI、某引擎、Pathping-WIKI