网络界的AK-47，一梭子打过去，让数据无所遁形！

    如果你没有听说过wireshark，说明你还不懂网络。

   由一个问题引起的思索

    一、问题：两台服务器A和B的网络配置如下，B的子网掩码本应该是255.255.255.0，被不小心配成了255.255.255.224。它们还能正常通信吗？

    服务器A：                                                      

       

    服务器B：

   

  二、你可能会想到的答案

  答案1：“A和B不能通信，因为------如果这样都行的话，子网掩码还有什么用？”（这位的反证法听上去很有道理！）

  答案2：“A和B能通信，因为它们可以通过ARP广播获得对方的MAC地址。”（那子网掩码还有什么用？楼下的反证法用来反驳这位正好。）

  答案3：“A和B能通信，但所有包都要通过默认网关192.168.1.254转发。”（请问这么复杂的结果你是怎么想到的？）

  答案4：“A和B不能通信，因为ARP不能跨越子网。”（这个答案听上去像是经过认真思考的）

   三、答案只有一个（借用柯南的名言'真相只有一个'）

   1、从http://www.wireshark.org/download.html免费下载安装包，并在服务器B上装好（把所有可选项都装上）。

   2、启动Wireshark软件，点击需要抓取数据包的网卡。

   

   3、在服务器B上Ping A的IP地址，结果是通的。

   

   4、收集每台设备的MAC地址

   服务器A：54:E1:AD:CD:3F:55

   服务器B：18:03:73:6D:FB:8B

   网关：38:83:45:72:bd:10

   5、分析相关数据包

   

   第1列是包的序号，前27号包在按下Capture键后，在ping包发起前就已经完成了交互。

   第28列。

   可以看到服务器B通过ARP广播查询默认网关192.168.1.254的MAC地址。为什么我ping的是服务器A的IP，B却去查默认网关的MAC地址呢？这是因为B根据自己的子网掩码，计算出A属于不同子网，跨子网通信需要默认网关的转发。崦要和默认网关通信，就需要获得其MAC地址。

   第29列。

   

     默认网关192.168.1.254向B回复了自己的MAC地址。为什么这个MAC地址开头明明是“38:83:45”，而Wireshark上显示出来却是以“Tp-Link”开头的字符呢？这是因为MAC地址的前3个字节表示厂商，而38:83:45被分配了TP-Link公司。这是全球统一的标准，所以WireShark干脆直接显示出厂商名了。

   下面的“Dell_6d:fb:8b”同理。

   第30列。

   

    B发出ping的request包，指定Destination IP为A，即192.168.1.1。但Destination MAC却是默认网关的38:83:45:72:bd:10。表明B希望网关把包转发给A。

  第31列。

  

   A发出ping的replye包。这是因为在A看来，B属于相同子网，相同子网通信无需默认网关参与，只要通过ARP获得对方的MAC地址就行。这个包也表明默认网关成功地把B发出的ping请求转发给了A，否则A不会回应ping的request包。

  从该数据包的源MAC地址54:E1:AD:CD:3F:55可以看出，这个包是A直接发送过来的，而不是通过默认网关的转发。

  答案：B先把Ping包请求交给默认网关，默认网关再转发给A。而A收到请求后直接把ping包回复给B，形成了三角形环路，和AD的三角传输相似。

  

  四、逆向思维下

   如果不是B主动发包，而是A主动发包,，那能ping通吗？？

   我们抓包看一下。

   抓包前，先将ARP清除下。

   DOS下使用arp -d *清除，使用该命令后，还需要使用arp -d 192.168.1.254手动清除网关的ARP绑定关系，因为该绑定关系是动态的，arp -d *命令无法清除动态的ARP绑定关系。

   实际测试中，跟操作系统有关，发现Win10的清除不掉，而Win7某些情况可以清除掉。

   结果：不可以。

   

   在A服务器上抓包。由于包比较多，我们使用filter工具过滤，在搜索栏里输入：arp

   

   可以看到，服务器A发出ARP请求，询问服务器B的MAC地址，服务器B回应ARP响应包。

   然后输入：ip addr == 192.168.1.240，搜索服务器B的相应包。

   

   可以看到，A服务器直接向B服务器发起ICMP的Request请求，但一直没有收到响应包。

   在B服务器上抓包，输入：ip.src == 192.168.1.1 and ip.dst == 192.168.1.240

   

   可以看到，服务器B回应了服务器A的ping request包，但为什么A没有收到ping的reply呢？

   打开二层帧，可以看到服务器B的目的MAC是TP-Link_72:bd:10，这时，我们可以推断出来，服务器B回包ping的请求包，但因为服务器B认为服务器A和自己不在同一个网段，其ping的回应包交给了网关处理，但网关并没有将这个包转交给服务器A。

    由于网关是一台路由器，不支持抓包，不好判定是什么原因导致的不转发该数据包。有可能路由器查看目的MAC是自己，而自己与服务器B没有交互，就将数据包丢弃了。

  四、其他

  win10系统启动Wireshark后会发现不了物理网卡。

  

  原因是NPF没有启动，需要在DOS下运行：net start npf

  

勿喷！勿喷！

我不太知道真实环境，我自己搭了一个虚拟场景。真实环境可能不相符。

交换机是空地 没有配置。抓取的交换机上连口的包

先是PC2 ping PC1，这个是没问题的

中间有黑色的包。好像是重定向

然后是PC1ping PC2，

现在  我重启路由器和交换机清除arp，直接用pc1去ping pc2

虚拟环境中没有出现三角传输，可能和环境有关系。虚拟环境中路由器收到包是会转的。这个和真实环境可能不太一样。

感谢分享

分析得非常好，之前都是模模糊糊一知半解，很认真的看完了，感谢楼主！

看的还是有点懵逼

感谢楼主！

碰到有客户这么玩，做访问控制，很刺激。。。。  

一本wireshark的书，第一个就是三角传输。

项目中经常会碰到这种，来回路径不一致。

实话实说，简单的看了下，一个字“懵”因为看不了抓的包，反正是没上心，看的稀里糊涂的，哪天认真的看下。

看完了，有点了解