tracert和traceroute的区别

最近用到跟踪路由来排查问题,发现Windows下跟centos进行路由跟踪有些许区别,也是偶然才发现。

Windows下的tracert用的ICMP协议,centos用的UDP协议,若跟踪路由过程中,若防火墙禁止ICMP或者UDP协议,则路由跟踪会失败。

所以为何在Windows下所跟踪的路由与centos下不同,就是由于所用的协议不同,中转途中的设备对此两种协议支持的程度不同。

还发现了centos 5.x下会有tracert和traceroute这两个命令,其实tracert是traceroute的软链接,可能是为了让使用惯Windows的人更加适应吧。在6.x版本中tracert此命令就没有了。
而且在linux下traceroute加上参数-I,就会以ICMP协议进行路由跟踪,就跟Windows的tracert一样了。

 

参考:

http://www.5iadmin.com/post/913.html本文来源于网管小王的博客

在日常的网络探测和故障诊断中,常用到的两个工具是Ping和Tracert。随着网络结构的日益复杂和中间设备(包括但不仅限于路由器和防火墙)的广泛部署,以及为了实现安全要求而在路由器和防火墙上实施了严格的访问控制策略后,网络管理和维护人员想要正常使用Ping/Tracert对网络进行主动有效的探测和故障诊断往往受阻,甚至无法进行。Windows环境下的Ping/Tracert工具都是基于ICMP协议实现的,而在Linux或Cisco等网络设备中,Traceroute还使用了UDP协议,在此不做深入讨论。
确实,在网络中部署了路由器和防火墙后,如果不经过慎重规划和部署,就以“保障网络安全”为由,在实施访问控制策略时,过滤掉ICMP协议流,将给日后正常的网络探测和故障诊断带来极大的困难。ICMP协议数据包的类型多样,有些类型的数据包确实会给网络带来安全威胁,但只要正确部署和配置路由器及防火墙的安全策略,在允许必要的ICMP类型数据包的同时过滤特定的ICMP类型数据包,则既能够使得Ping/Tracert工具正常工作,给网络维护和故障诊断带来便利,又能有效保证网络和设备的安全运行。
在网络中部署了路由器和防火墙后,要使得Ping/Tracert正常应用,需要从两个方面进行考虑:第一,过境设备的Ping/Tracert数据流,需要路由器和防火墙放行;第二,到设备自身或接口的Ping/Tracert数据流,需要路由器和防火墙响应。笔者以Cisco设备为例,来说明如何配置路由器和防火墙的策略,允许必要的包括回显(echo)、回显应答(echo reply)、超时(time exceeded)和目标不可到达(unreachables)等四种类型的ICMP数据包,以保障Ping/Tracert命令的正常使用。
在Cisco路由器中,利用NAT结合ACL实现访问控制时,一般允许从内部接口的到外部接口的所有流量,包括ICMP。所以,需要在路由器的外部应用ACL,为允许必要的ICMP数据包进入网络,ACL中必须包含以下的允许规则:
Access-list 101 permit icmp any any echo
Access-list 101 permit icmp any any unreachable
Access-list 101 permit icmp any any time-exceeded
Access-list 101 permit icmp any any echo-reply
如果在路由器中实现了基于区域的IOS防火墙功能,此时可以把路由器当状态防火墙对待,建议对ICMP流量实施应用审查,则配置更为简单明了。另外,对于从外部或内部到自身接口的需要允许的ICMP流量,也通过防火墙策略(而不是ACL)配置实现即可,在此不列出具体命令了。还有一点要注意的是,作为一种防御DoS攻击的保护措施,默认情况下,路由器将ICMP 不可到达类型的流量限制到每500毫秒一个数据包。在12.1及更新的IOS镜像中,这个速率限制可通过命令”ip icmp rate-limit unreachable”进行配置。
对于一般的状态化防火墙, 只要策略允许从内到外的所有流量,或对ICMP协议实施了应用审查,Ping/Tracert就能够正常运转,无需额外的策略配置。但是从外到内的Ping/Tracert则需要配置策略以放行流量。在PIX/ASA防火墙中,默认情况下,从外向内的ICMP流量被禁止,从内向外的ICMP流量允许通过,但返回包却被禁止。要改变这一默认行为,需要配置例外的允许策略以放行必要的ICMP类型数据包。此外,可通过命令”icmp unreachable rate-limit n burst-size n ”对ICMP不可到达类型的流量进行必要限制,还可以在防火墙上启用针对ICMP的防DoS功能。要允许穿越防火墙的特定的ICMP流量,配置命令如下:
Object-group icmp-type Permit-ICMPType
Icmp-object echo
Icmp-object unreachable
Imcp-object time-exceeded
Icmp-object echo-reply
Access-list inbound permit icmp any any object-group Permit-ICMPType
access-group inbound in interface outside
允许到防火墙自身接口特定的ICMP类型流量,在则命名接口上的配置命令为:
icmp permit 0.0.0.0 0.0.0.0 echo
icmp permit 0.0.0.0 0.0.0.0 echo-reply
icmp permit 0.0.0.0 0.0.0.0 unreachable
icmp permit 0.0.0.0 0.0.0.0 time-exceeded
icmp deny 0.0.0.0 0.0.0.0 
在实际的网络环境中,如果路由器或防火墙丢弃了ICMP超时数据包,那么Tracert会对该跃点显示一系列“*”字符。如果在近侧接口(靠近发起Tracert流的计算机端)上实施了ICMP过滤,那么该路由器或防火墙及其后续的设备上都会显示“*”字符直到完成30个(默认)跃点数尝试。如果Ping/Tracert工具工作正常,那么相应地另一工具即pathping也能正常工作。此外,Ping/Tracert目的为启用了Windows防火墙的主机,需关闭Windows防火墙或进行设置以使得其允许传入的特定类型的ICMP流量。

 

转自http://ewangsoft.blog.163.com/

tracert与traceroute的差别

windows下的tracert和linux/BSD/router下的traceroute都用于探测数据包从源到目的经过路由的IP,但两者探测的方法却有差别。

默认情况下,tracert是向目的地址发出ICMP请求回显数据包,而traceroute是向目的地址的某个端口(大于30000)发送UDP数据报。两者用于探测的数据类型不同。但他们也有一个共同点:都是通过设置发送包的TTL的值从1开始、逐次增1的方法来探测(此方法在“验分析Traceroute程序的工作过程 ”一文中已经详细说明)。

由于一个是向目标发送ICMP,一个是向目标发送UDP(traceroute可以通过使用参数“-I “来改变发送的数据包为ICMP)。那么当通信途中有防火墙阻止ICMP或UDP通过时,探测过程就不能完成。实验验证如下:

拓扑图:

trace1

实验验证过程:

一、验证traceroute当遇到阻止UDP数据通过时,探测结束

1、PC1(LINUX或BSD或用路由器代替)、R0、R1、Firewall、PC2均配置好网关或路由,保证PC1能与PC2正常通信。

2、在Firewall中不添加任何规则的情况下,在PC1中运行traceroute 172.16.0.11,结果如下:

trace2

在PC1与R0之间抓包结果如下:

trace3

从上图可以看到traceroute发送的探测数据使用的是UDP。

3、在Firewall中添加访问控制,禁止所有的UDP数据通过F0/1进入。firewall可以简单的使用路由器启用ACL代替,ACL编号为111,内容为:

    deny udp any host 172.16.0.11
    permit ip any any

然后在firewall的F0/1接口中使用下述命令启用规则:

ip access-group 111 in

4、在PC1上traceroute 172.16.0.11,由于firewall中添加了阻止UDP通过,探测过程将终止于firewall。结果如下图:

trace4

由于firewall阻止UDP通过,因此探测过程将结束。

二、验证tracert遇到ICMP请求回显阻止时,探测过程将结束

1、PC1使用WINDOWS系统

2、firewall上不使用任何限制规则时,PC1 tracert 172.16.0.11,结果如下图示:

trace5

在PC1和R0间抓包结果如下:

 trace6

从上图中可以看出tracert使用的是ICMP回显请求方式探测。

3、在firewall的F0/1接口中启用禁止到172.16.0.11的ICMP回显请求的访问列表:

deny icmp any host 172.16.0.11

4、在PC1上tracert 172.16.0.11,由于firewall上禁止ICMP通过,因此探测过程将终止于此。运行结果如下图示:

trace7

验证试验完成。