netfilter之connnection track（连接跟踪）简述

1、什么是连接跟踪？

报文过滤和连接跟踪可以说是Netfilter提供的两大基本功能。连接跟踪可以让Netfilter知道某个特定连接的状态，运行连接跟踪的防火墙称作带有状态机制的防火墙，以下简称为状态防火墙。状态防火墙比非状态防火墙要安全，因为它允许我们编写更严密的规则。

无状态防火墙通常会查看经过它的流量，并使用诸如它的地址、来源地址和其他预定义的统计信息。这是最简单、最容易使用的防火墙类型；大多数基于软件的防火墙都使用这种技术。它不像有状态防火墙那样安全，但它通常更快，因为它不必处理太多的信息。有状态防火墙不仅可以更深入地检查数据包，消除数据包假装不是它的样子并可能造成损害的可能性，它还可以跟踪传入和传出流量的连接状态它将把信息保存在一个称为状态表的表中，这样它就可以根据更详细的信息过滤和路由流量，例如数据包的大小和它在连接进程中的哪个部分。这使得有状态防火墙更有效，因为它们不必为连接的每个部分重新检查数据包，它们只需检查状态表；这是一个更快的过程，至少出于安全目的，它们比无状态防火墙更安全，但通常速度较慢。

2、为什么需要连接跟踪？

For example：（1）当你通过浏览器访问一个网站(连接网站的80端口)时，预期会收到服务器发送的源端口为80的报文回应，防火墙自然应该放行这些回应报文。那是不是所有源端口为80端口的报文都应该放行呢？显然不是，我们只应该放行源IP为服务器地址，源端口为80的报文，而应该阻止源地址不符的报文，即使它的源端口也是80。总结一下这种情况就是，我们只应该让主动发起的连接产生的双向报文通过，那么这种功能谁来实现呢？显然就是接下来的连接跟踪。

（2）另一个例子是NAT。我们可以使用iptables配置nat表进行地址或者端口转换的规则。如果每一个报文都去查询规则，这样效率太低了，因为同一个连接的转换方式是不变的！连接跟踪提供了一种缓存解决方案：当一条连接的第一个数据包通过时查询nat表时，连接跟踪将转换方法保存下来，后续的报文只需要根据连接跟踪里保存的转换方法就可以了。

3、连接跟踪依据什么？

TCP/IP的四元组、五元组、七元组：

四元组是：源IP地址、目的IP地址、源端口、目的端口

五元组是：源IP地址、目的IP地址、协议号、源端口、目的端口

七元组是：源IP地址、目的IP地址、协议号、源端口、目的端口、服务类型以及接口索引

 例如：192.168.1.1 10000 TCP 121.14.88.76 80 就构成了一个五元组。其意义是，一个IP地址为192.168.1.1的终端通过端口10000，利用TCP协议，和IP地址为121.14.88.76，端口为80的终端进行连接。

4、报文连接跟踪状态？

途径Netfilter框架的每一个报文总是会在入口处(PRE ROUTING或者LOCAL OUT)被赋予一个连接跟踪状态。这个状态存储在skb->nfctinfo，有以下常见的取值：

• IP_CT_ESTABLISHED：这是一个属于已经建立连接的报文，Netfilter目击过两个方向都互通过报文了

• IP_CT_RELATED：这个状态的报文所处的连接与另一个IP_CT_ESTABLISHED状态的连接是有联系的。比如典型的ftp，ftp-data的连接就是ftp-control派生出来的，它就是RELATED状态

• IP_CT_NEW：这是连接的第一个包，常见的就是TCP中的SYN包，UDP、ICMP中第一个包，

• IP_CT_ESTABLISHED + IP_CT_IS_REPLY：与IP_CT_ESTABLISHED类似，但是是在回复方向

• IP_CT_RELATED + IP_CT_IS_REPLY：与IP_CT_RELATED类似，但是是在回复方向

5、连接跟踪具体分析举例

（1）TCP

 一个TCP连接是经过三次握手协商连接信息才建立起来的。整个会话由一个SYN包开始，然后是一个 SYN/ACK包，最后是一个ACK包，此时，会话才建立成功，能够发送数据。最大的问题在于连接跟踪怎样控制这个过程？

首先，在/proc/net/ip_conntrack里，可以看出，SYN_SENT状态被设置了，这说明连接已经发出一个SYN包，但应答还没发送过 来，这可从[UNREPLIED]标志看出。

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

接下来，在/proc/net/ip_conntrack里，可以看出，已经收到了相应的SYN/ACK包，状态也变为SYN_RECV，这说明最初发出的SYN包已正确传输，并 且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

最后，在/proc/net/ip_conntrack里，可以看出，现在我们发出了三步握手的最后一个包，即ACK包，连接也就进入ESTABLISHED状态了。再传输几个数据 包，连接就是[ASSURED]的了。

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 use=1

（2）UDP

UDP连接是无状态的，因为它没有任何的连接建立和关闭过程，而且大部分是无序列号的。以某个顺序收 到的两个数据包是无法确定它们的发出顺序的。但内核仍然可以对UDP连接设置状态。接下来就看看netfilter是如何跟踪UDP连接的，以及conntrack的相关记录。

首先，看看第一个UDP包发出后的conntrack记录，从前两个值可知，这是一个UDP包。第一个是协议名称，第二个是协议号，第三个是此状态的生存时间， 默认是30秒。接下来是包的源、目地址和端口，还有期待之中回应包的源、目地址和端口。[UNREPLIED]标 记说明还未收到回应。

udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
    [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
    dport=137 use=1  

然后，一旦收到第一个包的回应，[UNREPLIED]标记就会被删除，连接就被认为是ESTABLISHED的，但在记录里 并不显示ESTABLISHED标记。相应地，状态的超时时间也变为180秒了。在本例中，只剩170秒了，10秒后， 就会减少为160秒。有个东西是不可少的，虽然它可能会有些变化，就是前面提过的[ASSURED]。要想变为 [ASSURED]状态，连接上必须要再有些流量。

udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
    dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
    dport=137 use=1

最后， 可以看出来，[ASSURED]状态的记录和前面的没有多大差别，除了标记由[UNREPLIED]变成[ASSURED]。如 果这个连接持续不了180秒，那就要被中断。180秒是短了点儿，但对大部分应用足够了。只要遇到这个连接 的包穿过防火墙，超时值就会被重置为默认值，所有的状态都是这样的。

udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
    dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
    dport=1025 [ASSURED] use=1

6、总结

连接跟踪是Netfilter提供的一项基本功能，它可以保存连接的状态。用户可以为不同状态的连接的报文制定不同的策略；

连接跟踪在报文进入Netfilter的入口将信息记录在报文上，在出口进行confirm.确认后的连接信息可以影响之后的报文；

连接跟踪的信息主要包括基本的描述连接的tuple以及各协议的私有信息。

本文主要参考其它文章进行的摘抄和总结，希望可以带来更直观的帮助，如有不当，请留言指正，谢谢！

https://segmentfault.com/a/1190000019605260

连接跟踪详解_weixin_34223655的博客-CSDN博客

TCP/IP的四元组、五元组、七元组_云淡风轻-CSDN博客_五元组

https://segmentfault.com/a/1190000020654892连接跟踪（conntrack）：原理、应用及 Linux 内核实现 - 博客 - 编程圈