再看nf_conntrack: table full问题

2013年4月22日 发表评论 阅读评论

一年前,我写过一篇博文叫 ————  ip_conntrack: table full问题 ,当时是在squid应用主机上最先发现了该问题,也于当时,深刻了解到iptables的这个报错,会造成拒绝服务的问题。其后iptables重启 (重启会将该hash表存的值清空)、proc参数优化,临时解决了该问题 。并未进行细一步的研究 。随着centos 由5.X升级到6.X ,该模块的名字也由ip_conntrack变成了nf_conntrack 。两者的区别是,前者只支持ipv4,而后者增加了对ipv6的支持。

由于公司自身的推广到位,流量出现了倍增 。于是公司决定另选了两个机房,每个机房各放置一台主机做squid cache加速 。而运行过程中一直有一个小问题,就是偶尔会出现丢包的问题。当于以为是IDC的问题,一直让IDC去查原因,IDC那边并未查到原因 。这个问题就暂时搁置了。

同于又由于受近期金价暴跌的影响,网站流量由平时的80M/s 直接上升到250M/s ,这个ping丢包的问题变的尤为明显。而将加速应用指到数据机房的squid上时。同现出现了ping丢包的问题,这个不得不从自身找原因了。通过/var/log/message查看,发现老面孔 ———— ip_conntrack: table full 。看到该错误,首先关闭了iptables 。过了一两分钟后,神奇的丢包问题没了。汗 ……

至此开始真正开始关注此问题。总结了下网上对该问题的处理方式有三种。

方法一:修改参数法

这个方法我在一年前就已经用过。如下:

vim /etc/sysctl.conf
#加大 ip_conntrack_max 值
net.ipv4.ip_conntrack_max = 393216
net.ipv4.netfilter.ip_conntrack_max = 393216
#降低 ip_conntrack timeout时间
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120

增加完以上内容后,通过sysctl -p 使配置生效 。不过该方法有两个缺点:一是重启iptables后,ip_conntrack_max值又会变成65535默认值,需要重新sysctl -p ;另一个是该法治标不治本,在高并发时,很快又会悲剧重演。

方法二:使用RAW表,跳过记录法

首先先认识下什么是raw表?做什么用的? 

iptables有5个链:PREROUTING,INPUT,FORWARD,OUTPUT,POSTROUTING,4个表:filter,nat,mangle,raw 。 

4个表的优先级由高到低的顺序为:raw-->mangle-->nat-->filter 

举例来说:如果PRROUTING链上,即有mangle表,也有nat表,那么先由mangle处理,然后由nat表处理 。

RAW表只使用在PREROUTING链和OUTPUT链上,因为优先级最高,从而可以对收到的数据包在连接跟踪前进行处理。一但用户使用了RAW表,在某个链上,RAW表处理完后,将跳过NAT表和 ip_conntrack处理,即不再做地址转换和数据包的链接跟踪处理了。
RAW表可以 style="color:#E53333;">应用在那些不需要做nat的情况下,以提高性能。如大量访问的web服务器,可以让80端口不再让iptables做数据包的链接跟踪处理,以提高用户的访问速度 。

具体操作方法如下:

1、修改/etc/sysconfig/iptables 文件中的-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED, UNTRACKED -j ACCEPT 行。增加红色字体中的部分,保存并restart iptables 。

2、运行下面的语句:

iptables -t raw -A PREROUTING -p tcp -m multiport --dports 80,3128 -j NOTRACK
iptables -t raw -A PREROUTING -p tcp -m multiport --sports 80,3128 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp -m multiport --dports 80,3128 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp -m multiport --sports 80,3128 -j NOTRACK

如果只是一个端口,改为下面的语句:

iptables -t raw -A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp -m tcp --sport 80 -j NOTRACK
iptables -t raw -A PREROUTING -p tcp -m tcp --sport 80 -j NOTRACK
iptables -t raw -A OUTPUT -p tcp -m tcp --dport 80 -j NOTRACK

注:第1步很重要,如果第1处没改,执行后面的语句会造成相应的端口不能访问。我使用该方法时,就因为没有执行第一步的操作,造成web访问不能使用。

方法三:移除模块法

[root@localhost log]# /sbin/lsmod | egrep 'ip_tables|conntrack'
nf_conntrack_ipv6       8748  2
nf_defrag_ipv6         12182  1 nf_conntrack_ipv6
nf_conntrack           79453  2 nf_conntrack_ipv6,xt_state
ipv6                  322541  209 ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6

执行上面的语句,不难发现state模块和nf_conntrack之间是有依赖关系的。所以想要卸载nf_conntrack模块的话,必须也要把state模块移除,不然,其会自动启用nf_conntrack模块。

操作方法如下:

1、先将/etc/sysconfig/iptables 中包含state的语句移除,并restart iptables 。

2、执行语句

modprobe -r xt_NOTRACK nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state
modprobe -r nf_conntrack

执行完查看/proc/net/ 下面如果没用了 nf_conntrack ,就证明模块移除成功了。

总结:

以上三种方法种,如果像web这样的操作访问量并发不大的情况下,建议通过第一种方法实现。因为nf_conntrack模块的作用不仅仅只用于记录状态,iptables还可以通过对该模块的使有达到动态过滤的作用。如我在用ab动测试的一台服务器上进行并发模拟时,在/var/log/message里发现如下的日志:

Apr 22 15:21:46 localhost kernel: possible SYN flooding on port 80. Sending cookies.
Apr 22 15:22:46 localhost kernel: possible SYN flooding on port 80. Sending cookies.

而此时iptables会智能的将发动SYN flood攻击的IP暂时拒绝掉:

[root@localhost ~]# ab -c 500 -n 5000 "http://192.168.10.177/"
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.10.177 (be patient)
apr_socket_recv: Connection reset by peer (104)
Total of 68 requests completed

如上所以,我用ab操作时,其就会收到apr_socket_recv 的错误提示 。我在网上查询到其具体实现的原理如下:

传统的防火墙只能进行静态过滤,而 iptables 除了这个基本的功能之外还可以进行动态过滤,即可以对连接状态进行跟踪,通常称为 conntrack 。 但这不意味着它只能对 TCP 这样的面向连接的协议有效,它还可以对 UDP, ICMP 这种无连接的协议进行跟踪,我们下面马上就会看到。

iptables 中的连接跟踪是通过 state 模块来实现的,是在PREROUTING 链中完成的,除了本地主机产生的数据包,它们是在 OUTPUT 链中完成。 它把“连接”划分为四种状态:NEW, ESTABLISHED, RELATED 和 INVALID。连接跟踪当前的所有连接状态可以通过 /proc/net/nf_conntrack 来查看(注意,在一些稍微旧的 Linux 系统上是 /proc/net/ip_conntrack)。 

当 conntrack 第一次看到相关的数据包时,就会把状态标记为 NEW ,比如 TCP 协议中收到第一个 SYN 数据包。当连接的双方都有数据包收发并且还将继续匹配到这些数据包时,连接状态就会变为 ESTABLISHED 。而 RELATED 状态是指一个新的连接,但这个连接和某个已知的连接有关系,比如 FTP 协议中的数据传输连接。INVALID 状态是说数据包和已知的任何连接都不匹配。

当然,仅仅利用iptables conntrack自动实现syn flood 等DDOS攻击时很弱的。而现成的动态过滤和DDOS防护的方法是很多的。比如netstat脚本实现,iptalbes限制每秒进行连接数,nginx/apache的连接数限制模块及fail2ban日志分析法………… ,所以在具有以上防护的情况下,非常推荐将web 、squid/varnish等应用所在的服务器配置为RAW方式 。我在现网一台150M/S 的cache server上将80和3128两个端口全部NOTRACK之后,conntrack hash表由瞬满直线下降到只有几百条。

最后,最不推荐使用的第三种方法,因为第三种方法会将state模块也一块儿移除掉。

参考页面:

http://jaseywang.me/2012/08/16/%E8%A7%A3%E5%86%B3-nf_conntrack-table-full-dropping-packet-%E7%9A%84%E5%87%A0%E7%A7%8D%E6%80%9D%E8%B7%AF/

http://wiki.khnet.info/index.php/Conntrack_tuning

http://blog.zol.com.cn/2608/article_2607945.html

http://wangcong.org/articles/learning-iptables.cn.html

http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/

http://blog.csdn.net/dog250/article/details/7262619




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: Linux/unix/mac 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.