Zeek-PF_RING inner-5-tuple Load Balance

发表于 更新于 分类于
本文字数： 1.7k 阅读时长 ≈ 2 分钟

背景

​ 早在2019年AWS刚对外发布“Traffic Mirroring” 测试的时候，作为国内最早一批吃“螃蟹”的用户，期间各种试错、填坑之后，“怒”写下了“我在’云’上的日子 - AWS上流量镜像遇到的坑”。也幸好是前期积累的经验，在之后其他云平台上使用云原生的“Traffic Mirroring”对接NTA时更加“丝滑”，毕竟做安全的哪有不监控流量的？！

​ 本篇文章介绍的情况恰巧相反。假设，你目前所在的云平台暂不支持“Traffic Mirroring”你会怎么做？当然，我们可以通过安装agent的形式将流量发出来，这也是在云原生支持“Traffic Mirroring”之前的通用做法。如今这类的agent不少，开源的有，商业的也有。恰巧我现在就在使用某商业产品，不过很“蠢”的是该产品通过VXLAN发送数据的时候源端口竟然是固定的。正因为这个问题，引出了这篇文章。

​ 当你使用tcpdump的时候，你会看到这样的情况。其中，192.168.199.100是数据源，192.168.199.200 是NTA。

1
2
3
4
5
6
$ sudo tcpdump -nni eth1 -c 100 | grep 4789

23:52:25.748497 IP 192.168.199.100.49152 > 192.168.199.200.4789: VXLAN, flags [I] (0x08), vni 1
23:52:25.748498 IP 192.168.199.100.49152 > 192.168.199.200.4789: VXLAN, flags [I] (0x08), vni 1
23:52:25.748505 IP 192.168.199.100.49152 > 192.168.199.200.4789: VXLAN, flags [I] (0x08), vni 1
23:52:25.748530 IP 192.168.199.100.49152 > 192.168.199.200.4789: VXLAN, flags [I] (0x08), vni 1

​ 大家都知道，Zeek配合PF_RING之后是支持基于多进程的流量负载均衡的。PF_RING默认的负载均衡是基于5-tuple来进行的。也就是基于5元组进行的HASH，同一个HASH分配到同一个进程。由于我的数据流五元组是一样的，导致我开了16个进程的Zeek只有1个进程是满负载，其他的15个进程是“空转”的。也导致了流量一大就出现了丢包的问题。

解决方案

​ 不得不说一句Zeek的开源社区非常的活跃，在Slack上提问了相关问题后，大佬们就给出了“解题思路”。解决方案也很简单将 test_cluster_types设置为inner-5-tuple。

​ inter 含义 引用原文：This PR adds support for the more recent “INNER” clustering strategies of PF_RING. These allow load balancing according to the IP addresses and ports inside (for instance) GRE tunnels, rather than according to the tunnel’s IP. This was leading to huge balancing issues on some sensors we run.

这里需要关注一下几个点：

  • PF_RING 8.2 版本集成了该功能，所以对PF_RING版本有要求

  • zeekctl版本有要求，ZeekControl version 2.5.0-5包含了此代码

    image-20230411112133033

修改后的Zeek配置文件代码

1
2
3
4
$ more /usr/local/zeek/etc/zeekctl.cfg

PFRINGClusterID = 99
PFRINGClusterType = inner-5-tuple

修改前

image-20230407232532950

修改后

image-20230411112934287

参考