虚拟机NAT之traceroute（VMWare的NAT模式下无法使用traceroute）

在kali下traceroute发现和windows下得到的结果不一样，但是记得之前用kali虚拟机也不会出现这种情况，遂打开wireshark抓包。

我traceroute的对象是baidu.com,可以看到，首先kali通过DNS协议去请求了百度的ip地址，然后向虚拟机网关发送探测包，只有网关的包正常的回应了，而这其他探测包无一例外的没有收到回应，就是上图的一堆星星。

 又在windows上tracert了baidu.com发现结果是完全不一样的

 发现windows下走的协议和linux完全不同，linux是清一色的udp协议，而windows是利用ICMP及IP header的TTL（Time To Live）栏位（field）来确定。

 

 这位师傅写的很清楚，traceroute和tracert的区别

而那些星星是没有回应的包。

问了学校老师，好多网络设备会直接忽略udp包，因为udp没带状态，溯源很难。。（懂得都懂吧。。。）

但是同时她指出来，我遇到的问题可能是vmware的虚拟网卡NAT路由导致的，于是又试了一下桥接，因为桥接不走NAT，在网络中拓补位置和host是对等的位置。

于是测试桥接模式 

完全正常，和windows的结果基本一致

而wireshark抓的包依然清一色udp，但也是和icmp交错的 ，这个icmp好像就是生存期到了，对应网络设备发回来的，windows上也是如此

第二天忽然想明白了，从流量包中可以看出，无论是traceroute还是tracert都是基于TTL经过每一个路由设备会减一的原理，然而当TTL=0时，host是不会感知的，所以就需要TTL=0时到达那个设备向host发送一个TTL=0的消息，这个时候主机收到，并且确认时间和此时存在路由设备，但是问题就在于这个数据的获取来源于路由设备的返回包。

我们知道，NAT是有网段隔离的，也就是说外部主机是无法直接进入的（位于物理机的vmware NAT路由会阻断这个数据包到达host，从而达到网络隔离保护的目的），换个说法，看最后那张图，可以发现返回的包走的ICMP协议，也就是ping回来的那个协议，所以，由于NAT的原因，外部是ping不进主机的，所以才会出现遇到的这个问题

 全剧终。。。