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

全栈程序员-用户IM • 2022年6月16日上午10:46 • 未分类

大家好，又见面了，我是你们的朋友全栈君。

命令：mtrXXX.XXX.XXX.XXX

效果：

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

例如mtr -nXXX.XXX.XXX.XXX

Machine generated alternative text:[ve .75] Dancentos65 Keys: Help 4. 777 19.9 35 1.4 29 13.8 13.8 79.1* 196 .129 .78 .199 2.4 3.4 (G.G.G.G) Display mode Resta rt statistics Orde r fields my quit t race route sun Jan 19 2916 Packets Loss* Snt Host 777 777 777 . 193.9.8.2G . 189 .149.129.157 . 229 .181 . 219.142.1.157 . 219.141.139.154 19. Las t Pings Avg Best 1.7 Wrst StDev 9.2

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后同样可以显示出结果：

Machine generated alternative text:www.baidu.com racing route to www.a.shifen.com [220.181 .111.188] uer a maximum OF 30 hops: 220.181.1?.150 30 ms 220.181.111.188 Request timed Request timed Request timed Request timed 42.159.128.80 25 26 Request Request Request Request t imed t imed t imed out. out. out. out. out. out. out. race 26 ms 30 ms complete . timed out.

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

Machine generated alternative text:www.baidu.com racing route to www.a.shifen.com [220.181 .112.244] uer a maximum OF 30 hops: 180.149.129.15? 220.181.112.244 Request timed out. Request timed out. Request timed out. Request timed out. 42.159.128.80 Request timed out. Request timed out. 220.181.1?.22 Request timed out. race 30 ms 30 ms complete . 30 ms 30 ms 32 35

看到第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：

Machine generated alternative text:2016/1/10 14.4076570 106.120.78.190 2016/1/10 14.4076620 106.120.78.190 2016/1/10 14.4076660 106.120.78.190 192.168 0 192.168.0.4 192.168.0.4 ICMP ICMP ICMP :Echo Reply Message, ICMP:Echo Reply Message, ICMP:Echo Reply Message, From 106.120.78.190 To 192.168.0.4 From 106.120.781190 To 192.168.0.4 From 106.120.781190 To 192.168.0.4

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

Machine generated alternative text:[ root@anCentOS65 trace route to 196 4 7 trace route .129 .78.199 -1 -n 196.129.78.199 (196.129.78.199), 39 hops max, 69 byte packets 196.129.78.199 2.992 ms 2.894 ms 2.876 ms

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

Machine generated alternative text:[ root@Dancentos65 trace route to 196 4 11 12 13 14 15 16 17 18 19 29 21 22 23 24 25 26 27 28 29 39 trace route 196.129.78.199 .129.78.199 (196.129.78.199), 39 hops max, 69 byte packets