用iptables的raw表解决ip_conntrack table full, dropping packet的问题

用iptables的raw表解决ip_conntrack table full, dropping packet的问题

1)  什么是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表可以应用在那些不需要做nat的情况下，以提高性能。如大量访问的web服务器，可以让80端口不再让iptables做数据包的链接跟踪处理，以提高用户的访问速度。

2)  iptables的数据包的流程是怎样的？

(流程介绍来源：http://selboo.com.cn/post/721/)
一个数据包到达时,是怎么依次穿过各个链和表的（图）。

基本步骤如下：
1. 数据包到达网络接口，比如 eth0。
2. 进入 raw 表的 PREROUTING 链，这个链的作用是赶在连接跟踪之前处理数据包。
3. 如果进行了连接跟踪，在此处理。
4. 进入 mangle 表的 PREROUTING 链，在此可以修改数据包，比如 TOS 等。
5. 进入 nat 表的 PREROUTING 链，可以在此做DNAT，但不要做过滤。
6. 决定路由，看是交给本地主机还是转发给其它主机。

到了这里我们就得分两种不同的情况进行讨论了，一种情况就是数据包要转发给其它主机，这时候它会依次经过：
7. 进入 mangle 表的 FORWARD 链，这里也比较特殊，这是在第一次路由决定之后，在进行最后的路由决定之前，我们仍然可以对数据包进行某些修改。
8. 进入 filter 表的 FORWARD 链，在这里我们可以对所有转发的数据包进行过滤。需要注意的是：经过这里的数据包是转发的，方向是双向的。
9. 进入 mangle 表的 POSTROUTING 链，到这里已经做完了所有的路由决定，但数据包仍然在本地主机，我们还可以进行某些修改。
10. 进入 nat 表的 POSTROUTING 链，在这里一般都是用来做 SNAT ，不要在这里进行过滤。
11. 进入出去的网络接口。完毕。

另一种情况是，数据包就是发给本地主机的，那么它会依次穿过：
7. 进入 mangle 表的 INPUT 链，这里是在路由之后，交由本地主机之前，我们也可以进行一些相应的修改。
8. 进入 filter 表的 INPUT 链，在这里我们可以对流入的所有数据包进行过滤，无论它来自哪个网络接口。
9. 交给本地主机的应用程序进行处理。
10. 处理完毕后进行路由决定，看该往那里发出。
11. 进入 raw 表的 OUTPUT 链，这里是在连接跟踪处理本地的数据包之前。
12. 连接跟踪对本地的数据包进行处理。
13. 进入 mangle 表的 OUTPUT 链，在这里我们可以修改数据包，但不要做过滤。
14. 进入 nat 表的 OUTPUT 链，可以对防火墙自己发出的数据做 NAT 。
15. 再次进行路由决定。
16. 进入 filter 表的 OUTPUT 链，可以对本地出去的数据包进行过滤。
17. 进入 mangle 表的 POSTROUTING 链，同上一种情况的第9步。注意，这里不光对经过防火墙的数据包进行处理，还对防火墙自己产生的数据包进行处理。
18. 进入 nat 表的 POSTROUTING 链，同上一种情况的第10步。
19. 进入出去的网络接口。完毕。

3)  iptables raw表的使用

增加raw表，在其他表处理之前，-j NOTRACK跳过其它表处理
状态除了以前的四个还增加了一个UNTRACKED

例如：
可以使用 “NOTRACK” target 允许规则指定80端口的包不进入链接跟踪/NAT子系统

4) 解决ip_conntrack: table full, dropping packet的问题

在启用了iptables web服务器上，流量高的时候经常会出现下面的错误：

ip_conntrack: table full, dropping packet

这个问题的原因是由于web服务器收到了大量的连接，在启用了iptables的情况下，iptables会把所有的连接都做链接跟踪处理，这样iptables就会有一个链接跟踪表，当这个表满的时候，就会出现上面的错误。

iptables的链接跟踪表最大容量为/proc/sys/net/ipv4/ip_conntrack_max，链接碰到各种状态的超时后就会从表中删除。

所以解決方法一般有两个：

(1) 加大 ip_conntrack_max 值

(2): 降低 ip_conntrack timeout时间

上面两种方法打个比喻就是烧水水开的时候，换一个大锅。一般情况下都可以解决问题，但是在极端情况下，还是不够用，怎么办？

这样就得反其道而行，用釜底抽薪的办法。iptables的raw表是不做数据包的链接跟踪处理的，我们就把那些连接量非常大的链接加入到iptables raw表。

如一台web服务器可以这样：

5)  iptables raw表的效果测试

我们在一台web server上做测试，先不使用raw表，观察链接跟踪表(/proc/net/ip_conntrack)的大小：

先看下iptables配置：

在另一台机器上用ab测试：

在web server上查看链接跟踪表(/proc/net/ip_conntrack)的大小：

可以看到跟踪表内有5153个链接，再大一些的压力可能就要报ip_conntrack: table full, dropping packet的错误了。

下面我们启用raw表：

先更新iptables：

重启iptables：

可以用iptables命令查看是否启用成功了：

然后再用ab测试：

查看链接跟踪表(/proc/net/ip_conntrack)的大小：

跟踪表内只跟踪了一个链接了。

可以看到iptables已经不跟踪进出端口为80的链接了。测试结果表明用iptables的raw表可以完美解决ip_conntrack: table full, dropping packet的问题。

最后编辑：2015-08-26

作者：王, 帅

这个作者貌似有点懒，什么都没有留下。

站内专栏