大量连接数导致iptables报错ip_conntrack: table full, dropping packet.
8月 15th, 2008 Posted in iptables < by Johnny Woo >
这个问题更多出现在使用linux作为NAT服务器的环境中
默认ip_conntrack模块默认的链接时间是5天
导致大量链接后很容易超过记录表的大小
/etc/sysctrl.conf
net.ipv4.ip_conntrack_max = 81920
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1500
8月 15th, 2008 at 12:37 下午
没NAT的环境中，squid会引发这个问题吗？我觉得不应该啊
8月 15th, 2008 at 1:42 下午
可以使用 “NOTRACK” target 允许规则指定80端口的包不进入链接跟踪/NAT子系统 ,在iptables中添加一个’raw’表,该表在netfilter框架中非常靠前,并在PREROUTING和OUTPUT链上有钩子,从而可以对收到的数据包在连接跟踪前进行处理
使用下面的规则
iptables -t raw -A PREROUTING -p tcp –dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -p tcp –sport 80 -j NOTRACK
#如果这是一台NAT服务器的话，再添加下面这条规则
iptables -A FORWARD -m state –state UNTRACKED -j ACCEPT
8月 15th, 2008 at 1:44 下午
to JulyClyde :只要启用了iptables ,就会启用ip_conntrack ,iptables 需要对进出的包进行连接跟踪状态来判断策略
8月 16th, 2008 at 8:57 上午
JulyClyde的说法提醒了我
这个环境并不是由于SQUID导致的IP_CONNTARK模块报错
而是由于这台服务器上开放了IPTABLES
这个报错是iptables的报错
只是由于正好有大量链接导致iptables的报错.
我修改下标题吧.省的大家误解
8月 18th, 2008 at 1:22 下午
好像在AS4U3系统上出现得比较多,我后来线上跑到的U5,U6不会在大量并发连接时出现这个问题,好像是U3的一个内核BUG
8月 19th, 2008 at 10:41 上午
只要启用iptables就有conntrack？似乎没什么意义啊
TCP/IP本身就会处理连接的，不需要额外的conntrack吧？
8月 25th, 2008 at 11:18 下午
conntrack连接跟踪，这是iptables 内部处理TCP/UDP/ICMP数据包状态所需要的一个模块,在iptables 中以判断数据包状态为条件来过滤数据包是否被通过，这些状态包括
ESTABISHED
RELATED
INVALID
NEW
UNTRACKED
这些状态是在用户空间(iptables)中定义的，和平常所说的tcp包连接状态不是同一个概念
8月 30th, 2008 at 12:39 上午
我在gentoo上跑squid也遇到这个问题了，办法是重新编译内核，将ip_conntrack模块去掉.