wireshark常见使用操作讲解以及几个故障解决案例分享

作者：一天，公众号：网络之路博客（ID：NetworkBlog）。让你的网络之路不在孤单，一起学习，一起成长。

前言

对于wireshark从学习路由交换这么久来，应该并不陌生了，一直没有讲解过关于wireshark的相关内容，这里来介绍下wireshark的常见操作，以及几个案例分享。

wireshark的常见操作讲解

（1）网卡选择

对于电脑本身有多个网卡的时候，选择网卡就成为了一个困惑的地方，其实这里很简单，只要把鼠标放在对应的网卡上面就可以看到地址等信息，就容易判断出来了。

（2）过滤器

直接抓包，电脑发出去的所有包，或者镜像过来的包 都非常的多，比便于查看某一个地址的流量，这里就需要学下wireshark的过滤器表达式。 

比较操作符号 ==等于，比如==192.168.1.1，则匹配出192.168.1.1的信息 ! 不等于 排除掉 >大于 通常用于端口号，包长度 <小于 通常用于端口号，包长度 >= 大于等于 <=小于等于

逻辑操作符号 and 两个条件必须同时满足 or 其中一个条件满足即可 xor 有且仅有一个条件被满足 not 没有条件满足

ip地址过滤 ip.addr：匹配IP地址，源目任意一个匹配即可 ip.src：匹配源IP地址 ip.dst：匹配目的IP地址

端口、标识过滤 tcp.port：匹配tcp端口号，源目任意一个即可 udp.port：匹配udp端口号，源目任意一个即可 udp.srcport：匹配udp端口号，源目任意一个即可 udp.dstport：匹配udp端口号，源目任意一个即可 tcp.srcport：匹配tcp源端口号 tcp.dstport：匹配tcp目的端口号 tcp.flag.syn：匹配TCP的syn tcp.flg.ack：匹配tcp的ACK

协议过滤 可以通过输入arp、ip、icmp、udp、tcp、dhcp、dns、stp等来匹配

（3）常见过滤语法

ip.addr==192.168.1.1：匹配源目有192.168.1.1的地址 ip.src==192.168.1.1:匹配源IP  192.168.1.1 ip.des==192.168.1.1：匹配目的IP 192.168.1.1 ip.src==192.168.1.100        and ip.dst==223.5.5.5 ：匹配源192.168.1.100，目的223.5.5.5（同时） tcp.port==80：匹配tcp端口号80，源目端口号匹配一个即可 udp.srcport==80：匹配udp源端口号80 tcp.flag.syn==1：匹配tcp的syn置1 !stp：排除掉STP流量 not udp.port==53：排除udp端口号有53的内容（与!符号作用一样）

案例一：端口映射访问失败

客户在路由器做了端口映射，但是外网访问业务不通，初步检查配置没有问题，开启了wireshark抓包

通过过滤器，ip.adrr==过滤出外网，这样源跟目都能匹配上，然后开始业务访问，发现本机192.168.255.88发给了对端的9998会话，开始建立SYN，但是第二条对方返回过来的是RST,ACK标志，这种情况有几个常见的可能

服务器端由于某种原因，应用进程奔溃了，无法正常建立三次握手，所以在收到SYN的时候直接回应RST、ACK。（这个可以通过在内网访问应用排除掉这个可能）

服务器安全策略原因禁止了，导致无法正常建立三次握手（这个通过排查个人防火墙是否开启，有没有安全策略禁止对应端口号、以及安全软件等）

端口映射没生效，路由器回应的RST与ACK，因为路由器系统大多基于Linux定制开发的，如果映射没生效，相当于本身没有开放这个端口号，那么路由器收到以后会直接回应RST、ACK。

 比如这里远程桌面路由器的接口地址，可以看到，它是直接返回RST、ACK来快速断开，从上面的分析来看，很大可能是因为路由器的映射没生效导致的。

问题解决：把端口映射配置删除掉，重新配置了一次，问题解决，映射生效，可以正常的建立三次握手建立TCP连接了，如果实际中重新配置还是没用，还可以在服务器端口开启wireshark的抓包，匹配客户端过来的地址，看是否有收到，如果没收到，正面对方流量没过来，可能是运营商过滤了，或者路由器收到没有转发。（这里运营商过滤应该是不存在，因为有关于对方的RST、ACK回包，表明对方已经收到）

案例二：访问对方业务不通

实际中，可能会遇到这样的情况，Ping对方是通的，但是访问具体的业务却不通，在无法定位的时候，wireshark可以帮忙缩短这些可能性的范围。

（1）对方有回应

 如果对方有回应，不管flag是什么，但是至少说明对方可以接收到这边发过去的报文，然后根据flag来定位，像RST、ACK，上面已经分析过了

（2）对方没有回应

如果发送过去的数据，对方一直没响应，只有客户端一直在重传，那这个就有两种可能

• 数据包发出去，对方没有收到

• 数据包发出去，对方收到了，但是由于业务端口号不对，对方没有监听这个端口号，直接丢弃了或者中间有安全设备进行过滤，没有放行

• 这两种可能，可以通过Ping对方或者在对方抓包，来具体验证，最终定位出来问题。

案例三：地址获取不到

一个哥们遇到一个奇怪的问题，2根网线其中一台电脑死活获取不到地址，另外一台随便接都没问题，而且静态手动设置地址也不行，那可能就是网卡的问题，本来是想让他抓包定位的，结果他不会抓包~~,只能让他下次带一个USB过去试试。

 后来他开启了抓包，发现PC是有发送DHCP报文出去的，初看像是DHCP服务器没有响应 

但是仔细一看，客户端的MAC地址全0，全0是一个非法的MAC地址，网络中是不予处理的，这样导致不管是自动还是静态都上不了网的原因，解决这个，直接在网卡的配置的高级属性里面，给予一个合法的MAC地址即可。