探索计算机网络ICMP协议
本文通过wireshark抓包ICMP报文进行ICMP协议的探索,将探索一下几个方面:
- Ping程序产生的ICMP消息。
- 由Traceroute程序产生的ICMP消息。
- ICMP消息的格式和内容。
1.ICMP和Ping
Ping程序是一个简单的工具,允许任何人(例如,网络管理员)验证一个主机是否是活的。源主机中的Ping程序向目标IP地址发送一个数据包;如果目标是活的,目标主机中的Ping程序就会向源主机发送一个数据包作为回应。而这些数据包都是ICMP数据包。
做到以下几点。
- 打开Windows命令提示程序。
- 启动Wireshark,并开始Wireshark数据包捕获。
- 在dos命令行中输入“ping -n 10 hostname ”,为了定位另一个大陆上的服务器,我们尝试输入“www.mit.edu”(麻省理工的网络服务器)。参数"-n 10 "表示应发送10条Ping信息。然后通过输入回车键运行Ping程序,发现根本获取不到ICMP数据包。(作者也不知道原因…)
那咱们试一试国内的,输入香港的“ping -n 10 www.ust.hk”来尽心捕获,记得在ping之前要先打开wireshark。 - 当Ping程序终止时,停止Wireshark中的数据包捕获
此时就拿到了数据包。如下:
此时在Wireshark中进行icmp的筛选,得到icmp的请求包:
我们发送了10次请求,这里有20个icmp数据包,可以发现每个都是request和reply,验证了icmp“回声式”的数据传输模式。
问题:
1.你的主机的IP地址是什么?目的地主机的IP地址是什么?
我们查看第一个request请求:
在第一个发送的数据包中发现Src:10.118.125.72 Dst:143.89.12.134。而本次为第一次request请求,所以我的主机IP为10.118.125.72, 目的IP为:143.89.12.134。(如果不确定可以在控制台中输入ipconfig看一下)eazy。
2.为什么ICMP数据包没有源和目的端口号?
因为 ICMP 报文作为 IP 有效载荷承载的,是一种差错和控制报文协议,不需要像 TCP 或 UDP 那样需要端口号。
3.检查由你的主机发送的一个ping请求包。ICMP的类型和代码是什么?这个ICMP数据包还有哪些字段?校验和、序列号和标识符字段有多少个字节?
查看一个request请求包,类型是8,代码是0。
其中还有校验和、标识符、序列号和数据data。其中校验和、标识符和序列号都是4个字节。
4.检查相应的PING回复数据包。ICMP的类型和代码是什么?这个ICMP数据包还有哪些字段?校验和、序列号和标识符字段有多少个字节?
类型是0,代码是0。与请求包一样包含校验和、标识符、序列号和数据,除数据外都是4个字节。
2.ICMP和Traceroute
现在让我们继续ICMP冒险,捕捉Traceroute程序产生的数据包。Traceroute程序可以用来找出数据包从源头到目的地的路径。Traceroute在Unix/Linux/MacOS和Windows中以不同的方式实现。在Unix/Linux中,源程序使用一个不可能的目标端口号向目标目的地发送一系列UDP数据包;在Windows中,源程序向目标目的地发送一系列ICMP数据包。对于这两个操作系统,程序发送的第一个数据包的TTL=1,第二个数据包的TTL=2,以此类推。回顾一下,当数据包通过路由器时,路由器会递减数据包的TTL值。当一个数据包以TTL=1到达路由器时,路由器会向源头发送一个ICMP错误数据包。在下文中,我们将使用本地Windows的tracert程序。
做到以下几点。
- 打开Windows命令提示程序。
- 启动Wireshark,并开始Wireshark数据包捕获。
- tracert命令在c:\windows\system32中,所以在MS-DOS命令行中输入 "tracert hostname "就可以执行,其中hostname是另一个大陆的主机。(注意,在Windows机器上,该命令是 "tracert "而不是 “traceroute”)。输入INRIA的网络服务器www.inria.fr,这是法国的一个计算机科学研究所。然后通过输入回车键运行Traceroute程序。
- 当Ping程序终止时,停止Wireshark中的数据。
得到的Wireshark中的数据包如下:
问题:
5.你的主机的IP地址是什么?目的地主机的IP地址是什么?
从任意一个发送的数据包中发现,Src:10.118.125.72 Dst:128.93.162.83。
6.如果ICMP发送UDP数据包,而不是像Unix/Linux那样,探测数据包的IP协议号还是01吗?如果不是,会是什么?
待解决。(还请各位大佬指导)
7.检查你截图中的ICMP回波数据包。这与本实验前半部分的ICMP ping查询数据包是否不同?如果是,是怎样的?
肯定是不同了,查看发现这里的报文类型变为了11,而前面我们知道ping时的报文类型是0。
8.检查你截图中的ICMP错误数据包。它比ICMP回波数据包有更多的字段。这些字段中包括什么?
多了这一部分,其中包含了ICMP 请求数据包的内容(包括总长度、标识符、TTL等)。
9.检查源主机收到的最后三个ICMP数据包。这些数据包与ICMP错误数据包有什么不同?为什么它们会不同?
我们找到最后的三个reply包:
查看包中的报文的类型:
发现最后的三个reply数据包中的Type都是0,即这三个都是目的IP返回的回显应答报文,查阅资料发现tracert 程序的原理是发送 TTL 增加的数据包,当 TTL = 1 的包达到路由器,该路由器会将该包丢弃,并且发送 ICMP 错误给请求的机器。而最后一组 3 个数据报时可以到达目的主机的,这时由于是被目的主机接收,目的主机不会丢包,而是确确实实收到的这个探测的数据报并进行了响应,所以会有这三个回显应答报文。
10.在tracert测量中,是否有一条链路的延迟明显长于其他链路?参考图4中的截图,是否有一条链路的延迟明显变长了?根据路由器的名称,你能猜到这个链接末端的两个路由器的位置吗?
确实,我们发现在15处延迟突变成为了155ms,路由器的名称也变为英文的,后面的全都变成了155ms+,所以推测应该是到达了中国到欧洲的路由器连接点了。
利用 Best trace进行追踪,发现确实是在这个节点出现了从北京到德国的7777km(小小致敬一下Clearlove)的大跳跃。
但其实利用Best trace可以更好的理解icmp的传递过程,还是挺好玩的。