Linux内核那些事之连接跟踪

红太狼 2023-01-05 12:08 369阅读 0赞

**“** 本文分析了Linux内核连接跟踪的关键实现**”**

连接跟踪（也叫会话管理）是状态防火墙关键核心，也是很多网元设备必不可少的一部分。各厂商的实现原理基本雷同，只是根据各自的业务进行修改和优化。其中，还有不少厂商干脆是基于Linux内核实现的。下面，我们就来看看Linux内核中连接跟踪的几个要点。

注：本文对应的Linux源码为最新的5.9.12

基础知识

1.  一个连接由两个tuple组成，分别代表两个方向的报文信息。
2.  一个tuple一般由报文的五元组构成，分别是源地址、目的地址，源端口、目的端口和协议号（四层）。
3.  连接跟踪表一般为hash表。该表可能是全局的，也可能是per cpu的，Linux内核选择的是全局表。
4.  每个连接根据自己的状态，都有自己的生命周期，到期会销毁。
5.  网元设备一般会在连接中增加扩展，来实现带状态的业务。

—

连接跟踪的匹配和创建

对于拥有连接跟踪的网元设备来说，数据报文一定是先尝试匹配已有连接，如果找到对应的连接则报文属于该连接，如果没有找到，则创建新连接。所以，连接的匹配和创建一般都是相邻的。

nf\_conntrack\_in是连接匹配的入口函数，其会被netfitler处理brdige（etables）、ipv4和ipv6的hook函数调用。

在nf\_conntrack\_in中，

![图片][7ae770d1804ed6cbaa78391fd2d890d8.png]

这里先调用get\_l4proto，根据三层协议获取四层协议号和数据偏移。然后，调用resolve\_normal\_ct进行连接的匹配和创建。

在resolve\_normal\_ct中，

![图片][792b99a085e1fc7e9fe7ee5407626089.png]

首先调用nf\_ct\_get\_tuple根据报文生成这个方向的tuple，然后调用\_\_nf\_conntrack\_find\_get通过tuple进行连接的查找。如果没有找到，则调用init\_conntrack生成新的连接。

也许有的同学会有疑问，在基础知识小节中，tuple是包含源端口和目的端口。那么如果报文不是UDP或者TCP，没有源端口和目的端口怎么办？答案很简单，内核会根据4层协议使用不同字段来填充tuple。在nf\_ct\_get\_tuple中，有如下代码：

![图片][4f1bc003e28eda89531c71460e2a8965.png]

以ICMP报文为例，见icmp\_pkt\_to\_tuple

![图片][9b3343fc299a10325a24708b5909ec73.png]

所以tuple的五元组只是一种粗略说法，实际上内核会根据不同协议填充不同字段。因为tuple的匹配时包含4层协议号本身，所以这样做完全没有问题。

连接的查找比较简单，根据tuple确定hash桶，然后遍历桶中元素查找拥有相等tuple的连接。

![图片][d17df0ae6a689f5bd3d0098699920eaf.png]

连接的创建同样简单，在init\_conntrack中，

![图片][a2767e5995b6cd9cb41e266a024976b3.png]

首先调用\_\_nf\_conntrack\_alloc申请一块conntrack的内存，然后在根据需求增加相应的扩展（extension），如这里的timeout\_ext，acct\_ext，tstamp\_ext等等。在很多厂商的实现中，都会把自己的业务数据直接保存在conntrack结构中，这就造成了conntrack的结构越来越大，且会保存一些没有必要的数据。比如一共有三个业务功能的数据保存在conntrack中，但实际上用户只使用了功能1，结果功能2和功能3虽然没有使用，但依然占用了内存。同时，越来越大的conntrack结构也越来越难以维护。Linux内核最早也是采取的这种方式（简单直接），后来其抽象了nf\_ct\_ext结构用于做业务扩展。conntrack不再直接保存扩展数据，当业务扩展被启用时，会动态申请nf\_ct\_ext，并追加到conntrack的扩展结构中。

因为本文只讨论连接跟踪，所以在此不细述conntrack的extension了。以后有机会再和大家分享这块儿内容。

在init\_conntrack中的结尾，还有一块儿代码值得大家注意：

![图片][40bef7168415867b665d05ba2876d756.png]

前两个语句，增加了conntrack的引用计数，然后将conntrack添加到unconfirmed\_list中。

![图片][cdb6de58d8ef9a47d4cbec85785ab53b.png]

这里的unconfirmed list是一个per cpu 变量。

—

连接如何插入全局连接跟踪表

前一节中，我们看到了内核创建了一个新的连接conntrack，并将其插入到unconfirmed list中。那么为什么不直接将其插入到全局连接跟踪表中呢？其原因有二：

1.  在基础知识一节中，我们提到一个conntrack有两个tuple。当我们创建conntrack时，实际上只有一个方向的报文，也就只能够生成这个方向的tuple。虽然我们可以根据tuple的定义，将当前方向的tuple做个反向处理来得到反向tuple。但这里会有一个问题，当有NAT规则时，此时此刻我们并不知道后面会如何进行NAT处理，生成的反向tuple自然不正确。那么，是否可以先插入一个tuple呢？答案也是否定的。这可能会引发并发竞争的问题。试想，一个连接的两个方向的报文，有可能由两个CPU进行处理，他们都根据当前报文生成了conntrack和tuple并插入到全局表中。这就意味着同一个连接被插入表两次，自然是一个错误。如果要增加这种情况的检查，逻辑会更加复杂。
2.  在创建连接的时候，属于比较早期的阶段，很有可能在后面的处理中报文会被丢弃，比如命中了防火墙drop规则等等。如果先把连接插入了全局表，到时候还要进行删除处理，这无疑是一种浪费。Linux内核会在最后阶段，才会把连接插入到全局表中。

基于以上原因，Linux内核会在最后时刻才会将新建的conntrack插入到全局表中。那么这个最后的时刻是什么时候呢？Linux内核的连接跟踪是由netfilter模块的功能，而netfilter的原理主要是通过五个阶段（prerouting、forward、postrouting、localin和localout），并在每个阶段根据优先级执行hook函数或者规则。关于这块儿的资料已经很多，在此不做重复说明。

以IPv4报文为例，

![20210112093410871.gif][]

其分别在postrouting和localin两个阶段，以优先级NF\_IP\_PRI\_CONNTRACK\_CONFIRM（INT\_MAX）来调用hook函数ipv4\_confirm。这就保证了无论是转发的，本机发出的（最后也会走到postrouting），还是发给本机的，都会在最后阶段（也就是即将离开netfilter模块）时执行ipv4\_confirm。而ipv4\_confirm经过层层还是会最终调用到\_\_nf\_conntrack\_confirm，其负责将conntrack插入到全局表中。

前文说过，一个连接有两个tuple，根据不同tuple计算的hash bucket自然也不同，也就是说，内核需要将conntrack插入到了两个bucket中。前面在\_\_nf\_conntrack\_find\_get中进行连接查找匹配时，使用的是rcu\_read\_lock进行保护。现在要进行插入操作（写操作），自然要使用锁了。在老版本内核中，全局连接表的写入操作使用了全局唯一一个spinlock，这无疑降低并发性能。后来内核对此做了改进，使用了CONNTRACK\_LOCKS（1024）个锁，来减小锁的粒度。

对于一个连接涉及两把锁的时候，就需要注意上锁的顺序，不然就会引起死锁。比如连接1上锁顺序是lock A，lock B，而连接2上锁顺序则是lock B，lock A。当连接1持有了lock A，然后尝试获取lock B，连接2持有了lock B，然后尝试获取lock A。这时，两个CPU就陷入了死锁状态。为了避免这种问题，就需要保证上锁的顺序，即使是不同连接，也要使用同一个顺序上锁。为此，内核特意封装了一个函数解决这一问题。

![图片][48c5cc72c3845e40ac69fe4c3903d193.png]

上面代码中h1和h2分别对应conntrack两个tuple计算的hash值，分别与CONNTRACK\_LOCKS进行模操作得到两个锁的索引。然后比较h1和h2，永远保证先对索引小的lock进行上锁，然后再锁索引大的lock。其中特殊情况是两个锁索引相同时，那么只锁一次。

然后先检查是否已经有CPU插入了相同连接，

![图片][d3da9abb8ea50c0c7798ff8b648cd214.png]

如果两个tuple中的任何一个已经被插入，则认为已有CPU插入了相同连接，则放弃当前连接的插入。

通过一系列检查后，\_\_nf\_conntrack\_confirm调用\_\_nf\_conntrack\_hash\_insert把conntrack两个tuple插入到全局表中。

—

连接跟踪的生命周期

如何处理淘汰（或者叫做删除）过期连接，最直接的做法就是为每个连接增加一个定时器，定时器过期时间即为连接的生命周期。早期内核版本也是采取的这一方式。但随着支持的并发连接数量的增多，过期timer的数量也成为了一个巨大的值。这种海量的timer，对timer机制是一个挑战，同时每个timer（struct timer\_list）会占用80个字节（x86\_64)。在海量的连接下，定时器内存的消耗也不容忽视。于是，内核做了一个优化，使用了一个u32 变量timeout作为conntrack的过期时间。但是，没有了定时器触发，如何判定conntrack过期呢？

首先，在nf\_conntrack\_in函数中调用nf\_conntrack\_handle\_packet根据不同协议处理报文，更新连接状态。以TCP报文为例，会调用nf\_conntrack\_tcp\_packet进行处理。

![图片][95a96c04829b6de1d3f3d3c05bbbc81b.png]

这里根据不同的TCP状态确定不同的timeout值，然后调用nf\_ct\_refresh\_acct设置到conntrack上。

然后，在连接查找匹配时，即\_\_\_\_nf\_conntrack\_find函数中。

![图片][0a5cc26d07d2d8422101a38c801df573.png]

在遍历桶中连接时，在匹配前调用nf\_ct\_is\_expired判断连接是否过期，如果过期则调用nf\_ct\_gc\_expired淘汰该连接。这样就保证了大部分过期连接可以得到及时淘汰。

如果在最坏的情况下，某个桶始终不会被遍历时，那个桶中的连接如何淘汰呢？为应对这种情况，内核还有一个补救措施 —— 定义了一个deferable work，gc\_worker。其周期性（1s）执行，按顺序遍历全局连接表，淘汰过期连接。

以上三点是连接跟踪中比较大块和重要的部分，除此之外，还有关联连接、扩展支持等。内核基于连接跟踪又实现了很多有趣实用的功能，如NAT、ALG、SynProxy等。希望后面有机会跟大家分享更多的内核知识，争取把这个做成系列文章。

[7ae770d1804ed6cbaa78391fd2d890d8.png]: /images/20221119/022e8d6aa5604d9d901bf8794ac44a62.png
[792b99a085e1fc7e9fe7ee5407626089.png]: /images/20221119/048b8c6b88654166b8c17afe8cfe3213.png
[4f1bc003e28eda89531c71460e2a8965.png]: /images/20221119/eaf59e740a02433a8ed33645177d0429.png
[9b3343fc299a10325a24708b5909ec73.png]: https://img-blog.csdnimg.cn/img_convert/9b3343fc299a10325a24708b5909ec73.png
[d17df0ae6a689f5bd3d0098699920eaf.png]: https://img-blog.csdnimg.cn/img_convert/d17df0ae6a689f5bd3d0098699920eaf.png
[a2767e5995b6cd9cb41e266a024976b3.png]: https://img-blog.csdnimg.cn/img_convert/a2767e5995b6cd9cb41e266a024976b3.png
[40bef7168415867b665d05ba2876d756.png]: https://img-blog.csdnimg.cn/img_convert/40bef7168415867b665d05ba2876d756.png
[cdb6de58d8ef9a47d4cbec85785ab53b.png]: https://img-blog.csdnimg.cn/img_convert/cdb6de58d8ef9a47d4cbec85785ab53b.png
[20210112093410871.gif]: https://img-blog.csdnimg.cn/20210112093410871.gif
[48c5cc72c3845e40ac69fe4c3903d193.png]: https://img-blog.csdnimg.cn/img_convert/48c5cc72c3845e40ac69fe4c3903d193.png
[d3da9abb8ea50c0c7798ff8b648cd214.png]: https://img-blog.csdnimg.cn/img_convert/d3da9abb8ea50c0c7798ff8b648cd214.png
[95a96c04829b6de1d3f3d3c05bbbc81b.png]: https://img-blog.csdnimg.cn/img_convert/95a96c04829b6de1d3f3d3c05bbbc81b.png
[0a5cc26d07d2d8422101a38c801df573.png]: https://img-blog.csdnimg.cn/img_convert/0a5cc26d07d2d8422101a38c801df573.png