数据库连接池长时间不用，乍一用还用不了，结果是防火墙的锅

前言

我们的程序，在实际的网络部署时，一般比较复杂，会经过很多的网络设备，防火墙就是其中的一种。做开发的同事，一般对这块了解不多，也很可能被防火墙坑到。比如，应用一般需要访问数据库，为了避免频繁建立连接，一般是会提前建立一个连接池，每次来一个请求，就从连接池取一个连接来用，用完再归还到池子里。

连接池中的连接是啥呢，其实就是和数据库之间的完成了三次握手后的socket，这个socket在白天时，一般经常有数据传输，而到了凌晨这种，可能就很少数据传输，等到了第二天，某个请求来了，从池子里取了某个socket，就直接发送数据，此时，很可能就会出现一个read timeout的情况。

为啥呢，是数据库不返回数据吗？不一定，如果应用服务器和db服务器之间，经过了防火墙的话，很可能，你这个socket发出去的包，直接就防火墙给丢弃了，根本没有到达数据库。如果想搜索这块相关的案例，可以搜索“防火墙长连接”关键字。

状态防火墙(stateful firewall)

现在的防火墙，基本都是有状态的，什么叫做有状态呢？以tcp为例，当服务端收到第一次握手（syn）时，此时，会认为这是要新建立连接，当三次握手完成后，再收到客户端在该socket上发来的请求报文时，此时，就知道这个报文不再是要新建立连接了，socket的状态此时也是established。说白了，握手时候的报文和握手完成后的报文，是不一样的，我们是可以区别对待的，这就是通俗意义上的“有状态”。

而在此之前，都是无状态防火墙（stateless firewall），不管是什么报文，都是一视同仁，没法根据状态来区分处理。

接下来，我们可以以iptables为例，理解下状态防火墙（iptables就是典型的状态防火墙）。

iptables中的状态

该部分参考官网：https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE

iptables是用户态中的命令，在内核中由netfilter实现，netfilter中实现连接的状态跟踪的机制，叫做conntrack（connection track）。在这个机制中，一共定义了4种状态：NEW, ESTABLISHED, RELATED，INVALID，UNTRACKED。

注意这里的conntrack，中文就是连接追踪，既然是连接，那么，我们怎么区分一个连接呢，比如，在tcp中，就是依靠四元组，这个四元组就可以唯一标识一个连接。

我们可以定义一个hash表，在收到一个tcp报文时，检查下这个四元组在hash表中是否存在（key就是四元组），如果不存在，我们就可以认为这个报文此时是新来的，也就是状态是new；当我们收到服务端返回的报文时，我们又可以检测下四元组在本地hash表是否存在，发现已经存在了，此时就可以认为状态是established。

这里大家如果要看这个状态的详细解释，可以查看官网文档；另外，我发现一篇文章也不错：

https://mp.weixin.qq.com/s/kv32lyWak4dCaPjMI4_6jw

NEW：
新建连接请求的数据包，且该数据包没有和任何已有连接相关联。 判断的依据是conntrack当前“只看到一个方向数据包(UNREPLIED)”，没有回包。
ESTABLISHED：
该连接是某NEW状态连接的回包，也就是完成了连接的双向关联。

其他几种状态，RELATED和INVALID我感觉一般比较少用，至于UNTRACKED ，可以等后续再慢慢领悟。

实际感受状态变化

客户端首次握手（syn）

可以通过cat /proc/net/nf_conntrack查看连接状态。

如收到首次握手请求后，会看到如下内容：

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1

各个字段的意思：

tcp，协议名
6，传输层协议代号，其中tcp是6，udp是17,
117，ttl，表示这个conntrack的过期时间，类似于redis里的key的ttl
SYN_SENT，socket此时的状态。官方：The value SYN_SENT tells us that we are looking at a connection that has only seen a TCP SYN packet in one direction
src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23部分：

the source IP address, destination IP address, source port and destination port
UNREPLIED（未回复）

we have seen no return traffic for this connection，表示我们还没看到回包，现在只有单方向的包
src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031

这是我们期待的回包的样子

服务端返回syn+ack

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1

收到syn+ack后，此时，我们的状态由SYN_SENT变成SYN_RECV，此时，也移除了之前的UNREPLIED关键字

客户端第三次握手 ack

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 [ASSURED] use=1

状态变成ESTABLISHED，增加了关键字：ASSURED

其他

涉及到socket关闭的部分，导致的状态变化请参考官方文档：https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#STATEMACHINE

简单来说，就是两边都完成关闭，状态才变成closed。

状态标记发生的阶段

我们上面可以看到在一个connection上状态的变化，说白了，这部分就是给一个报文打上标记，关于状态的标记，后续我们才能基于这个状态label进行匹配。

所以，我们对于这个标记发生的时间，需要特别注意，可以看下，下图的左上角的绿色方块（connection tracking）就是状态标记发生的位置，基本上是最前面了（最上面是网卡，再下来是raw，再下来就是connection tracking了）。

在这个绿色方块执行完成后，状态就已经标记好了，我们就可以根据状态来匹配这些报文来进行accept或者drop了，具体看下文。

4515962123a9190c28252a1d8dbedc4

iptables模拟长连接超时后继续使用该连接的场景

部署图

我们的两台机器如下：

服务器：10.0.2.15:2222，监听2222端口

客户端：10.0.2.4

iptables配置

放行第一次握手请求

三次握手的报文都需要放行，第一次握手请求的特征是，此时，根据前面我们讲的状态，第一次握手到来时，本地是找不到该四元组的，所以state是new，再加上目的端口是2222，因此，我们的匹配条件是：

--dport 2222 -m state --state NEW，因此，命令如下：

iptables -I INPUT 4 -p tcp --dport 2222 -m state --state NEW -j ACCEPT

放行第二次、第三次握手请求

此时，马上会收到2222端口返回的syn + ack，此时，状态就会变成established。

这种报文的特征是，state为established，这种怎么放心呢，这种其实默认就放心了，不需要我们再干啥。

第三次请求，也是同理，状态会被标记为established。

等待conntrack记录过期或手动删除、清空

我们这边就需要模拟连接建立后，等conntrack记录过期后，客户端再使用这个socket会发生什么。

那么，我们怎么来查看这些conntrack呢，需要安装工具：yum install conntrack-tools

查看hash表
[root@node1 ~]# conntrack -L
tcp      6 431997 ESTABLISHED src=10.0.2.2 dst=10.0.2.15 sport=9526 dport=22 src=10.0.2.15 dst=10.0.2.2 sport=22 dport=9526 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1

我们可以看到过期时间为431997，单位是秒，差不多是5天。这个初始值是432000，来自于内核参数：net.netfilter.nf_conntrack_tcp_timeout_established :

[root@node1 ~]# sysctl -a |grep net.netfilter.nf_conntrack_tcp_timeout_established
net.netfilter.nf_conntrack_tcp_timeout_established = 432000

我们测试的话，这个时间就太长了，我们可以修改这个内核参数进行设置。我们可以改成60s过期：

[root@node1 ~]# vim /etc/sysctl.conf
net.netfilter.nf_conntrack_tcp_timeout_established = 60

执行sysctl -p

我们也可以选择手动删除、清空这些conntrack记录：

删除目标端口为2222的记录：
conntrack -D -p tcp --dport 2222

清空整个hash表
conntrack -F

实时监控hash表的变动（增删改）
conntrack -E

丢弃客户端在长时间空闲的长连接上发过来的包

由于我们上一步执行了conntrack记录删除，此时，客户端发的报文，在iptables看来，又是全新的四元组，也就是会把状态标记为new，但是，这种请求报文和握手报文明显不同，这种报文的tcp层一般会设置psh标记，握手请求里则会设置syn等，所以，我们按照这个进行区分。

匹配条件为：--dport 2222 -m state --state NEW -m tcp --tcp-flags PSH PSH，动作为丢弃：drop

iptables -I INPUT 4 -p tcp --dport 2222 -m state --state NEW -m tcp  --tcp-flags PSH PSH  -j DROP

ok，接下来开始测试。

最终的iptables效果

实际测试

用到了该博客中的客户端、服务端程序：

https://blog.csdn.net/fengcai_ke/article/details/125717134

server.c，主要是监听2222端口；client.c，就是连接并发送请求。

服务端发起监听，客户端发起连接，完成三次握手：

[root@node1 ~]# ./server 

[root@node2 ~]# ./client 
please input:

此时，可以看到三次握手：

服务端的conntrack -E，也可以看到hash表的变化：

[root@node1 ~]# conntrack -E
    [NEW] tcp      6 120 SYN_SENT src=10.0.2.4 dst=10.0.2.15 sport=46216 dport=2222 [UNREPLIED] src=10.0.2.15 dst=10.0.2.4 sport=2222 dport=46216
 [UPDATE] tcp      6 60 SYN_RECV src=10.0.2.4 dst=10.0.2.15 sport=46216 dport=2222 src=10.0.2.15 dst=10.0.2.4 sport=2222 dport=46216
 [UPDATE] tcp      6 432000 ESTABLISHED src=10.0.2.4 dst=10.0.2.15 sport=46216 dport=2222 src=10.0.2.15 dst=10.0.2.4 sport=2222 dport=46216 [ASSURED]

可以看到established的conntrack：

[root@node1 ~]# conntrack -L|grep 2222
conntrack v1.4.4 (conntrack-tools): 5 flow entries have been shown.
tcp      6 431857 ESTABLISHED src=10.0.2.4 dst=10.0.2.15 sport=46216 dport=2222 src=10.0.2.15 dst=10.0.2.4 sport=2222 dport=46216 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1

接下来，删除conntrack记录：

删除记录：
[root@node1 ~]# conntrack -D -p tcp --dport 2222
tcp      6 431800 ESTABLISHED src=10.0.2.4 dst=10.0.2.15 sport=46216 dport=2222 src=10.0.2.15 dst=10.0.2.4 sport=2222 dport=46216 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
conntrack v1.4.4 (conntrack-tools): 1 flow entries have been deleted.
查询：
[root@node1 ~]# conntrack -L|grep 2222
conntrack v1.4.4 (conntrack-tools): 4 flow entries have been shown.

客户端使用该socket发起请求：

[root@node2 ~]# ./client 
please input:11
send result
: Success

可以看到，服务端2222，没回复，客户端一直重传：

观察iptables，可以发现，确实匹配上了drop那条：

参考

https://blog.csdn.net/fengcai_ke/article/details/125717134

https://blog.csdn.net/weixin_46768610/article/details/109354433

https://www.cnblogs.com/saolv/p/13096965.html