Linux iptables / conntrack性能问题

前端之家收集整理的这篇文章主要介绍了Linux iptables / conntrack性能问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在实验室里有4台机器进行测试设置:

> 2台旧P4机器(t1,t2)
> 1 Xeon 5420 DP 2.5 GHz 8 GB RAM(t3)Intel e1000
> 1 Xeon 5420 DP 2.5 GHz 8 GB RAM(t4)Intel e1000

测试linux防火墙性能,因为我们在过去几个月遭到了许多同步泛滥攻击.所有机器都运行Ubuntu 12.04 64bit. t1,t2,t3通过1GB / s开关互连,t4通过额外接口连接到t3.所以t3模拟防火墙,t4是目标,t1,t2扮演攻击者生成一个包的风暴(192.168.4.199是t4):

hping3 -I eth1 --rand-source --syn --flood 192.168.4.199 -p 80

t4丢弃所有传入的数据包,以避免与网关混淆,t4等性能问题.我在iptraf中观察数据包统计信息.我已经配置了防火墙(t3)如下:

>股票3.2.0-31-通用#50-Ubuntu SMP内核
> rhash_entries = 33554432作为内核参数
> sysctl如下:

net.ipv4.ip_forward = 1
net.ipv4.route.gc_elasticity = 2
net.ipv4.route.gc_timeout = 1
net.ipv4.route.gc_interval = 5
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_thresh = 2000000
net.ipv4.route.max_size = 20000000

(当t1 t2发送尽可能多的数据包时,我已经调整了很多以保持t3运行).

这项努力的结果有些奇怪:

> t1 t2设法发送每个大约200k包/ s.在最好的情况下,t4总共可以看到200k,因此丢失了一半的数据包.
> t3在控制台上几乎无法使用,虽然数据包正在流过它(大量的软irq)
>路由缓存垃圾收集器无法接近可预测的并且在默认设置中被极少数数据包/ s(<50k数据包/秒)所淹没
>激活有状态iptables规则使得到达t4的数据包速率降至约100k数据包/秒,有效地丢失了超过75%的数据包

而这 – 这是我的主要关注点 – 两台旧的P4机器尽可能多地发送数据包 – 这意味着网络上几乎每个人都应该能够做到这一点.

所以这里提出我的问题:我是否忽略了配置或测试设置中的一些重要信息?是否有任何替代方案来构建防火墙系统,尤其是在smp系统上?

解决方法

我将迁移到Kernel> = 3.6,它不再具有路由缓存.这应该解决你的一部分问题.

猜你在找的Linux相关文章