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.addr192.168.1.1：匹配源目有192.168.1.1的地址
ip.src192.168.1.1:匹配源IP 192.168.1.1
ip.des192.168.1.1：匹配目的IP 192.168.1.1
ip.src192.168.1.100 and ip.dst223.5.5.5 ：匹配源192.168.1.100，目的223.5.5.5（同时）
tcp.port80：匹配tcp端口号80，源目端口号匹配一个即可
udp.srcport80：匹配udp源端口号80
tcp.flag.syn1：匹配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对方或者在对方抓包，来具体验证，最终定位出来问题。