编写ringBuff过程中遇到的一次bug

问题描述

    最近在隧道项目的开发过程中遇到了一个奇怪的bug，如上图，在网关C InBound模块中收到了D主机发送给主机A的数据包（解密成功后查出），按照代码逻辑C InBound中收到的所有包都是网关B OutBound模块转发而来的，这些包肯定是B发过来的。设计中网关用户侧使用的是af_packet抓的包，之后进入OutBound转发给目标主机所在的网关，进入其InBound模块进行解封装、解密与转发，而且所有网关部署了转发策略（依据五元组），网关B的策略只允许A->D的包出去，网关C的策略只允许D->A的包出去，进来的包不受限。所以网关C解密得到D->A的包很奇怪。网关两侧都使用了我自己编写的RingBuff，由于开发语言使用的go，配合channel很容易实现RingBuff。

问题分析

    通过抓包发现，网关B的OutBound模块之所以转发D->A的数据包是因为网关B用户侧的af_packet不仅仅抓取了用户A的数据包还抓了网关B发往用户A的包，所以会出现这种现象，解决的办法是，设置BPF，控制af_packet抓包的方向，只抓取InBound的包。策略失效的原因是因为RingBuff空间被无用包侵吞。在设计RingBuff的时候，定义RingBuff的长度为(channelLen + 1) * threadNum * frameSize，OutBound抓取一个包就轮询的分配给worker线程，但当出现杂包之后这个空间明显就不够用了。所以得严格按照生产一个包消费一个包来编写代码，对于杂包要约束其固定在一个buff里，待出现有用包之后再移动buffIndex。RingBuff空间被侵占的后果就是数据包的空间可能会出现错乱，新包会覆盖旧包。


    自然怜幽草，人间爱晚晴。