LINUX服务器防火墙nf_conntrack问题一例

本文主要是介绍LINUX服务器防火墙nf_conntrack问题一例，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、故障现象

业务反馈服务异常,无法响应请求，从系统日志 dmesg 或 /var/log/messages 看到大量以下记录：kernel: nf_conntrack: table full, dropping packet.

二、问题分析

业务高峰期服务器访问量大，内核 netfilter 模块 conntrack 相关参数配置过小不合理，导致 IP 包被丢掉，连接无法建立。

nf_conntrack 模块在 kernel 2.6.15（2006-01-03 发布）被引入，支持 IPv4 和 IPv6，取代只支持 IPv4 的 ip_connktrack，用于跟踪连接的状态，供其他模块使用。需要 NAT 的服务都会用到它，例如防火墙、Docker 等。以 iptables 的 nat 和 state 模块为例：

nat：根据转发规则修改 IP 包的源/目标地址，靠 conntrack 记录才能让返回的包能路由到发请求的机器。
state：直接用 conntrack 记录的连接状态（NEW/ESTABLISHED/RELATED/INVALID 等）来匹配防火墙过滤规则。
nf_conntrack 跟踪所有网络连接，记录存储在 1 个哈希表里。首先根据五元组算出哈希值，分配一个桶，如果有冲突就在链表上遍历，直到找到一个精确匹配的。如果没有匹配的则新建。连接记录会在哈希表里保留一段时间，根据协议和状态有所不同，直到超时都没有收发包就会清除记录。如果服务器比较繁忙，新连接进来的速度远高于释放的速度，把哈希表塞满了，新连接的数据包就会被丢掉。此时 netfilter 变成了一个黑洞，这发生在3层（网络层），应用程序毫无办法。

哈希表查看：
查看哈希表大小（桶的数量）
sysctl net.netfilter.nf_conntrack_buckets
查看最大跟踪连接数
sysctl net.netfilter.nf_conntrack_max
#默认 nf_conntrack_buckets * 4
# max 是 bucket 的多少倍决定了每个桶里的链表有多长，因此默认链表长度为 4
哈希表使用情况
sysctl net.netfilter.nf_conntrack_count
跟踪连接记录
四层协议类型和连接数：
cat /proc/net/nf_conntrack | awk '{sum[$3]++} END {for(i in sum) print i, sum[i]}'
连接数最多的 10 个 IP 地址：
cat /proc/net/nf_conntrack | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10

三、处理过程

哈希表扩容：
nf_conntrack_max 的默认值算法为：
CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)
nf_conntrack_buckets 默认值算法为：
HASHSIZE = CONNTRACK_MAX / 4
针对目前主机的配置建议配置(内存：16GB系统：64位)：
CONNTRACK_MAX=（16*1024^3）/16384/(64/32)=524,288
HASHSIZE=524,288/4=131,072
给哈希表扩容的影响：（主要是内存）
计算内存使用算法：
size_of_mem_used_by_conntrack (in bytes) = CONNTRACK_MAX * sizeof(struct ip_conntrack) + HASHSIZE * sizeof(struct list_head)

参数调整方法：