这篇文章将为大家详细讲解有关如何进行Linux Netfilter调优,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
如果您正在为高流量的 Web/DNS 服务器提供服务,并且最近使该服务器 PING 丢失并且并非所有 HTTP 请求都成功。您可以开始检查系统日志。并且如果您看到类似下面的内容,那么下面的指南将帮助您调整 Linux 服务器以正确处理流量负载。
|
buckets 哈希表大小,max 最大记录的连接条数
|
哈希表使用情况
|
当前跟踪的连接数
|
跟踪连接详细信息
|
为了完成任务,NAT-server(一般指的是 iptables) 需要记录所有通过它的连接。无论是 “ping” 还是某人的 “ICQ”,NAT-server 都会记录在一个特殊的表中并跟踪所有会话。当会话关闭时,相关记录将从连接跟踪表中删除。这个记录表的大小是固定的,所以如果通过服务器的流量很大,但表太小,那么 NAT-server 就会开始丢弃数据包,中断会话。为了避免这样的麻烦,有必要适当增加连接跟踪表的大小。
最大连接跟踪数默认为 *nf_conntrack_buckets * 4*,可以通过以下命令查看当前值:
|
CONNTRACK_MAX 默认计算公式
|
其中 ARCH
为 CPU 架构,值为 32 或 64。
比如:64 位 8G 内存的机器:(8*1024^3)/16384/(64/32) = 262144
临时调整是临时性的,重启节点好配置值将会丢失。
|
要使其配置在重新启动后永久存在,需要将这些值添加到 sysctl.conf 中
|
如果服务器中的 RAM 少于 1 GB,建议不要设置太大的值。
哈希表大小是只读的,不能在 /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,内核态能用一半,只需要关心物理内存的使用情况。
计算内存使用的公式
|
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)
需要通过内核模块的方式修改:
临时生效:
|
永久生效
将以下内容添加到文件:/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
|
centos 7.8
|
以上均是以秒为单位的超时值。
对于通外网的服务器,考虑调整以下参数,减少 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
。
|
关于如何进行Linux Netfilter调优就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。