关于tracert的工作原理和用法

caicai

我遇到了以下问题：
1、网络环境：一台intel550交换机划分vlan，我的pc windows 2k server
ip：192.168.0.101/27,gw:192.168.0.97
另两台unix机器
sco openserver:192.168.0.112/27，gw：192.168.0.97
redhat 8.0：192.168.0.111/27，gw：192.168.0.97
代理服务器192.168.0.4/27，通过代理服务器上网   
2、我在这三台机器上分别执行tracert(windows)  和traceroute(sco，linux)目的地址202.99.8.1
结果windows下可以正常返回信息：
C:\Documents and Settings\Administrator>;tracert -d 202.99.8.1

Tracing route to 202.99.8.1 over a maximum of 30 hops

  1   <10 ms   <10 ms   <10 ms  192.168.0.97
  2     *        *        *     Request timed out.
  3    40 ms    10 ms    20 ms  61.149.32.1
  4    10 ms    20 ms    20 ms  61.148.4.21
  5    10 ms    11 ms    20 ms  202.108.46.29
  6    10 ms    10 ms    20 ms  202.106.193.149
  7    10 ms    20 ms    21 ms  202.106.192.230
  8    20 ms    20 ms    20 ms  202.96.13.46
  9    10 ms    20 ms    20 ms  202.96.6.78
10    10 ms    20 ms    20 ms  202.99.8.1

而在sco和linux下却不能够得到返回信息
# traceroute -n 202.99.8.1
traceroute to 202.99.8.1 (202.99.8.1), 30 hops max, 40 byte packets
1  192.168.0.97  20 ms  0 ms  0 ms
2  * * *
3  * *

他们之间的区别是windows用icmp包，而unix下使用UDP包，这是为什么呢？

caicai

unix系统使用udp协议应该没错的我试了几种系统都是这样

如果方便的话，你们可以用sniffer抓一下看看

我不知道是不是和我用proxy有关系

caicai

原帖由 "redwolf" 发表：
原理不假。可在到达的时候，他应该发一个ICMP应答包。。
你说的UDP端口我不解。。

   

unix系统在运行traceroute时会向目的地址发送一个目标端口非常大，通常是33400以上的，中间的router不会管这些的（即使是ICMP，因为目的地址不是自己），中间的router是看到ttl值为“0”，然后丢弃包，并向源站发送ICMP包（超时），当目的站收到包后，因为一般情况下，这么高的端口不会有程序监听的，也就是不会打开，所以就会发送另一个ICMP包（type:0x03目的不可达，code:0x03端口不可达），源站收到这个ICMP包后结束traceroute操作

caicai

原帖由 "炎舞" 发表：
1 192.168.0.97 20 ms 0 ms 0 ms

这个应该是你网关了。然后其他的packet一概进不来。
应该是你proxy的关系。

   

192.168.0.97是我的网关没错

可是包不会进不来呀，因为我在windows下可以成功执行，而不管是在什么系统下，返回包应该是一样的（icmp的ttl超时包），所以应该不是进不来

我觉得不是vlan的问题，就是proxy的问题，应该是出不去

我刚才找了一个有公网地址的机器，执行traceroute 202.99.8.1，可以返回信息
[root@]# traceroute -n 202.99.8.1
traceroute to 202.99.8.1 (202.99.8.1), 30 hops max, 38 byte packets
1  211.154.170.250  0.246 ms  0.185 ms  0.180 ms
2  211.154.160.251  0.400 ms  0.350 ms  0.417 ms
3  211.99.57.81  1.062 ms  0.605 ms  0.711 ms
4  202.96.13.1  82.941 ms  83.840 ms  85.126 ms
5  202.96.13.46  82.227 ms  83.019 ms  78.859 ms
6  202.96.6.78  83.765 ms  81.806 ms  81.296 ms
7  202.99.8.1  80.724 ms *  91.728 ms

caicai

[quote]原帖由 "redwolf"]哦。端口不假，可到达目的地的时候，应该是发送ECHO REPLY，不应该是UNREACHBLE呀。。。因为到达目的地了，他也要遵循ICMP协议。[/quote 发表：
     

unix系统下执行traceroute是用udp，发送一个目的端口大于33400，ttl值从1开始递增的数据包，中间的路由器不会管这些包是ICMP还是UDP，一样处理（丢弃，发送ttl超时），最后这个包会发送到目的主机，目的主机发现自己并没有开放相应的端口，所以会向源站发送不可达

caicai

也就是说，traceroute起始包使用ICMP，还是UDP都没有关系，中间的router和最后的目的主机会严格按照ICMP协议处理的

caicai

原帖由 "redwolf" 发表：
“最后这个包会发送到目的主机，目的主机发现自己并没有开放相应的端口，所以会向源站发送不可达”再次探讨一下，
比如它如果发目的地不可达，主机又如何判断已经到达目的地了。。
还有如果目的地发送不可达的话，..........

   

UDP和ICMP都是无连接的协议，从本地发出的数据包经过中间路由器，直到最后的直接连接目的主机所在的网络然后使用局域网协议将数据包发送到目的主机，目的主机收到数据包后底层检测是发送给自己的就会将数据包送给高层协议去处理，但发现目的UDP端口并没有开放（也就是没有服务程序监听该端口），就会像源站点发送端口不可达的ICMP包。不可达是icmp的type，他的code又分好几种，端口不可达就是其中一种，还有主机不可达，网络不可达。

caicai

我们是通过代理服务器上网的，我想如果是路由器，应该不会存在问题。
我现在不明白的是，同样在内网的一个网段内，为什么windows下执行tracert就可以，而在unix下，就只有我的交换机返回一条信息。

   windows和unix的区别是：windows使用ICMP包，UNIX使用UDP包