linux 内核 netfilter 网络过滤模块 (4)-期望连接

谁借莪１个温暖的怀抱￠ 2021-07-28 15:13 461阅读 0赞

传统的conntrack和NAT处理只对IP层和传输层头部进行转换处理，但是一些应用层协议，在协议数据报文中包含了地址信息。为了使得这些应用也能透明地完成NAT转换，NAT使用一种称作ALG的技术，它能对这些应用程序在通信时所包含的地址信息也进行相应的NAT转换。

例如：对于FTP协议的PORT/PASV命令，在数据包载荷中需要包含地址信息，并且数据包如果需要做NAT，那应用层数据部分的地址也需要做NAT转换。实现这种转换，需要在普通的conntrack条目基础上增加一个expect conntrack（期望连接）来记录这个连接上的额外信息。

本文将以tftp和ftp协议举例期望连接。

### 1. 以tftp举例期望连接 ###

tftp是基于UDP的应用层协议，用于简单的文件传输。

### 1.1 实验拓扑 ###

测试拓扑如下，在路由器R1上通过tftp请求PC1上的文件“ethreg.sh”，R1和PC1之间有一个路由器R2让R1位于局域网中，PC1位于公网中。在R1上输入以下命令：

tftp –gr ethreg.sh 192.168.10.100

![Center][]

在PC1上抓包结果如下：

![Center 1][]

第一个数据包为read request请求，数据包方向为R1->PC1(192.168.1.1:50173-> 192.168.10.100:69)，其中69中tftp端口号，数据包传输过程经过了SNAT转换。

数据部分共经过两次传输完成，发送数据方向为PC1->R1(192.168.10.100:3873-> 192.168.1.1:50173)，数据包在传输过程经过了DNAT转换。

可见传输数据时，第一个包是从Server端即PC1发出的，而PC1处在NAT外面，而通常情况下，这样的数据包是无法通过NAT达到局域网的，因为路由器R2上并没有记录这个连接做NAT的连接条目，NAT的作用之一就是隐藏局域网中的主机。

下面来看一下tftp协议如何依靠期望连接实现数据包的NAT转换的。

### 1.2 tftp协议的期望连接实现 ###

在编译内核时打开CONFIG\_NF\_CONNTRACK\_TFTP宏，使其以模块形式编译到内核，来支持tftp建立期望连接。该模块的init函数为nf\_conntrack\_tftp\_init()，它初始化了一个conntrack helper方法，并将其注册到helper extension的链表中去（conntrack extensions见前面的博文）。

static struct nf_conntrack_helper tftp[MAX_PORTS][2]__read_mostly;

tftp conntrack模块的初始化函数：

static int __init nf_conntrack_tftp_init(void)
    {
    	int i, j, ret;
    	char *tmpname;
     
    	if (ports_c == 0)
    		ports[ports_c++] = TFTP_PORT;
     
    	for (i = 0; i < ports_c; i++) {
    		memset(&tftp[i], 0, sizeof(tftp[i]));
     
    		tftp[i][0].tuple.src.l3num = AF_INET;
    		tftp[i][1].tuple.src.l3num = AF_INET6;
    		for (j = 0; j < 2; j++) {
    			tftp[i][j].tuple.dst.protonum = IPPROTO_UDP;
    			tftp[i][j].tuple.src.u.udp.port = htons(ports[i]);
    			tftp[i][j].expect_policy = &tftp_exp_policy;
    			tftp[i][j].me = THIS_MODULE;
    			tftp[i][j].help = tftp_help;
     
    			tmpname = &tftp_names[i][j][0];
    			if (ports[i] == TFTP_PORT)
    				sprintf(tmpname, "tftp");
    			else
    				sprintf(tmpname, "tftp-%u", i);
    			tftp[i][j].name = tmpname;
     
    			ret = nf_conntrack_helper_register(&tftp[i][j]);
    			if (ret) {
    				printk("nf_ct_tftp: failed to register helper "
    				       "for pf: %u port: %u\n",
    					tftp[i][j].tuple.src.l3num, ports[i]);
    				nf_conntrack_tftp_fini();
    				return ret;
    			}
    		}
    	}
    	return 0;
    }

tftp\_exp\_policy的定义如下：

static const struct nf_conntrack_expect_policy tftp_exp_policy = {
    	.max_expected	= 1,
    	.timeout	= 5 * 60,
    };

在init函数中对nf\_conntrack\_helper结构体的tuple进行了部分初始化，由于tftp数据包的协议和port是固定的，所以可以预先赋值。同时注册了help函数为tftp\_help()，函数定义如下，注意，参数skb是当前处理的数据包，ct是相应的conntrack，处理tftp read/write request的时候会进入这个函数。

static int tftp_help(struct sk_buff *skb,
    		     unsigned int protoff,
    		     struct nf_conn *ct,
    		     enum ip_conntrack_info ctinfo)
    {
    	const struct tftphdr *tfh;
    	struct tftphdr _tftph;
    	struct nf_conntrack_expect *exp;
    	struct nf_conntrack_tuple *tuple;
    	unsigned int ret = NF_ACCEPT;
    	typeof(nf_nat_tftp_hook) nf_nat_tftp;
    	
    	/* 获得tftp首部 */
    	tfh = skb_header_pointer(skb, protoff + sizeof(struct udphdr),
    				 sizeof(_tftph), &_tftph);
    	if (tfh == NULL)
    		return NF_ACCEPT;
     
    	/* 从tftp首部中获得操作码 */
    	switch (ntohs(tfh->opcode)) {
    	case TFTP_OPCODE_READ:	/* read请求 */
    	case TFTP_OPCODE_WRITE: /* write请求 */
    		/* RRQ and WRQ works the same way */
    		
    		/* 
    在nf_ct_expect_cachep上分配一个expect连接，同时赋两个值：
    exp->master = ct,
    exp->use = 1。 
    */
    		exp = nf_ct_expect_alloc(ct);
    		if (exp == NULL)
    			return NF_DROP;
     
    		/* 根据ct初始化expect */
    		tuple = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
    		nf_ct_expect_init(exp, NF_CT_EXPECT_CLASS_DEFAULT,
    				  nf_ct_l3num(ct),
    				  &tuple->src.u3, &tuple->dst.u3,
    				  IPPROTO_UDP, NULL, &tuple->dst.u.udp.port);
    		
    		/* 指向help() -- nf_nat_tftp.c */
    		nf_nat_tftp = rcu_dereference(nf_nat_tftp_hook);
     
    		/* 数据包需要走NAT时，if成立，局域网传输则else成立。 */
    		if (nf_nat_tftp && ct->status & IPS_NAT_MASK)
    			ret = nf_nat_tftp(skb, ctinfo, exp);
    		else if (nf_ct_expect_related(exp) != 0)
    			ret = NF_DROP;
    		nf_ct_expect_put(exp);
    		break;
    	case TFTP_OPCODE_DATA: /* 数据 */
    	case TFTP_OPCODE_ACK: /* 数据的ACK */
    		pr_debug("Data/ACK opcode\n");
    		break;
    	case TFTP_OPCODE_ERROR:
    		pr_debug("Error opcode\n");
    		break;
    	default:
    		pr_debug("Unknown opcode\n");
    	}
    	return ret;
    }

tftp\_help()的工作有两部分：

1.   根据数据包的ct初始化一个expect连接，由于help函数是在ipv4\_confirm()时调用的，所以ct是存在的。另外需要说明一点，tftp请求（读或写）只能从client到server，所以，如果要走NAT，tftp请求包的方向一定是从内网到外网的。

按照上面的例子，当前ct为：

ORGINAL tuple: 17 192.168.10.1:58747 -> 192.168.10.100:69

REPLY tuple: 17 192.168.10.100:69 -> 192.168.10.1:58747

生成的expect为：

ORGINAL tuple: 17 192.168.10.100:0 -> 192.168.10.1:58747

同时，exp->master = ct。注意，expect只有一个tuple，即只有一个方向，这里只看到ORIGNAL方向的tuple，只是因为tuple的dir没赋值，默认为0。

2.   如果ct做了NAT，就调用nf\_nat\_tftp指向的函数，这里它指向nf\_nat\_tftp.c中的help()函数。

static unsigned int help(struct sk_buff *skb,
    			 enum ip_conntrack_info ctinfo,
    			 struct nf_conntrack_expect *exp)
    {
    	const struct nf_conn *ct = exp->master;
    	exp->saved_proto.udp.port
    		= ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.u.udp.port;
    	exp->dir = IP_CT_DIR_REPLY;
    	exp->expectfn = nf_nat_follow_master;
    	if (nf_ct_expect_related(exp) != 0) /* 插入链表 */
    		return NF_DROP;
    	return NF_ACCEPT;
    }

这个函数进一步初始化了expect，同时将这个expect插入struct nf\_conn\_help结构的链表以及全局的期望连接链表expect\_hash中：

static void nf_ct_expect_insert(struct nf_conntrack_expect *exp)
    {
    	/* 获得exp->master的help */
    	struct nf_conn_help *master_help = nfct_help(exp->master);
    	struct net *net = nf_ct_exp_net(exp);
    	const struct nf_conntrack_expect_policy *p;
    	unsigned int h = nf_ct_expect_dst_hash(&exp->tuple);
     
    	atomic_inc(&exp->use);
    	/* 插入到help->expectations链表 */
    	hlist_add_head(&exp->lnode, &master_help->expectations);
    	master_help->expecting[exp->class]++;
    	/* 插入到全局的expect_hash表 */
    	hlist_add_head_rcu(&exp->hnode, &net->ct.expect_hash[h]);
    	net->ct.expect_count++;
    	/* 设置并启动定时器 */
    	setup_timer(&exp->timeout, nf_ct_expectation_timed_out,
    		    (unsigned long)exp);
    	p = &master_help->helper->expect_policy[exp->class];
    	exp->timeout.expires = jiffies + p->timeout * HZ;
    	add_timer(&exp->timeout);
     
    	atomic_inc(&exp->use);
    	NF_CT_STAT_INC(net, expect_create);
    }

我们还注意到在help()函数中将exp-> expectfn赋值为nf\_nat\_follow\_master()，这个函数的作用在后面会提到。

上面的内容是在客户端发送tftp请求后触发的动作，主要的效果就是生成了一个期望连接并可以被使用了。下面以请求读数据来看一下传输数据时的数据包变化。

当tftp请求包进入nf\_conntrack\_in的时候，由于没有ct条目，所以调用init\_conntrack()尝试新建一个条目，在这个函数中，根据skb新建两个方向的tuple，之后有这样的代码：

spin_lock_bh(&nf_conntrack_lock);
    	exp = nf_ct_find_expectation(net, tuple);
    	 /* 如果在期望连接链表中 */
    	if (exp) { 
    		__set_bit(IPS_EXPECTED_BIT, &ct->status);
    		ct->master = exp->master;
    		if (exp->helper) {
    			help = nf_ct_helper_ext_add(ct, GFP_ATOMIC);
    			if (help)
    				rcu_assign_pointer(help->helper, exp->helper);
    		}
     
    		nf_conntrack_get(&ct->master->ct_general);
    		NF_CT_STAT_INC(net, expect_new);
    	} else {
    		__nf_ct_try_assign_helper(ct, GFP_ATOMIC);
    		NF_CT_STAT_INC(net, new);
    	}
     
    	hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
    		       &net->ct.unconfirmed);
     
    	spin_unlock_bh(&nf_conntrack_lock);
     
    	if (exp) {
    		if (exp->expectfn)
    			exp->expectfn(ct, exp);
    		nf_ct_expect_put(exp); 
    	}
     
    	return &ct->tuplehash[IP_CT_DIR_ORIGINAL];

这里会在全局的期望连接链表expect\_hash中查找是否有匹配新建tuple的期望连接。第一次过来的数据包肯定是没有的，于是走else分支，\_\_nf\_ct\_try\_assign\_helper()函数去nf\_ct\_helper\_hash哈希表中匹配当前tuple，由于我们在本节开头提到nf\_conntrack\_tftp\_init()已经把tftp的helper extension添加进去了，所以可以匹配成功，于是把找到的helper赋值给nfct\_help(ct)->helper，而这个helper的help方法就是tftp\_help()。

当tftp请求包走到ipv4\_confirm的时候，会去执行这个help方法，即tftp\_help()，也就是建立一个期望连接。

当后续tftp传输数据时，在nf\_conntrack\_in里面，新建tuple后，在expect\_hash表中查可以匹配到新建tuple的期望连接（因为只根据源端口来匹配），因此上面代码的if成立，所以ct->master被赋值为exp->master，并且，还会执行exp->expectfn()函数，这个函数上面提到是指向nf\_nat\_follow\_master()的，该函数根据ct的master来给ct做NAT，ct在经过这个函数处理前后的tuple分别为：

before expectfn:

ORGINAL : tuple 83b38338: 17 192.168.10.100:3873 ->192.168.10.1:50173

REPLY : tuple 83b38368: 17 192.168.10.1:50173 ->192.168.10.100:3873

after expectfn:

ORGINAL : tuple 83b38338: 17 192.168.10.100:3873 ->192.168.10.1:50173

REPLY : tuple 83b38368: 17192.168.5.1:50173 -> 192.168.10.100:3873

在ipv4\_confirm中，由于ct没有期望连接，所以跳过helper有关的代码直接调用nf\_conntrack\_confirm()函数。

其他相关问题：

1.   数据传输时的服务器端的端口时谁指定的：

服务器端指定的。在从server->client传数据时，server收到tftp read request之后，就直接发送数据，数据从block1开始计数。而从client->server传数据时，server收到tftp write request之后，先回复一个tftp ack（标记为block0），包中携带server打开的端口号，client便知道使用的目的端口，然后client开始发送数据，数据从block1开始计数。

2.   期望连接的匹配原则：

添加到net->ct.expect\_hash\[\]中的hash规则为nf\_ct\_expect\_dst\_hash(&exp->tuple)，在查找的时候使用同样的hash规则。

\_\_nf\_ct\_helper\_find(tuple)函数用于在nf\_ct\_helper\_hash\[\]表中查找匹配的structnf\_conntrack\_helper结构。过程中不匹配tuple->src.u3，即不匹配源IP地址，需要匹配的是源端口、L3协议号和L4协议号，dir和目的port也需要不匹配。当然，在对tuple进行hash的时候，也只用到了源端口、L3协议号和L4协议号。所以，对于下面的tuple，只比较红色部分：

REPLY : tuple 83a5d5b0: 17192.168.10.100:69 -> 192.168.5.1:40240

nf\_ct\_find\_expectation(net, tuple)函数用于在net->ct.expect\_hash\[\]查找是否有和tuple匹配的连接跟踪，匹配函数为nf\_ct\_tuple\_mask\_cmp(tuple,&exp->tuple, &exp->mask)，要求tuple中所有条件都符合，而由于expect连接的源端口是0。不过没关系，源端口的mask被设置为0，所以相当于不匹配该项（可参考创建expecttuple的函数nf\_ct\_expect\_init是如何根据源端口设置mask的）。

待匹配tuple：ORGINAL : tuple 801efc1c: 17 192.168.10.100:4593-> 192.168.10.1:40240

expect tuple：ORGINAL : tuple 839dd908: 17 192.168.10.100:0 ->192.168.10.1:40240

我们现在可以来整理一下连接上的tuple和expect tuple之间的关系，  
![Center 2][]

上图浅绿色内容是模块初始化时注册的，黄色内容是处理tftp请求包时初始化的，蓝色的数组是全局hash表。tftp数据包就根据上面的内容进行NAT转换。

注意，在nf\_ct\_find\_expectation()查找期望连接时，如果找到了，就把该期望连接从struct nf\_conn\_help结构的链表以及全局的期望连接链表expect\_hash中删除。在expect\_hash中的连接通过设置的超时时间来超时。

### 2. 以ftp协议举例期望连接 ###

有些应用层协议字段需要携带IP和PORT信息，例如ftp协议，它是基于TCP的文件传输协议，FTP 使用TCP 生成一个虚拟连接用于控制信息，然后再生成一个单独的TCP 连接用于数据传输。而简单的NAT转换并不关注TCP的数据部分，所以需要额外的helper和expect连接来让外网的服务器看到的源IP确实是WAN口的IP并且使用于传输数据的TCP连接上的数据包可以进行NAT转换。

测试拓扑如下图：

![Center 3][]  
在PC1上抓包，在Router上查看连接信息。

在ftp客户端获取服务器上的do\_exit-tty.log.rar文件：

[root@zhenfg build]# ftp 172.31.1.23
    ftp> passive
    ftp> get do_exit-tty.log.rar
    ftp> disconnect
    ftp> quit
    [root@zhenfg build]#

下图是ftp在PORT（主动）模式下get服务器上的文件的抓包，其中黄色框部分是用于交互控制信息的TCP连接建立连接和断开连接的过程，绿色框部分是用于传输数据而建立的TCP连接。从红色框的数据包可以看到在ftp头部中包含了请求方的IP地址，而这个地址已经被转换成PC1的WAN口地址。

![Center 4][]

从上图可以看到，传输数据的TCP连接是从服务器端发起的，所以如果没有期望连接，路由器就不知道如何进行DNAT转换。

用于ftp控制信息的TCP连接的conntrack信息为：

ORGINAL : tuple 83b13580: 6 192.168.5.103:1757 ->172.31.1.23:21

REPLY : tuple 83b135b0: 6 172.31.1.23:21 ->172.31.70.42:1757

数据传输的TCP连接便是使用控制信息的TCP连接来生成期望连接的，并且将其作为期望连接的master。生成的期望连接为：

ORGINAL : tuple 83b1c9b8: 6 172.31.1.23:0 ->172.31.70.42:1762

实际机型NAT转换的函数依然是exp->expectfn()，并且仍然指向nf\_nat\_follow\_master()函数，该函数根据ct的master来给ct做NAT，ct在经过这个函数处理前后的tuple分别为：

before expectfn:

ORGINAL : tuple 83b22ee8: 6 172.31.1.23:20 ->172.31.70.42:1762

REPLY : tuple 83b22f18: 6 172.31.70.42:1762 ->172.31.1.23:20

after expectfn:

ORGINAL : tuple 83b22ee8: 6 172.31.1.23:20 ->172.31.70.42:1762

REPLY : tuple 83b22f18: 6 192.168.5.103:1762 ->172.31.1.23:20

系统中的期望连接条目记录在proc文件/proc/net/nf\_conntrack\_expect中，显示文件内容的函数为exp\_seq\_show()。

[Center]: /images/20210728/fc79f2740bda44529582b513aa6b94c8.png
[Center 1]: /images/20210728/1bfe5469a4384d8eb7442ba3d75c6c16.png
[Center 2]: /images/20210728/25e0c08688c245af9ccef4990c10d259.png
[Center 3]: /images/20210728/1e8822811d53426f8645446bd5726c25.png
[Center 4]: /images/20210728/81444a54b7d447e38205e21e5211c9fa.png