有关 iptables ip_conntrack 的问题

[rrfeng]

大家应该了解在高访问量的服务器上开启 iptables 会必然遇到的一个问题：
『nf_conntrack: table full, dropping packet.』

为了解决这个问题，一般都会介绍 3 种办法，一种是 sysctl 增大 nf_conntrack_max 的值，治标不治本；一种是弃用 state 模块；第三种是使用 raw 表。

我采用第三种方法，在一个作为 反向代理 的 Nginx 服务器上应用策略，开始明显生效了，/proc/net/nf_conntrack 降到了系统默认值以下(65536)。

然后随着流量的进一步增加，问题又重现了。经过分析，我认为是从 nginx server 到后端服务器之间的连接仍然被 conntrack 了。那么作为一个反向代理，一个进来的连接必然会生成 一个到后端服务器的连接，甚至更多。所以 『nf_conntrack: table full, dropping packet.』重现了……

于是我尝试对于 server 主动发起的连接也启用 NOTRACK：
-t raw -A OUTPUT -d 10.1.0.1/24 -j NOTRACK
（10.1.0.0 是后端服务器的网段）
满怀希望的以为现在终于可以彻底解决这个问题了吧……

事实是，这台 server 再也不能『主动』访问其他服务器了，想了一下假如主动发起的连接不做 conntrack，那么远端回复的流量在经过 filter->INPUT 的时候就不能被识别，于是被禁止了……

不知以上是否我理解有误？


那么，这个问题如何解决？『主动发起的流量如何 UNTRACK？』

[liwei]

在filter表里把进入的流量放行不行么？

[alexapollo]

尝试把conntrack的时间调短一点？
默认时间好像非常长

[rrfeng]

@liwei
how ？主动发起的高端端口号是随机的，怎么放行？

@alexapollo
访问量太大，调短应该也是治标不治本……

后台的 server （nginx 1：3 back server）都已经开始出现这个问题了。。。。

[liwei]

@rrfeng 从被代理的server到代理服务器的连接源端口不是80或者8080这样固定的端口吗？

[rrfeng]

@liwei

应该可行。试一下