After the firewall iptable rule is enabled, the system network becomes slow

Possible reason: the conntrack table of iptables is full, which leads to slow access to the website
Phenomenon: suddenly found that the website access is very slow, and the server's cpu, memory and disk usage are normal
ip_conntrack and ns_conntrack have the same meaning, butDifferent analysis processes and solutions on the old and new versions: Query the /var/log/message log and find such a record "ip_conntrack table full dropping packet".The kernel uses the ip_conntrack module to record the status of the iptables network packets, and save it in the table (this table is in memory). If the network condition is busy, such as high connection, high concurrent connection, etc., it will gradually occupy the available space of this table. Generally, this tableIt is very large and not easy to fill up and can be cleaned up by yourself. The records of the table will stay in the table and occupy space until the source IP sends an RST packet, but if there is an attack, wrong network configuration, problematic routing/router, there is a problemWhen the network card is not connected, the RST packet sent by the source IP will not be received, so it will accumulate in the table, and the more it accumulates, the more it will be until it is full.Case.

Solution: When Iptables starts, it will prompt the current value of buckets and conntrack_max in the log and how much memory each tracking connection needs to consume:
That is to say, 304MB memory will support 1048576 tracking connection records, so it is necessary toConfigure the appropriate value according to the memory size of the server.
Permanently modify ip_conntrack_max and hashsize

1. Increase ip_conntrack_max (set to 2^20, default is 2^16=65536)
   #vi /etc/sysctl.conf
   net.ipv4.ip_conntrack_max = 1048576

2. Increase hashsize (on i386 architecture, HASHSIZE=CONNTRACK_MAX/8)
   #vi /etc/modprobe.conf
   options ip_conntrack hashsize=131072
   Then restart iptables service, in messagesYou can see that the parameters have taken effect:
   #service iptables restart

#cat /proc/sys/net/nf_conntrack_max defines the maximum value of connection tracking, it is recommended to increase this value as needed;
#cat /proc/net/nf_conntrack records all currently tracked connections
cat/proc/sys/net/netfilter/nf_conntrak_tcp_timeout_established ESTABLISHED timeout period, the default time is relatively long, it is recommended to reduce this value.
The limit of nf_conntrack connection tracking is controlled by the /proc/sys/net/nf_conntrack_max file, which can be modified or /etc/sysctl.conf/etc/sysctl.conf.
echo “65536” > /proc/sys/net/nf_conntrack_max

Possible reason 2: lack of dns related rules
iptables -I INPUT -p udp --sport 53 -j ACCEPT
iptables -I INPUT -p tcp --sport 53 -j ACCEPT

Cause 3: Routing problem https://support.huawei.com/enterprise/zh/knowledge/EKB1000059526

Reason 4: There is a lack of corresponding udp rules. For example, if there is NFS, you need to open the NFS-related udp link, otherwise the NFS link will be full, causing other links to be interrupted, resulting in slow access

https://www.liuyixiang.com/post/83843.html
https://www.haiyun.me/archives/iptables-conntrack-max.html
https://blog.51cto.com/jasonyong/280993
https://support.huawei.com/enterprise/zh/knowledge/EKB1000059526
https://www.docin.com/p-1065250766.html
https://www.163.com/dy/article/GE1TIRTL05373KLK.html
https://www.zsythink.net/archives/1493
https://www.cnblogs.com/yxh168/p/9676745.html
https://www.dandelioncloud.cn/article/details/1430922069444997121