Linux内核那些事之连接跟踪

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

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

注&＃xff1a;本文对应的Linux源码为最新的5.9.12

00

基础知识

1. 一个连接由两个tuple组成&＃xff0c;分别代表两个方向的报文信息。

2. 一个tuple一般由报文的五元组构成&＃xff0c;分别是源地址、目的地址&＃xff0c;源端口、目的端口和协议号&＃xff08;四层&＃xff09;。

3. 连接跟踪表一般为hash表。该表可能是全局的&＃xff0c;也可能是per cpu的&＃xff0c;Linux内核选择的是全局表。

4. 每个连接根据自己的状态&＃xff0c;都有自己的生命周期&＃xff0c;到期会销毁。

5. 网元设备一般会在连接中增加扩展&＃xff0c;来实现带状态的业务。

    

01

—

连接跟踪的匹配和创建

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

nf_conntrack_in是连接匹配的入口函数&＃xff0c;其会被netfitler处理brdige&＃xff08;etables&＃xff09;、ipv4和ipv6的hook函数调用。

在nf_conntrack_in中&＃xff0c;

这里先调用get_l4proto&＃xff0c;根据三层协议获取四层协议号和数据偏移。然后&＃xff0c;调用resolve_normal_ct进行连接的匹配和创建。

在resolve_normal_ct中&＃xff0c;

首先调用nf_ct_get_tuple根据报文生成这个方向的tuple&＃xff0c;然后调用__nf_conntrack_find_get通过tuple进行连接的查找。如果没有找到&＃xff0c;则调用init_conntrack生成新的连接。

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

以ICMP报文为例&＃xff0c;见icmp_pkt_to_tuple

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

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

连接的创建同样简单&＃xff0c;在init_conntrack中&＃xff0c;

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

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

在init_conntrack中的结尾&＃xff0c;还有一块儿代码值得大家注意&＃xff1a;

前两个语句&＃xff0c;增加了conntrack的引用计数&＃xff0c;然后将conntrack添加到unconfirmed_list中。

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

02

—

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

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

1. 在基础知识一节中&＃xff0c;我们提到一个conntrack有两个tuple。当我们创建conntrack时&＃xff0c;实际上只有一个方向的报文&＃xff0c;也就只能够生成这个方向的tuple。虽然我们可以根据tuple的定义&＃xff0c;将当前方向的tuple做个反向处理来得到反向tuple。但这里会有一个问题&＃xff0c;当有NAT规则时&＃xff0c;此时此刻我们并不知道后面会如何进行NAT处理&＃xff0c;生成的反向tuple自然不正确。那么&＃xff0c;是否可以先插入一个tuple呢&＃xff1f;答案也是否定的。这可能会引发并发竞争的问题。试想&＃xff0c;一个连接的两个方向的报文&＃xff0c;有可能由两个CPU进行处理&＃xff0c;他们都根据当前报文生成了conntrack和tuple并插入到全局表中。这就意味着同一个连接被插入表两次&＃xff0c;自然是一个错误。如果要增加这种情况的检查&＃xff0c;逻辑会更加复杂。

2. 在创建连接的时候&＃xff0c;属于比较早期的阶段&＃xff0c;很有可能在后面的处理中报文会被丢弃&＃xff0c;比如命中了防火墙drop规则等等。如果先把连接插入了全局表&＃xff0c;到时候还要进行删除处理&＃xff0c;这无疑是一种浪费。Linux内核会在最后阶段&＃xff0c;才会把连接插入到全局表中。 

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

以IPv4报文为例&＃xff0c;

其分别在postrouting和localin两个阶段&＃xff0c;以优先级NF_IP_PRI_CONNTRACK_CONFIRM&＃xff08;INT_MAX&＃xff09;来调用hook函数ipv4_confirm。这就保证了无论是转发的&＃xff0c;本机发出的&＃xff08;最后也会走到postrouting&＃xff09;&＃xff0c;还是发给本机的&＃xff0c;都会在最后阶段&＃xff08;也就是即将离开netfilter模块&＃xff09;时执行ipv4_confirm。而ipv4_confirm经过层层还是会最终调用到__nf_conntrack_confirm&＃xff0c;其负责将conntrack插入到全局表中。

前文说过&＃xff0c;一个连接有两个tuple&＃xff0c;根据不同tuple计算的hash bucket自然也不同&＃xff0c;也就是说&＃xff0c;内核需要将conntrack插入到了两个bucket中。前面在__nf_conntrack_find_get中进行连接查找匹配时&＃xff0c;使用的是rcu_read_lock进行保护。现在要进行插入操作&＃xff08;写操作&＃xff09;&＃xff0c;自然要使用锁了。在老版本内核中&＃xff0c;全局连接表的写入操作使用了全局唯一一个spinlock&＃xff0c;这无疑降低并发性能。后来内核对此做了改进&＃xff0c;使用了CONNTRACK_LOCKS&＃xff08;1024&＃xff09;个锁&＃xff0c;来减小锁的粒度。

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

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

然后先检查是否已经有CPU插入了相同连接&＃xff0c;

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

通过一系列检查后&＃xff0c;__nf_conntrack_confirm调用__nf_conntrack_hash_insert把conntrack两个tuple插入到全局表中。

03

—

连接跟踪的生命周期

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

首先&＃xff0c;在nf_conntrack_in函数中调用nf_conntrack_handle_packet根据不同协议处理报文&＃xff0c;更新连接状态。以TCP报文为例&＃xff0c;会调用nf_conntrack_tcp_packet进行处理。

这里根据不同的TCP状态确定不同的timeout值&＃xff0c;然后调用nf_ct_refresh_acct设置到conntrack上。

然后&＃xff0c;在连接查找匹配时&＃xff0c;即____nf_conntrack_find函数中。

在遍历桶中连接时&＃xff0c;在匹配前调用nf_ct_is_expired判断连接是否过期&＃xff0c;如果过期则调用nf_ct_gc_expired淘汰该连接。这样就保证了大部分过期连接可以得到及时淘汰。

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

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