我们最近遇到了一个问题,我们的一台服务器(Debian Squeeze)在负载较大时变得无响应。查看内核日志,我认为原因如下:
kernel: nf_conntrack: table full, dropping packet
据我了解,这是 conntrack 模块,它对连接进行一些状态跟踪,报告用于存储连接详细信息的表已满。
根据我所做的研究,似乎有两种方法可以缓解这种情况:
增加表格的尺寸。
将该模块从系统中完全移除。
然而,在这台机器上不/proc/sys/net/ipv4/ip_conntrack_max
存在/proc/sys/net/ipv4/netfilter/ip_conntrack_max
( 下没有ipv4
目录net
)。
如果我这样做,lsmod
就不会得到任何结果。
所以,我有点困惑——也许有人可以为我澄清一下情况?
- conntrack 是否已安装?如果已安装,设置在哪里?为什么它未显示在 lsmod 中?
- 如果没有安装 conntrack,为什么会发出表已满消息?
谢谢
答案1
这是根据经验得出的 - 我还没有做过研究来验证这些信息:我见过一些系统在系统日志中出现同样的错误和/proc/sys/net/ipv4/ip_conn* 或 /proc/sys/net/ipv4/netfilter 中没有任何内容。我也想知道原因 - 但一旦找到原始症状的修复方法,这不再那么重要。;)
缓解策略有两个方面:通过 sysctl 增加限制(简单的短期方法)并找出为什么被跟踪的连接数量如此之高。
如果超出了默认限制,而相关服务器不打算处理大量连接,那么显然根本不应该达到限制。具有高连接跟踪要求的服务的一个很好的例子是服务于十万多个客户端的“公共”DNS 服务器。
缓解措施是查看日志,确保反 DOS/DDOS 措施到位(例如参见 fail2ban),并确保安装了合理的防火墙配置。
关于 lsmod,我还没有遇到过它似乎处于活动状态但模块未列出的情况。我不确定这种情况是如何发生的。
答案2
conntrack 的设置通常在 /proc/sys/net/netfilter/nf_conntrack_max 中。