traceroute不通linux,能ping通traceroute不通

问题现象：

Linux下可以ping通IP，但是traceroute不通

问题原因：

traceroute路由跟踪是利用IP数据包的TTL值来实现的，Linux 下 traceroute 首先发出 TTL = 1 的UDP 数据包，第一个路由器将 TTL 减 1 得 0 后就不再继续转发此数据包，而是返回一个 ICMP 超时报文，traceroute 从超时报文中即可提取出数据包所经过的第一个网关的 IP 地址。然后又发送了一个 TTL = 2 的 UDP 数据包，由此可获得第二个网关的 IP 地址。依次递增 TTL 便获得了沿途所有网关的 IP 地址。

因为UDP 常被用来做网络攻击，因为 UDP 无需连接，因而没有任何状态约束它，比较方便攻击者伪造源 IP、伪造目的端口发送任意多的 UDP 包，长度自定义。所以运营商为安全考虑，对于 UDP 端口常常采用白名单 ACL，就是只有 ACL 允许的端口才可以通过，没有明确允许的则统统丢弃。比如允许 DNS/DHCP/SNMP 等

注意：

Linux下traceroute程序默认发送的探测包为UDP协议，windows下tracert、mtr，以及Linux下mtr默认都发送的是icmp的数据包，并不是所有网关都会如实返回 ICMP 超时报文。处于安全性考虑，大多数防火墙以及启用了防火墙功能的路由器缺省配置为不返回各种 ICMP 报文，其余路由器或交换机也可能被管理员主动修改配置变为不返回 ICMP 报文。因此 Traceroute 程序不一定能拿到所有的沿途网关地址。所以，当某个 TTL 值的数据包得不到响应时，并不能停止这一追踪过程，程序仍然会把 TTL 递增而发出下一个数据包。这个过程将一直持续到数据包发送到目标主机，或者达到默认或用参数指定的追踪限制(maximum_hops 默认最大为30)才结束追踪

验证：

Linux 下 traceroute 114.114.114.114

如图，以第一跳和第五跳为例，对比抓包可以看出，第一组(每次发三个包)UDP 的 request 数据包 TTL 值为1，在到达第1个路由节点后，TTL减1后为0，则不继续传递，返回一个 ICMP 超时报文，这时客户端获取到了第1个路由节点IP，与traceroute测试信息相符

第五跳时，发送的 request 数据包 TTL 值为5，在到达第5个路由节点后，TTL减为0，则不继续传递，返回一个 ICMP 超时报文，这时客户端获取到了第5个路由节点IP，与traceroute测试信息相符

总结：

Linux 下 traceroute 默认发送的时 udp 协议 request 包，很多路由节点上会丢弃该部分数据包不做响应；windows 下 tracert、mtr 以及 Linux 下 mtr 默认发送的是是 icmp 协议 request 包，测试网络时更有参考价值

Linux 下 traceroute、mtr 都支持指定协议端口进行网络探测，建议使用 icmp 或 tcp 协议进行网络探测

traceroute 常用参数：

-I --icmp //指定ICMP协议

-T --tcp //指定TCP协议

-p port --port=port //指定端口

mtr 常用参数：

-c //指定发包次数

--tcp //指定tcp协议

--port=PORT //指定端口

--udp //指定udp协议