,," /> " />

目 录CONTENT

文章目录

网络连接数:CT

Administrator
2024-02-18 / 0 评论 / 0 点赞 / 11 阅读 / 19647 字

问题

服务器负载正常,当请求量稍微大时就出现超时现象,服务器上面看不到请求日志,但通过dmesg 或 cat var/log/messages 发现看到大量内核错误日志如下:

kernel: nf_conntrack: table full, dropping packet.

2.6.15 之前的版本,Linux 内核抛出:

ip_conntrack: table full, dropping packet.

本文主要从 nf_conntrack 的角度来总结,而ip_conntrack 只有较老的内核版本才单独支持。

连接跟踪


先说下上面问题的原因,当访问量大时,内核 netfilter 模块 conntrack 相关参数配置不合理,导致 IP 包被丢掉,连接无法建立时,就会报上面的错误,后面给出相关参数配置,那么什么是 连接跟踪状态呢?

conntrack 就是跟踪并且记录连接的状态,Linux 为每一个经过网络堆栈的数据包,生成一个新的连接记录项(Connection entry),此后,所有属于此连接的数据包都被唯一地分配给这个连接,并标识连接的状态,连接跟踪是防火墙模块的状态检测的基础,同时也是地址转换中实 现SNAT和DNAT的前提

注意 nf_conntrack 模块在 kernel 2.6.15 被引入,支持 IPv4 和 IPv6,取代之前只支持 IPv4 的 ip_connktrack,它主要用来跟踪连接的状态,方便一些问题的定位。

如果 Linux 服务器上面需要使用 NAT 功能,可以使用它记录一些连接跟踪的状态,比如经常使用 iptables 的 NAT 功能 。

NAT 即根据转发规则修改 IP 包的源/目标地址,靠 conntrack 记录才能让返回的数据包能路由到发送请求的机器上面,经常使用的地址伪装功能。

连接跟踪是由 iptables 的 state 选项来实现的,它可以记录并检测每个连接的状态并在内存中维护一个跟踪状态表,这个表即连接跟踪状态表。

state:这个模块能够跟踪每个分组的连接状态,通过它把连接状态记录到 conntrack 表中(连接跟踪状态表)。

状态选项含义
INVALID表示分组对应的连接是未知的;
ESTABLISHED表示分组对应的连接已经进行了双向分组传输,也就是说连接已经建立;
NEW表示这个分组需要发起一个连接,或者说,分组对应的连接在两个方向上都没有进行过分组传输;
RELATED表示分组要发起一个新的连接,但这个连接和一个现有的连接有关;例如:FTP 的数据传输连接和控制连接之间就是 RELATED 关系。

接跟踪状态如何工作

我们知道 Linux 服务器的每个数据包分组将以以下的顺序:PREROUTING -- FORWARD -- POSTROUTING 。

企业微信截图_20240218100304.png

(图片来源于网络)

先经过 PREROUTING 链,此时如果必要的话,就对这个分组进行目的网络地址转换 (DNAT) 和 mangle 处理,同时, iptables 的状态检测机制将重组分组,并且以以下某种方式跟踪其状态:

\1. 分组是否匹配状态表中的一个已经实现 (ESTABLISHED) 的连接;

\2. 分组是否是和状态表中某个 UDP/TCP 连接相关(RELATED) 的一个 ICMP 分组;

\3. 分组是否为发起的新 (NEW) 连接;

\4. 如果分组和任何连接状态选项无关,就被认为是无效(INVALID)的。

再经过 FORWARD 链把分组的状态和过滤表中的规则进行匹配,如果分组状态与相应规则都无法匹 配,就使用默认的策略进行处理;

最后 POSTROUTING 链如果有必要的话,就会对分组进行源网络地址转换(SNAT)等。

数据包分组都必须和过滤表的规则进行匹配比较,如果规则进行了修改,要拒绝所有的网络流量,那么即使数据包的分组状态匹配状态表中的某一个,如:ESTABLISHED,那么连接状态跟踪表中,也不会被记录,也将被拒之门外。

安装查看连接跟踪状态工具

yum -y install conntrack

注意需要先开启记录功能才可以使用连接跟踪表,默认是没有开启的,下面我们对 TCP 、UDP、ICMP 三个协议分别进行分析。

TCP 实验分析


TCP 开启连接状态跟踪

[root@vm-os-centos7 ~]# iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
[root@vm-os-centos7 ~]# iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

TCP 测试

[root@vm-os-centos7 ~]# curl http://www.baidu.com
<!DOCTYPE html>
<!--STATUS OK--><html> <head><meta http-equiv=content-type content=text/html;charset=utf-8><meta http-equiv=X-UA-Compatible content=IE=Edge><meta content=always name=referrer><link rel=stylesheet type=text/css href=http://s1.bdstatic.com/r/www/cache/bdorz/baidu.min.css><title>百度一下,你就知道</title></head> <body link=#0000cc> <div id=wrapper> <div id=head> <div class=head_wrapper> <div class=s_form> <div class=s_form_wrapper> <div id=lg> <img hidefocus=true src=//www.baidu.com/img/bd_logo1.png width=270 height=129> </div> <form id=form name=f action=//www.baidu.com/s class=fm> <input type=hidden name=bdorz_come value=1> <input type=hidden name=ie value=utf-8> <input type=hidden name=f value=8> <input type=hidden name=rsv_bp value=1> <input type=hidden name=rsv_idx value=1> <input type=hidden name=tn value=baidu><span class="bg s_ipt_wr"><input id=kw name=wd class=s_ipt value maxlength=255 autocomplete=off autofocus></span><span class="bg s_btn_wr"><input type=submit id=su value=百度一下 class="bg s_btn"></span> </form> </div> </div> <div id=u1> <a href=http://news.baidu.com name=tj_trnews class=mnav>新闻</a> <a href=http://www.hao123.com name=tj_trhao123 class=mnav>hao123</a> <a href=http://map.baidu.com name=tj_trmap class=mnav>地图</a> <a href=http://v.baidu.com name=tj_trvideo class=mnav>视频</a> <a href=http://tieba.baidu.com name=tj_trtieba class=mnav>贴吧</a> <noscript> <a href=http://www.baidu.com/bdorz/login.gif?login&amp;tpl=mn&amp;u=http%3A%2F%2Fwww.baidu.com%2f%3fbdorz_come%3d1 name=tj_login class=lb>登录</a> </noscript> <script>document.write('<a href="http://www.baidu.com/bdorz/login.gif?login&tpl=mn&u='+ encodeURIComponent(window.location.href+ (window.location.search === "" ? "?" : "&")+ "bdorz_come=1")+ '" name="tj_login" class="lb">登录</a>');</script> <a href=//www.baidu.com/more/ name=tj_briicon class=bri style="display: block;">更多产品</a> </div> </div> </div> <div id=ftCon> <div id=ftConw> <p id=lh> <a href=http://home.baidu.com>关于百度</a> <a href=http://ir.baidu.com>About Baidu</a> </p> <p id=cp>&copy;2017&nbsp;Baidu&nbsp;<a href=http://www.baidu.com/duty/>使用百度前必读</a>&nbsp; <a href=http://jianyi.baidu.com/ class=cp-feedback>意见反馈</a>&nbsp;京ICP证030173号&nbsp; <img src=//www.baidu.com/img/gs.gif> </p> </div> </div> </div> </body> </html>
[root@vm-os-centos7 ~]#

TCP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp
    [NEW] tcp 6 120 SYN_SENT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770
 [UPDATE] tcp 6 60 SYN_RECV src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770
 [UPDATE] tcp 6 432000 ESTABLISHED src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 120 FIN_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 60 CLOSE_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 30 LAST_ACK src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
 [UPDATE] tcp 6 120 TIME_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]
。。。

连接的协议是 TCP (TCP 协议号 6),第四列是一个倒计时的秒数,是超时时间,接下来是当前时间点的状态,然后是请求方向上的源、目的地址和源、目的端口,响应方向上的源、目的地址和源、目的端口。

第一行 NEW 代表初始请求进入 OUTPUT 链,并且规则允许通过,此时就记录在这个连接跟踪表中,TCP 连接状态是 SYN_SENT,连接被标记为 UNREPLIED。[UNREPLIED] 表示这个连接还没有收到任何回应。

三次握手与连接跟踪状态分析

TCP 协议是有状态的协议,并且具有很多关于 iptables 状态机制的详细信息。

首先,客户端程序发出一个同步请求(发出一个 SYN 分组),初始 SYN 分组进入到OUTPUT链,并且防火樯规则允许这个分组通过,所以状态表项为:

[NEW] tcp 6 120 SYN_SENT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770

TCP 连接状态是 SYN_SENT,连接被标记为 UNREPLIED。

其次,服务器端回应一个 SYN|ACK 分组,客户端一旦得到响应,这个TCP连接表项变为:

[UPDATE] tcp 6 60 SYN_RECV src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770

连接的状态变为 SYN_RECV,UNREPLIED 标志被清除。

最后,客户端返回一个ACK 分组,完成三次握手的过程,ACK 分组到达后,我们首先对其序

列号进行一些检查,如果正确,就把这个连接的状态变为 ESTABLISHED,并且使

用 ASSURED 标记这个连接,如下:

[UPDATE] tcp 6 432000 ESTABLISHED src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

四次挥手与连接跟踪状态分析

首先. 客户端发送了 FIN 后,客户端连接跟踪状态就变为了FIN_WAIT,如下:

[UPDATE] tcp 6 120 FIN_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

其次. 当客户端收到对方的ACK后,客户端连接跟踪状态变为了 CLOSE_WAIT,如下:

[UPDATE] tcp 6 60 CLOSE_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

再次. 当客户端再次收到对方的FIN时,客户端连接跟踪状态变为了LAST_ACK,如下:

[UPDATE] tcp 6 30 LAST_ACK src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

最后. 客户端发送最后的ACK后,客户端连接跟踪状态变为了TIME_WAIT。

[UPDATE] tcp 6 120 TIME_WAIT src=100.73.18.153 dst=180.101.49.12 sport=32770 dport=80 src=180.101.49.12 dst=100.73.18.153 sport=80 dport=32770 [ASSURED]

连接关闭后,主动关闭方(这里用例客户端)进入 TIME_WAIT 状态,缺省时间是2MSL(报文最大生存时间,2分钟),是为了让数据包能完全通过各种规则的检查,并且网络正常,不阻塞的情况下到达对方。为什么是2MSL?1. 最后一个ACK发出去之后,服务器端在超时时间内未收到,会重新发送 FIN,客户端再发送 ACK;2. 如果客户端没有TIME_WAIT状态,客户端直接进入CLOSE,客户端之前使用的源端口,就被释放掉,很有可能客户端的端口被新连接再次使用,此时如果先前发送的 ACK 在网络链路上面丢了,服务器端重新发送了FIN,会造成客户端异常关闭连接,所以TIME_WAIT必须存在

如果连接是被RST包重置的,就直接变为CLOSE了。这意味着在关闭之前只有10秒的默认时间,RST包是不需要确认的,它会直接关闭连接。

UDP 实验分析


UDP 开启连接状态跟踪

[root@vm-os-centos7 ~]# iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
[root@vm-os-centos7 ~]# iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT

UDP 测试

[root@vm-os-centos7 ~]# dig -t A www.baidu.com @114.114.114.114

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> -t A www.baidu.com @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63201
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.baidu.com.INA

;; ANSWER SECTION:
www.baidu.com.543INCNAMEwww.a.shifen.com.
www.a.shifen.com.214INA180.101.49.11
www.a.shifen.com.214INA180.101.49.12

;; Query time: 25 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: 四 8月 20 11:18:06 CST 2020
;; MSG SIZE rcvd: 101

[root@vm-os-centos7 ~]#

UDP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp
    [NEW] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 [UNREPLIED] src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
 [UPDATE] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
[DESTROY] udp 17 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768
。。。

UDP 连接跟踪状态分析

UDP (用户数据包协议)是一种无状态协议,虽然协议没有序列号,但是我们还可以使用其它的一些信息跟踪 UDP 连接的状态。

第一行,UDP 代表UDP协议,17 是 UDP 协议编号,30是超时时间,单位是秒,接下来是请求方向上的源、目的地址和源、目的端口,响应方向上的源、目的地址和源、目的端口,这个连接使用 UNREPLIED 标记,表示还没有收到应答;

[NEW] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 [UNREPLIED] src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

注意一个UDP请求应答的时间是30秒,如果在这个时间内没有收到下面的应答响应,这个表项就会被删除,一旦收到第一个包的回应,[UNREPLIED]标记就会被删除,连接就被认为是 ESTABLISHED 的,但在记录里并不显示ESTABLISHED标记。

[UPDATE] udp 17 30 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

接收到数据后,此连接就此销毁,如下:

[DESTROY] udp 17 src=100.73.18.153 dst=114.114.114.114 sport=32768 dport=53 src=114.114.114.114 dst=100.73.18.153 sport=53 dport=32768

ICMP 实验分析


ICMP 开启连****接状态跟踪

[root@vm-os-centos7 ~]# iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED, RELATED
-j ACCEPT
[root@vm-os-centos7 ~]# iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j
ACCEPT

ICMP 测试

[root@vm-os-centos7 ~]# ping -c 3 www.baidu.com
PING www.baidu.com (180.101.49.12) 56(84) bytes of data.
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=1 ttl=50 time=25.8 ms
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=2 ttl=50 time=26.3 ms
64 bytes from www.baidu.com (180.101.49.12): icmp_seq=3 ttl=50 time=25.6 ms

--- www.baidu.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 25.622/25.931/26.305/0.338 ms
[root@vm-os-centos7 ~]#

ICMP 连接跟踪查看

[root@vm-os-centos7 ~]# conntrack -E -o ktimestamp|grep 180.101.49.12
    [NEW] icmp 1 30 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 [UNREPLIED] src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
 [UPDATE] icmp 1 29 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
[DESTROY] icmp 1 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18840 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18840
[DESTROY] icmp 1 src=100.73.18.153 dst=180.101.49.12 type=8 code=0 id=18849 src=180.101.49.12 dst=100.73.18.153 type=0 code=0 id=18849
。。。
[root@vm-os-centos7 ~]#

ICP 连接跟踪分析

ICMP 也是一种无状态协议,它只是用来控制而不是建立连接。

ICMP 包有很多类型,但只有四种类型有应答包,它们是回显请求和应答(Echo request and reply),时间戳请求和应答(Timestamp request and reply)(这种类型已经废除),信息请求和应答(Information request and reply),还有地址掩码请求和应答(Address mask request and reply),这些包有两种状态,NEW和ESTABLISHED ,回显请求是经常使用的,比如ping命令就用的到,地址掩码请求也有时会使用。

连接跟踪查看


查看方式

/proc/net/nf_conntrack 文件中的内容与使用 conntrack 命令是一样的:

conntrack -L -o extended 或cat proc/net/nf_conntrack

网络层协议名、网络层协议编号、传输层协议名、传输层协议编号、记录失效前剩余秒数、连接状态(不是所有协议都有),[ASSURED] 代表请求和响应都有流量, [UNREPLIED] 表示没收到响应,哈希表满的时候这些连接先扔掉,下面几种常用查看方式,都给出两种查看方式,并且结果是一样的。

TCP/UDP 连接数统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{sum[$3]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '{sum[$3]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2752 flow entries have been shown.
udp 121
tcp 2631
-----------
udp 121
tcp 2631
[root@k8s-master-1 ~]#

TCP 连接状态统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '/^.*tcp.*$/ {sum[$6]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2115 flow entries have been shown.
CLOSE_WAIT 11
CLOSE 18
ESTABLISHED 1401
SYN_SENT 13
TIME_WAIT 496
-----------
CLOSE_WAIT 11
CLOSE 18
ESTABLISHED 1401
SYN_SENT 13
TIME_WAIT 496
[root@k8s-master-1 ~]#

IP层协议统计

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{sum[$1]++} END {for(i in sum) print i, sum[i]}' && echo "-----------" && cat proc/net/nf_conntrack | awk '{sum[$1]++} END {for(i in sum) print i, sum[i]}'
conntrack v1.4.4 (conntrack-tools): 2822 flow entries have been shown.
ipv4 2822
-----------
ipv4 2822
[root@k8s-master-1 ~]#

连接数最多的10个IP

[root@k8s-master-1 ~]# conntrack -L -o extended | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10 && echo "-----------" && cat proc/net/nf_conntrack | awk '{print $7}' | cut -d "=" -f 2 | sort | uniq -c | sort -nr | head -n 10
conntrack v1.4.4 (conntrack-tools): 2821 flow entries have been shown.
    385 100.72.16.4
    149 100.71.57.51
    149 100.71.57.21
    149 100.71.57.14
    148 100.71.57.46
    148 100.71.57.31
    142 127.0.0.1
    139 100.71.57.62
    134 100.71.57.57
    119 100.72.128.2
-----------
    385 100.72.16.4
    149 100.71.57.51
    149 100.71.57.21
    149 100.71.57.14
    148 100.71.57.46
    148 100.71.57.31
    142 127.0.0.1
    139 100.71.57.62
    134 100.71.57.57
    119 100.72.128.2
[root@k8s-master-1 ~]#

参数详情


回到文章的开头,当 Linux 内核报 nf_conntrack: table full, dropping packet. 错误时,这是因为服务器开启了 iptables 防火墙并设置了连接状态跟踪,当服务器收到大量的连接时,iptables 会把所有的连接都做链接跟踪处理,iptables 它会产生一个链接状态跟踪表,当这个表满时,就会出现上面的错误,可以通过修改以下参数解决。

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_tcp_timeout_established
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
[root@vm-os-centos7 ~]# sysctl -a |grep net.nf_conntrack_max
net.nf_conntrack_max = 262144
[root@vm-os-centos7 ~]#

上面的nf_conntrack_tcp_timeout_established 默认是5天(432000/86400=5),建议修改小一些,比如1天或者10个小时36000秒,这种状态多的话,会占用端口和连接数;net.nf_conntrack_max 状态表满时,及时调整这个值即可,下面这些都是连接跟踪中的TCP状态的超时参数,可以根据需要进行设置;

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_tcp_timeout
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
[root@vm-os-centos7 ~]#

下面是udp及icmp的超时参数,如有需要,也可以自行调整。

[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_udp_timeout
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
[root@vm-os-centos7 ~]# sysctl -a |grep net.netfilter.nf_conntrack_icmp_timeout
net.netfilter.nf_conntrack_icmp_timeout = 30
[root@vm-os-centos7 ~]#
0
  1. 支付宝打赏

    qrcode alipay
  2. 微信打赏

    qrcode weixin

评论区