ZooKeeper TCP连接被防火墙阻断排查过程

0x01 现象

本来正常的Zookeeper选举连接，过一段时间会突然异常，重新选举，查看日志提示连接被Reset掉了。

java.net.SocketException: Connection reset

各个实例的日志都查看了，也没找到异常点。
没办法，只能抓包了。同事使用tcpdump抓了包，使用wireshark打开看了，也没有看到什么异常。正常的连接，会突然收到一个RST包。

本来对ZooKeeper了解不多，但有接触过，也被拉着一起排查。
同事排除了SSL的影响，我一开始的怀疑点是数据包损坏，但数据包损坏的话，应该有重传发生，根据抓的包看，并没有发现重传，这个方向应该不对。

其他可能的原因就只有两个了。

ZooKeeper本身未知的问题；
某些流量中的pattern触发了网络设备的防护机制。

同事反馈这个环境里的ZooKeeper实例是在同一个二层网络中，也就是说并没有跨网络设备。鉴于1的可能性也比较小，就目前手头有的输入来说，就只有抓到的包，还是按照2的方向排查下。

0x02 IP协议细节

2.1 identity字段

通过对比正常和异常的数据包，发现有以下异常。

正常包的identity字段是逐渐递增的。
而RST的包只有0和固定的23352（经过了修改）。查询资料1，有的说是可以标识IP包来源的，有的说没有特别含义，只是分片后在目标端用来重组IP数据包。跟同事反馈了，算是一个线索，但并没被完全认可。不能完全证实是网络设备发送的RST包。

正常RST为0。

Identification: 0x0000 (0)

异常RST的（以下信息经过了修改）。

Identification: 0x8882 (23352)

2.2 TTL字段

这个字段学习过IP协议的同学都知道，是用来标识一个报文在网络中的生存跳数，每过一次路由器，TTL就会减1，避免报文无限制转发。

同样注意到异常RST包的TTL有两个值，一个是64，一个128。通过比较正常报文发现，正常报文的也是64。通过右键字段，可以将其“应用为列”，展示在wireshark报文列表中，更直观看出。

这个字段可以作为有效证据，证实确实有网络设备发送了TCP RST包。

那到底是什么设备发送的？还有另外一个直接线索。

0x03 额外的直接线索

由于wireshark默认展示到列表中的字段有有限，很多细节需要自己去对比。比如这个问题中最重要的线索，MAC地址。这是同事发现的，前面说的异常的源MAC地址，跟其他数据报文的明显不同，writeshark直接展示为

Ethernet II, Src: Shenzhen_xx:xx:xx (xx:xx:xx:xx:xx:xx),
...

正常的

Ethernet II, Src: xx:xx:xx:xx:xx:xx (xx:xx:xx:xx:xx:xx),
...

另外一个非集群成员的设备伪装发送了一个RST包。正式结案。

0x04 结论

证实了是网络设备发出的RST包，还没结案。为什么二层网络中，会经过网络设备？

这个问题咨询了这方案的专家，得到的答复是：

交换机开启了STP协议，STP震荡导致了交换机的FDB表刷乱了，导致一些二层包，转到了网络设备上，触发了网络设备的默认防护行为，连接被Reset。

STP是交换机中软件层面用来防止环路的一种协议，也确认证实当时的环境有开启。

0x05 总结

排查过程先注意到IP协议中identity字段，然后注意到TTL字段，最直接的链路层的src MAC最后才注意到，一开始并没有找到最关键的点。协议用时方恨了解的少。