计算机网络抓包实验报告

第三次课堂实践报告高国栋 20同实验者 韦纯 韦方宇 王尊严一、实践内容1 1. 两台PC通过交换机或网线互相ping通。2. 抓取1个ARP请求报文和1个ARP响应报文。3. 抓取1个ICMP ECHO报文和1个ICMP ECHO REPLY报文。Ping通目标主机 50（对方也ping通00）在ping命令时抓取的arp与icmp数据包 分别选择其中的任意一个ARP请求报文、ARP响应报文、ICMP ECHO报文、ICMP ECHO REPLY报文，并打开其数据包。4. 要求: (1) 列出上述报文对应MAC帧原始数据，附上对应截图。对应的帧原始数据为框中的内容：ARP请求报文：ARP响应报文：IMP ECHO 报文ICMP ECHO REPLY报文：(2) 找出上述报文对应MAC帧的源MAC地址、目的MAC地址、类型、数据长度，附上与原始数据的对应图。ARP请求报文ARP响应报文IMP ECHO 报文ICMP ECHO REPLY报文(3) 找出ICMP ECHO和ECHO REPLAY报文的首部长度、总长度、生存时间、协议、首部校验和、源IP地址、目的IP地址，计算单次成功ping的时间，附上与原始数据的对应图。ICMP ECHO报文数据包如下：可看到时间标记为10：28：06.ECHO REPLAY报文：时间标记为10：28：06.单次成功ping的时间=10：28：06.-10：28：06.=0.s所以单次成功ping的时间0.00257秒(4) 找出ARP请求报文希望获得的MAC地址及其对应的IP地址，附上对应截图。从图中可以知道ARP请求报文希望获得的MAC地址为50:7B:9D:07:D0:B2。它对应的IP地址为：00。 因为此时是IP地址为50在ping 00，所以是50给00发送ARP请求报文，所以捕获到的目的IP地址为00。(5) 举例说明MAC帧、IP包、ICMP报文的关系。用我们抓取的ICMP Echo报文举例说明：ICMP报文20字节IP包60字节MAC报文78字节从第0字节到第77字节是一个完整的MAC帧，总长度78字节。去掉MAC帧的首部（第0到13个字节）和尾部（FCS共4字节），保留的从第14字节到第73字节是一个完整的IP包。再去掉IP包首部（第14到33字节），保留的为ICMP报文，即MAC帧包含IP包，IP包包含ICMP报文。二、实践内容21.PC机的默认网关配置为192.168.0.x, x在250-254之间。配置默认网关为51，如图所示：2. 两台PC通过交换机或网线互相ping通。注：ping命令不带-t参数。3.先执行arp d命令，开始抓包，然后执行ping 55命令。请根据抓包结果分析此ping命令执行过程中数据报文的传输情况，并附上相应截图。 在进行这一步实验时，我们组发现如果是两台电脑用网线相连，无论是哪台电脑执行ping 55命令，都会请求超时。而当我们用交换机将全部4台电脑（IP地址分别为00，50，7，8）连在一起时，再执行ping 55命令，IP地址为50，7，8的三台主机均会有如下显示，而00的主机执行ping 55命令后依然为请求超时。50执行ping 55命令后结果之后我们抓取ARP与ICMP报文进行分析，IP地址为.0.150的主机抓取的报文如下（只截取了一部分）： 将抓包结果与之前ping结果对照，可以发现每执行一次ping命令，会收到4次来自00的回复，从抓包结果中可以将每次回复的过程找出来如下所示： 从中可以看出MAC地址为80:62:66:E4:E5:12的主机先向以太网广播发送了一条APR 请求报文，之后IP地址50向以太网广播的IP地址55发送了一条ICMP Echo报文，由IP地址为00的主机向50回复了一条ICMP Echo Reply报文；之后MAC地址为50:7B:9D:07:D0:B2主机连续向02:32:63:44:E5:12发送了5次ARP相应报文。 按常规来说如果主机都通过交换机连接，那么如果一个主机执行ping 55命令，那么他应该收到来自所有其它主机的回复，而在我们组的实验中只能收到同一主机（00）的回复，收不到其他两台主机的回复。这个问题可能是由于我们另外三台主机的默认网关配置的一样，而与另一台不一样，在执行ping 55命令时会无视同为51相同默认网关的另外两台主机，只能收到默认网关为50的主机的回复。还有一种可能性是交换机接口的配置不同，导致ping 55命令时的结果不同。因为时间原因，我们组也没有对这个问题进行进一步探讨。4.先执行arp d命令，开始抓包，然后执行ping 6命令。请根据抓包结果分析此ping命令执行过程中数据报文的传输情况，并附上相应截图。我们四台主机连在交换机上执行ping6命令均请求超时。所以可知此连接不通。5. 主机A、B、C共同连在交换机上，主机C配置为主机A的网关。主机A ping B，B抓取ARP Response 报文，ping通后主机A执行arp a。然后，主机B利用抓包工具软件修改抓取的ARP Response报文，仅修改ARP Response报文中B的MAC地址（注：不是MAC帧首部的B的MAC地址），修改后发送（发送10次以上），在主机A上再执行arp a。对比两次的arp a的结果，分析原因，附上相应截图。B继续持续发送修改后的ARP Response报文，在主机A上ping B，记录ping的情况，附上截图，并分析原因。 因为我们组没有交换机，所以整个实验是两台电脑用网线连接做的。第一次Aping B的结果：A执行arp a的结果：从图中可看到B的IP地址为50，MAC地址为50-7B-9D-07-D0-B2。此时B抓取ARP Response 报文：修改抓取的ARP Response报文，仅修改ARP Response报文中B的MAC地址。所以选择第14个数据包进行修改，将其设置为要发送的数据包，在工具栏中点击“编辑要发送的数据包”，把B的MAC地址改为52-22-22-22-22-22如下图：连续不断点击发送按钮，在主机A上再执行arp a，结果如下：从途中可以看出IP地址50对应的MAC地址变为了52-22-22-22-22-22，即为修改后的值，再在主机A上ping B，结果如下：会看到主机A已经ping不通B（50）了，这是因为B将修改后的ARP响应报文发送给A后，主机A中默认的B的MAC地址发生了改变，执行ping50时，默认的50对应的MAC地址修改为52-22-22-22-22-22，而本身50对应的MAC地址为修改之前（50-7B-9D-07-D0-B2）的值，所以当然不会ping通。三、实践内容3访问因特网上的web站点，抓取TCP连接的三次握手和四次挥手过程，附上相应截图，并分析三次握手和四次握手的详细过程，包括源、目的IP，源、目的端口号，序号和确认序号的变化情况，标志位SYN、FIN和ACK的值等。关闭无用软件后，用电脑访问，同时用omnipeek软件抓取TCP数据包。从中可以找到TCP连接的三次握手和四次挥手过程。找到三次握手的数据包如下：四次握手的数据包如下： 现进行具体分析。1.第一次握手数据包内容如下：第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认。客户端向服务器发送连接请求包，标志位SYN（同步序号）置为1，序号为X=。从数据包中可以看到：源IP地址：8目的IP地址：1源端口号：51835目的端口号：8089序号： 确认序号：0标志位： SYN=1 ASK=0 FIN=02.第二次握手数据包内容如下：服务器收到客户端发过来报文，由SYN=1知道客户端要求建立联机。向客户端发送一个SYN和ACK都置为1的TCP报文，设置初始序号Y=0，将确认序号设置为客户的序列号加1，即X+1 。从数据包中可以看到：源IP地址：1目的IP地址：8源端口号：8089目的端口号：51835序号：确认序号： 为第一次握手的序号+1标志位： SYN=1 ASK=1 FIN=03.第三次握手数据包内容如下：客户端收到服务器发来的包后检查确认序号是否正确，即第一次发送的序号加1（X+1=1）。以及标志位ACK是否为1。若正确，服务器再次发送确认包，ACK标志位为1，SYN标志位为0。确认序号=Y+1=0+1=1，发送序号为X+1=1。客户端收到后确认序号值与ACK=1则连接建立成功，可以传送数据了。从数据包中可以看到：源IP地址：8目的IP地址：1源端口号：51835目的端口号：8089序号： 为第一次握手的序号+1 确认序号： 为第二次握手的序号+1标志位： SYN=0 ASK=1 FIN=0 所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，TCP在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。4.第一次挥手数据包内容如下：客户端给服务器发送TCP包，用来关闭客户端到服务器的数据传送。将标志位FIN和ACK置为1，序号为X，确认序号为Z。从数据包中可以看到：源IP地址：1目的IP地址：8源端口号：8089目的端口号：51835序号：确认序号： 标志位： SYN=0 ASK=1 FIN=15.第二次挥手服务器收到FIN后，发回一个ACK(标志位ACK=1),确认序号为收到的序号加1，序号为收到的确认序号=Z。从数据包中可以看到：源IP地址：8目的IP地址：1源端口号：51835目的端口号：8089序号： 为第一次挥手的确认序号确认序号： 为第一次挥手的序号+1标志位： SYN=0 ASK=1 FIN=06.第三次挥手数据包内容如下：服务器关闭与客户端的连接，发送一个FIN。标志位FIN和ACK置为1，序号为Y，确认序号为X=2。从数据包中可以看到：源IP地址：8目的IP地址：1源端口号：51835目的端口号：8089序号： 为第一次挥手的确认序号确认序号： 为第一次挥手的序号+1标志位： SYN=0 ASK=1 FIN=17.第四次挥手数据包内容如下：客户端收到服务器发送的FIN之后，发回ACK确认(标志位ACK=1),确认序号为收到的序号加1，序号为收到的确认序号X=2。从数据包中可以看到：源IP地址：1目的IP地址：8源端口号：8089目的端口号：51835序号： 为第一次挥手序号+1确认序号： 为第一次挥手确认序号+1标志位： SYN=0 ASK=1 FIN=0由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。（3） 服务器关闭客户端的连接，发送一个FIN给客户端。（4） 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。 在实验中，我发现在四次挥手时客户端与服务端反了，这与我们在课堂上学到的结论不符，经过几次重复试验后，我们发现无论如何找到的三次握手与四次挥手的客户端与服务端都是反的，但其他的标志位的变化及序号与确认序号的变化都是正确的，所以我们猜测是在访问后目标网页对客户端与服务端进行了调换，或者是目标网址先执行了