在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不进主机的,所以才会出现遇到的这个问题
全剧终。。。