本文永久链接: https://www.xtplayer.cn/linux/netfilter/linux-netfilter-optimization/

如果您正在为高流量的 Web/DNS 服务器提供服务，并且最近使该服务器 PING 丢失并且并非所有 HTTP 请求都成功。您可以开始检查系统日志。并且如果您看到类似下面的内容，那么下面的指南将帮助您调整 Linux 服务器以正确处理流量负载。

Mar 22 21:25:55 localhost kernel: nf_conntrack: table full, dropping packet.
Mar 22 21:26:00 localhost kernel: printk: 11 messages suppressed.
Mar 22 21:26:00 localhost kernel: nf_conntrack: table full, dropping packet.
Mar 22 21:26:05 localhost kernel: printk: 16 messages suppressed.

状态查看

  • buckets 哈希表大小，max 最大记录的连接条数

    sudo dmesg | grep conntrack

    [    8.782060] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)

  • 哈希表使用情况

    grep conntrack /proc/slabinfo

    nf_conntrack_1       102    102    320   51    4 : tunables    0    0    0 : slabdata      2      2      0

  • 当前跟踪的连接数

    sudo sysctl net.netfilter.nf_conntrack_count

  • 跟踪连接详细信息

    # centos
    cat /proc/net/nf_conntrack
    # ubuntu，可能需要安装 conntrack 工具，yum install -y conntrack 或者 apt-getinstall -y conntrack
    conntrack -L

最大连接跟踪数

为了完成任务，NAT-server（一般指的是 iptables） 需要记录所有通过它的连接。无论是 “ping” 还是某人的 “ICQ”，NAT-server 都会记录在一个特殊的表中并跟踪所有会话。当会话关闭时，相关记录将从连接跟踪表中删除。这个记录表的大小是固定的，所以如果通过服务器的流量很大，但表太小，那么 NAT-server 就会开始丢弃数据包，中断会话。为了避免这样的麻烦，有必要适当增加连接跟踪表的大小。

  • 最大连接跟踪数默认为 nf_conntrack_buckets * 4，可以通过以下命令查看当前值：

    sysctl net.netfilter.nf_conntrack_buckets
    sysctl net.netfilter.nf_conntrack_max

  • CONNTRACK_MAX 默认计算公式

    CONNTRACK_MAX = 内存个数*1024*1024*1024/16384/(ARCH/32)
    • 其中 ARCH 为 CPU 架构，值为 32 或 64。
    • 比如：64 位 8G 内存的机器：(8*1024^3)/16384/(64/32) = 262144

临时调整

临时调整是临时性的，重启节点好配置值将会丢失。

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.nf_conntrack_max=1048576

永久调整

要使其配置在重新启动后永久存在，需要将这些值添加到 sysctl.conf 中

echo 'net.netfilter.nf_conntrack_max' = 1048576 >> /etc/sysctl.conf
echo 'net.nf_conntrack_max = 1048576' >> /etc/sysctl.conf
sysctl  -p

如果服务器中的 RAM 少于 1 GB，建议不要设置太大的值。

哈希表(hash-table)

哈希表大小是只读的，不能在 /etc/sysctl.conf 文件中设置值。64 位 Linux 系统中，4G 内存默认 16384，8G 内存默认 65536，16G 翻倍，以此类推。

给哈希表扩容的影响

主要是内存使用增加，32 位系统还要关心内核态的地址空间够不够。

netfilter 的哈希表存储在内核态的内存空间，这部分内存不能 swap，操作系统为了兼容 32 位，默认值往往比较保守。

  • 32 位系统的虚拟地址空间最多 4G，其中内核态最多 1G，通常能用的只有前 896M。

    给 netfilter 分配太多地址空间可能会导致其他内核进程不够分配。1 条跟踪记录 300 字节左右，因此当年 nf_conntrack_max 默认 65535 条，占 20 多 MB。

  • 64 位系统的虚拟地址空间有 256 TB，内核态能用一半，只需要关心物理内存的使用情况。

  • 计算内存使用的公式

    size_of_mem_used_by_conntrack (in bytes) = CONNTRACK_MAX * sizeof(struct ip_conntrack) + HASHSIZE * sizeof(struct list_head)

    • sizeof(struct ip_conntrack) 在不同架构、内核版本、编译选项下不一样。这里按 352 字节算。

    • sizeof(struct list_head) = 2 * size_of_a_pointer（32 位系统的指针大小是 4 字节，64 位是 8 字节）

    • 64 位系统，8G 内存的机器，按默认 CONNTRACK_MAX 为 262144，HASHSIZE 为 65536 时：262144 * 352 + 65536 * 8 = 92798976（88.5 MB）

  • 互联网公司的服务器通常内存没那么紧张，可以放开点：

    • CONNTRACK_MAX 为 1048576，HASHSIZE 为 262144 ，内存大概使用：1048576 * 352 + 262144 * 8 = 371195904（354 MB）

哈希表大小调整

需要通过内核模块的方式修改：

  • 临时生效：

    echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

  • 永久生效

    将以下内容添加到文件：/etc/modprobe.d/iptables.conf（如果没有则新建）

    echo 'options nf_conntrack hashsize=262144' >> /etc/modprobe.d/iptables.conf

减少超时时间

NAT-server 只跟踪通过它的 活动 的会话。如果一个会话很长时间是空闲的，不活跃，它将会因为超值而被关闭。当会话关闭时，关于它的信息将被删除，以便连接跟踪表不会溢出。

但是，如果超时的默认值很大，流量较大时候，即使将 nf_conntrack_max 扩展到了极限，跟踪表仍然有溢出的风险。为此，必须在 NAT-server 上正确设置连接跟踪超时。

可以执行以下命令查看默认值：

sysctl -a | grep conntrack | grep timeout

  • Ubuntu 16.04

    net.netfilter.nf_conntrack_generic_timeout = 600
    net.netfilter.nf_conntrack_icmp_timeout = 30
    net.netfilter.nf_conntrack_tcp_timeout_close = 10
    net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
    net.netfilter.nf_conntrack_tcp_timeout_established = 432000
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
    net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
    net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
    net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
    net.netfilter.nf_conntrack_udp_timeout = 30
    net.netfilter.nf_conntrack_udp_timeout_stream = 180

  • centos 7.8

    net.netfilter.nf_conntrack_dccp_timeout_closereq = 64
    net.netfilter.nf_conntrack_dccp_timeout_closing = 64
    net.netfilter.nf_conntrack_dccp_timeout_open = 43200
    net.netfilter.nf_conntrack_dccp_timeout_partopen = 480
    net.netfilter.nf_conntrack_dccp_timeout_request = 240
    net.netfilter.nf_conntrack_dccp_timeout_respond = 480
    net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
    net.netfilter.nf_conntrack_events_retry_timeout = 15
    net.netfilter.nf_conntrack_generic_timeout = 600
    net.netfilter.nf_conntrack_icmp_timeout = 30
    net.netfilter.nf_conntrack_sctp_timeout_closed = 10
    net.netfilter.nf_conntrack_sctp_timeout_cookie_echoed = 3
    net.netfilter.nf_conntrack_sctp_timeout_cookie_wait = 3
    net.netfilter.nf_conntrack_sctp_timeout_established = 432000
    net.netfilter.nf_conntrack_sctp_timeout_heartbeat_acked = 210
    net.netfilter.nf_conntrack_sctp_timeout_heartbeat_sent = 30
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_ack_sent = 3
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0
    net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0
    net.netfilter.nf_conntrack_tcp_timeout_close = 10
    net.netfilter.nf_conntrack_tcp_timeout_close_wait = 3600
    net.netfilter.nf_conntrack_tcp_timeout_established = 86400
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
    net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
    net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
    net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
    net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
    net.netfilter.nf_conntrack_udp_timeout = 30
    net.netfilter.nf_conntrack_udp_timeout_stream = 180

以上均是以秒为单位的超时值。

对于通外网的服务器，考虑调整以下参数，减少 DDoS 的危害：

  • net.netfilter.nf_conntrack_tcp_timeout_established：默认 432000（5 天）

    • 这个值对应的场景是 “双方建立了连接后一直不发包，直到 5 天后才发”
    • 但默认 keep-alive 超时时间只有 2 小时 11 分（net.ipv4.tcp_keepalive_time + net.ipv4.tcp_keepalive_intvl * net.ipv4.tcp_keepalive_probes），由于超时关 socket 不发包，conntrack 无法根据包头的标识知道状态的变化，记录会一直处于 ESTABLISHED 状态，直到 5 天后倒计时结束才删掉。
    • 空连接攻击的最佳目标。攻击者把 IP 包头的源地址改成随机 IP，握完手就关 socket，用一台机发请求就能把你的哈希表填满。

  • net.netfilter.nf_conntrack_tcp_timeout_syn_recv：默认 60

    • 类似，故意不发握手的 ACK 即可。但这个超时时间没那么夸张，系统也有 syn cookie 机制来缓解 syn flood 攻击。

其他值得注意的参数：

  • net.netfilter.nf_conntrack_tcp_timeout_syn_sent：默认 120

    • 你的程序的 connect timeout 有这么长吗？

  • net.netfilter.nf_conntrack_tcp_timeout_fin_wait：默认 120

    • net.ipv4.tcp_fin_timeout 默认 60 秒，通常还会参考 BSD 和 macOS 设成更小的值。这里往往也没必要这么大。

  • net.netfilter.nf_conntrack_icmp_timeout：默认 30

    • 哪里的 ping 会等 30 秒才超时？

这几个倒是比较合理，小于等于可能遇到的极端情况，但如果不想半关闭的连接的记录继续占着宝贵的哈希表，提早清了似乎也没什么问题：

  • net.netfilter.nf_conntrack_tcp_timeout_time_wait：默认 120

    • Linux 里的 MSL 写死 60 秒（而不是 TCP 标准里拍脑袋的 120 秒），TIME_WAIT 要等 2MSL，这里 120 算是个合理的值。
    • 但现在默认有 PAWS（net.ipv4.tcp_timestamps），不会出现标准制定时担心的迷途报文回来碰巧污染了序列号相同的新连接的数据的情况。互联网公司基本都开 net.ipv4.tcp_tw_reuse，既然半连接都不留这么久，记录似乎也不需要留这么久。

  • net.netfilter.nf_conntrack_tcp_timeout_close_wait：默认 60

    • CLOSE_WAIT 状态是让被动关闭方把该传的数据传完。如果程序写得不好，这里抛了未捕捉的异常，也许就走不到发 FIN 那步了，一直停在这里。

  • net.netfilter.nf_conntrack_tcp_timeout_last_ack：默认 30

    • 被动关闭方发 FIN 后如果一直收不到对面的 ACK 或 RST，会不断重发，直到超时才 CLOSE。net.ipv4.tcp_retries2 的默认值是 15，最多要等 924.6 秒……不过一般都会调小这个值。

调整参数

添加以下配置参数到 /etc/sysctl.conf 文件，最后执行 sysctl -p。

net.netfilter.nf_conntrack_icmp_timeout=10
net.netfilter.nf_conntrack_tcp_timeout_syn_recv=5
net.netfilter.nf_conntrack_tcp_timeout_syn_sent=5
net.netfilter.nf_conntrack_tcp_timeout_established=600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait=10
net.netfilter.nf_conntrack_tcp_timeout_time_wait=10
net.netfilter.nf_conntrack_tcp_timeout_close_wait=10
net.netfilter.nf_conntrack_tcp_timeout_last_ack=10

参考链接

https://testerhome.com/topics/15824
https://www.cnblogs.com/xiangsikai/p/9525287.html