Azure虚拟机中使用Tracert/Traceroute/MTR(My Traceroute)的原理讨论

命令：mtrXXX.XXX.XXX.XXX

效果：

 

如果加上-n参数可以显示IP而不是反向解析成域名：

例如mtr -nXXX.XXX.XXX.XXX

 

mtr的工作原理：

利用IP报文头部的TTL值来进行探测

 

我们以目标IP为106.120.78.190为例：

抓包见附件，我们看到如下的交互过程：

前4个报文展开来看：

第一个：

第二个：

第三个第四个的TTL分别为3和4。

 

即向目的端依次发TTL=1，TTL=2，TTL=3…的ICMP报文，当TTL=1时，到达第一个路由之后，就直接返回了，如果该路由没有任何返回结果，则在mtr界面上就显示为???，这也是为什么我们的结果中前4跳都显示为???，应该是对应的azure设备。

 

接着，在TTL=5的报文发出后，我们收到了103.9.8.18返回的TimeExceeded Message，即这一跳的设备返回TTL过期的错误给我们，所以也就知道了这一跳的IP地址以及可达性。

依次类推，继续发送TTL+1的ICMP报文，直到真正我们mtr的目的IP返回了一个ICMP响应报文：

然后再重新开始TTL=1的新一轮探测。

上面实验的前提是为虚拟机指定了PIP，这样回显的ICMPTime Exceeded Message才能够到达主机从而知道每一跳的地址。

 

在Azure虚拟机中做了一下tracert，发现原理和mtr相同，配置PIP后同样可以显示出结果：

同时，从抓包也可以看出，tracert计算延迟时间是通过发送ICMP报文与收到Time Exceeded Message的时间差来计算的，例如：

看到第6跳，两次超时加一次32ms，从抓包来看，前两次没有收到Time Exceeded Message：

 

最后，又在虚拟机配置PIP的情况下使用traceroute进行了实验，发现traceroute的原理是发送UDP报文（也可以使用-I参数指定使用ICMP报文），同样利用TTL递增的原理，同样可以收到Time Exceeded Message的ICMP报文，但是却没有显示任何结果，原因是尽管收到了Time Exceeded Message，但是traceroute并不像mtr一样会对响应时间和丢包率进行统计，或者像tracert一样利用Time Exceeded Message的返回时间进行计算，因此当3次Time ExceededMessage收到后，traceroute就判断这个node不可达，所以在结果中就只能看到全是*的情况。

当指定-I参数时，traceroute会使用ICMP报文进行探测而非UDP，因此当到达实际要探测的目的端IP时，目的端IP会返回Echo Reply Message：

此时，能够看出中间经过的跳数（但是每一跳的IP不会回显），以及到这个目的端IP的延迟：

而使用UDP的时候，没有ICMP的Echo Reply Message，所以探测会一直持续下去没有任何结果（知道达到最大跳数30）：