大家好，欢迎来到IT知识分享网。

netfilter内核实现概述

一、前言

netfilter是Linux内核中网络防火墙的基础，无论是基于xtables的iptables，还是conntrack、nftables，其底层都是基于netfilter的。总体来说，netfilter提供了一个相对来说比较通用的防火墙框架，这个框架提供了个入口，内核中的其他网络模块可以通过这个入口来实现自己的网络逻辑。本文简单地对netfilter的整个框架以及其内核实现进行了梳理。

二、netfilter框架

2.1 基本原理

相比于那些基于netfilter所实现的一些功能（如iptables），netfilter本身的实现并不复杂，其本质上是在内核网络中提供了一些HOOK点。不同的协议族（如ip协议族、arp协议、bridge网桥设备等）所提供的HOOK点也不同。以ipv4协议为例，其提供的HOOK点与我们平时所接触的iptables中的五个链一致（详情可参考：iptables原理中关于规则链的介绍）：

内核在实现的时候，采用struct netns_nf来表示当前所支持的所有的协议族及其HOOK点，如下所示：

struct netns_nf { 
   
#if defined CONFIG_PROC_FS
	struct proc_dir_entry *proc_netfilter;
#endif
	const struct nf_queue_handler __rcu *queue_handler;
	const struct nf_logger __rcu *nf_loggers[NFPROTO_NUMPROTO];
#ifdef CONFIG_SYSCTL
	struct ctl_table_header *nf_log_dir_header;
#endif
    /* 由于每个HOOK点对应一个struct nf_hook_entries，这里采用数组的方式 * 来存储当前协议族所有的HOOK点对应的entries。 */
	struct nf_hook_entries __rcu *hooks_ipv4[NF_INET_NUMHOOKS];
	struct nf_hook_entries __rcu *hooks_ipv6[NF_INET_NUMHOOKS];
#ifdef CONFIG_NETFILTER_FAMILY_ARP
	struct nf_hook_entries __rcu *hooks_arp[NF_ARP_NUMHOOKS];
#endif
#ifdef CONFIG_NETFILTER_FAMILY_BRIDGE
	struct nf_hook_entries __rcu *hooks_bridge[NF_INET_NUMHOOKS];
#endif
#if IS_ENABLED(CONFIG_DECNET)
	struct nf_hook_entries __rcu *hooks_decnet[NF_DN_NUMHOOKS];
#endif
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV4)
	bool			defrag_ipv4;
#endif
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
	bool			defrag_ipv6;
#endif
};

这里可以看出，netfilter实现的关键在于struct nf_hook_entries这个结构体。这个结构体定义了内核里所有的模块在其对应的HOOK点上注册的钩子函数。

/* 以数组的方式将多个nf_hook_entry组织起来的结构体。一般，一个协议族或者是 * 一种防火墙（如ipv4）的一个HOOK点会对应一个nf_hook_entries，代表所有注册 * 在这个HOOK点上的处理函数。 * * 这个结构体在数据存储方面采用了下面的结构图： * num_hook_entries | (struct nf_hook_entry) * num_hook_entries | * (struct nf_hook_ops) * num_hook_entries * * 每个entry都有一个与之对应的ops，通过index可以直接找到entry和ops。 */
struct nf_hook_entries { 
   
	u16				num_hook_entries;
	/* padding */
	struct nf_hook_entry		hooks[];
	 */
};

2.2 优先级

同一个协议族的同一个HOOK点上有若干个钩子函数，这些函数的执行顺序是根据注册的时候的优先级决定的，这个可以从钩子函数的注册函数__nf_register_net_hook()看出来。在进行nf_hook_ops注册的时候，会先根据命名空间和协议族以及HOOK号找到对应的nf_hook_entries，然后调用nf_hook_entries_grow将其插入到nf_hook_entries中。插入的时候，会对所有的nf_hook_entry按照优先级从小到大的顺序存储。

每个协议族都有自己的一套优先级定义，以IPv4为例，其优先级列表如下所示：

enum nf_ip_hook_priorities { 
   
	NF_IP_PRI_FIRST = INT_MIN,
	NF_IP_PRI_RAW_BEFORE_DEFRAG = -450,
	NF_IP_PRI_CONNTRACK_DEFRAG = -400,
	NF_IP_PRI_RAW = -300,
	NF_IP_PRI_SELINUX_FIRST = -225,
	NF_IP_PRI_CONNTRACK = -200,
	NF_IP_PRI_MANGLE = -150,
	NF_IP_PRI_NAT_DST = -100,
	NF_IP_PRI_FILTER = 0,
	NF_IP_PRI_SECURITY = 50,
	NF_IP_PRI_NAT_SRC = 100,
	NF_IP_PRI_SELINUX_LAST = 225,
	NF_IP_PRI_CONNTRACK_HELPER = 300,
	NF_IP_PRI_CONNTRACK_CONFIRM = INT_MAX,
	NF_IP_PRI_LAST = INT_MAX,
};

可以看出，虽然CONNTRACK和NAT都是在同一个HOOK点上（PREROUTING）起作用，但是CONNTRACK始终会先于NAT运行，因为其优先级较高。

2.3 HOOK注册

这里简单看一下HOOK上的钩子函数是如何注册上去的。钩子函数的定义和注册都是通过struct nf_hook_ops结构体来实现的。该结构体的pf和hooknum两个字段基本就确定了当前钩子函数所属于的协议族和作用的HOOK点；nf_hookfn则定义了要执行的回掉函数。

struct nf_hook_ops { 
   
	/* User fills in from here down. */
	nf_hookfn		*hook;
	struct net_device	*dev;
	void			*priv;
	u_int8_t		pf;
	unsigned int		hooknum;
	/* 优先级，同一个HOOK点上的不同ops通过这个来进行排序，按照从小到大 * 的顺序排列。 */
	int			priority;
};

以conntrack模块中的ip4协议为例，其定义了如下的struct nf_hook_ops：

static const struct nf_hook_ops ipv4_conntrack_ops[] = { 
   
	{ 
   
		.hook		= ipv4_conntrack_in,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_PRE_ROUTING,
		.priority	= NF_IP_PRI_CONNTRACK,
	},
	{ 
   
		.hook		= ipv4_conntrack_local,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_LOCAL_OUT,
		.priority	= NF_IP_PRI_CONNTRACK,
	},
	{ 
   
		.hook		= ipv4_confirm,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_POST_ROUTING,
		.priority	= NF_IP_PRI_CONNTRACK_CONFIRM,
	},
	{ 
   
		.hook		= ipv4_confirm,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_LOCAL_IN,
		.priority	= NF_IP_PRI_CONNTRACK_CONFIRM,
	},
};

在启用conntrack的时候（详见nf_ct_netns_get()函数），上面的四个钩子函数会注册到对应的HOOK点。具体的注册过程比较简单，首先根据nf_hook_ops的pf和hooknum从当前网络命名空间中找到对应的struct nf_hook_entries，然后按照一定的优先级将ops插入到entries中。

2.4 执行

netfilter的执行就比较简单了，一般都是使用宏定义NF_HOOK()来执行。它会根据协议族和hooknum找到当前命名空间的对应的struct nf_hook_entries。

static inline int
NF_HOOK(uint8_t pf, unsigned int hook, struct net *net, struct sock *sk, struct sk_buff *skb,
	struct net_device *in, struct net_device *out,
	int (*okfn)(struct net *, struct sock *, struct sk_buff *))
{ 
   
	int ret = nf_hook(pf, hook, net, sk, skb, in, out, okfn);
	if (ret == 1)
		ret = okfn(net, sk, skb);
	return ret;
}

随后，遍历struct nf_hook_entries上所有的struct nf_hook_entry，并调用其上的回调函数。

/* 执行特定协议族的特定HOOK点上的所有注册的钩子函数，并根据返回值做相应的处理。 * 该函数如果返回1，代表okfn应该被执行；否则，不执行。 */

int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state,
		 const struct nf_hook_entries *e, unsigned int s)
{ 
   
	unsigned int verdict;
	int ret;

	for (; s < e->num_hook_entries; s++) { 
   
		verdict = nf_hook_entry_hookfn(&e->hooks[s], skb, state);
		switch (verdict & NF_VERDICT_MASK) { 
   
		case NF_ACCEPT:
			break;
		case NF_DROP:
			kfree_skb(skb);
			ret = NF_DROP_GETERR(verdict);
			if (ret == 0)
				ret = -EPERM;
			return ret;
		case NF_QUEUE:
			ret = nf_queue(skb, state, s, verdict);
			if (ret == 1)
				continue;
			return ret;
		default:
			/* Implicit handling for NF_STOLEN, as well as any other * non conventional verdicts. */
			return 0;
		}
	}

	return 1;
}

三、nftables

与iptables类似，nftables也是Linux系统中的一个防火墙工具。不同的是iptables仅支持ip协议族，例如如果想要拦截arp，就要使用arptable。且由于iptables实现的框架过于繁琐，效率低等原因，目前高版本的发行版已经使用nftables取代iptables了。这里我们就以nftables为例，简单看一下nftables是如何与netfilter关联在一起的。

3.1 基本原理

对于表、链的概念，nftables与iptables是完全一致的，这也是为什么用户可以在不感知的情况下能够从iptables切换到nftables。想要理解nftables的内核实现，以下几个结构体是作用是需要了解的：struct nft_chain_type、struct nft_chain、struct nft_table。如果你已经对iptables（xtables）的实现有了一定了了解，那这里的概念就会变得很容易理解。

关于表、链的基本概念这里不再赘述，需要着重讲一下链类型（chain_type）的概念，这个与iptables中有些不一样。iptables中的表是预定义好的，比如filter表用作过滤、nat表用于转发，即通过表来区分规则的作用。nftables有些不一样，nftables更加灵活，其没有固定的（默认的）表，用户可以随意增加表。那么一条规则，是如何区分他是要进行过滤还是NAT呢？这里是通过链类型来决定的。我们来简单看一下nftables的使用过程，下面的命令我们创建了filter表，并给其中增加了input、output和forward三条链，这样这个表的作用就和iptables中的filter的作用一样了。而决定这三条链只能用作filter而不能用作nat的，就是命令中的type字段。

nft create table inet filter
nft add chain inet filter input { type filter hook input priority filter \; }
nft add chain inet filter output { type filter hook output priority filter \; }
nft add chain inet filter forward { type filter hook forward priority filter \; }

下面我们把NAT类型的链也创建到filter表中，可以看到也添加成功了，这说明决定规则类型的是链的类型，而不是表的类型。

nft add chain inet filter prerouting { type nat hook prerouting priority dstnat \; }

3.2 内核实现

通过上面的分析，我们大概可以知道nftables的处理逻辑是通过链类型来决定的，内核中采用struct nft_chain_type来表示。事实上，chain_type可以理解为nftables的元数据，其定义了当前链类型上支持的HOOK点、处理函数等信息，如下为ipv4的filter类型的chain_type的定义：

static const struct nft_chain_type nft_chain_filter_ipv4 = { 
   
	.name		= "filter",
	.type		= NFT_CHAIN_T_DEFAULT,
	.family		= NFPROTO_IPV4,
	.hook_mask	= (1 << NF_INET_LOCAL_IN) |
			  (1 << NF_INET_LOCAL_OUT) |
			  (1 << NF_INET_FORWARD) |
			  (1 << NF_INET_PRE_ROUTING) |
			  (1 << NF_INET_POST_ROUTING),
	.hooks		= { 
   
		[NF_INET_LOCAL_IN]	= nft_do_chain_ipv4,
		[NF_INET_LOCAL_OUT]	= nft_do_chain_ipv4,
		[NF_INET_FORWARD]	= nft_do_chain_ipv4,
		[NF_INET_PRE_ROUTING]	= nft_do_chain_ipv4,
		[NF_INET_POST_ROUTING]	= nft_do_chain_ipv4,
	},
};

所有的内核支持的链类型都注册到了全局数组chain_type中。这是个二维数组，索引分别是协议号和链类型号。

/* 按照协议族、表类型以二维数组的方式把nft_chain_type组织起来。 * 其中，每个nft_chain_type对应一个协议族的一个表。 * * NFT_CHAIN_T_MAX代表一个协议族表的最大数量，比如FILTER、NAT等。 */
static const struct nft_chain_type *chain_type[NFPROTO_NUMPROTO][NFT_CHAIN_T_MAX];

其中，链类型号目前支持的就三种：

• NFT_CHAIN_T_DEFAULT：默认的链类型（filter类型）
• NFT_CHAIN_T_ROUTE：路由类型的链
• NFT_CHAIN_T_NAT：进行NAT地址转发的链

3.3 链的添加

下面我们来看一下一条链是如何添加到内核中的，以及其是如何和netfilter联系起来的。所有的nftables操作都是通过netlink来实现的，链的添加最终会调用nf_tables_addchain()这个内核函数。从下面的函数处理过程可以看出，在创建链的时候内核会为每个链（非NAT类型）创建一个对应的nf_hook_ops结构体并注册到netfilter框架中对应的entries中。对于NAT类型的链，由于NAT涉及到各个模块之间的配合，因此稍微复杂点，下面会专门讲这一部分。

static int nf_tables_addchain(struct nft_ctx *ctx, u8 family, u8 genmask,
			      u8 policy, u32 flags)
{ 
   
	const struct nlattr * const *nla = ctx->nla;
	struct nft_table *table = ctx->table;
	struct nft_base_chain *basechain;
	struct nft_stats __percpu *stats;
	struct net *net = ctx->net;
	char name[NFT_NAME_MAXLEN];
	struct nft_trans *trans;
	struct nft_chain *chain;
	struct nft_rule **rules;
	int err;

	if (table->use == UINT_MAX)
		return -EOVERFLOW;

	if (nla[NFTA_CHAIN_HOOK]) { 
   
		struct nft_chain_hook hook;

		if (flags & NFT_CHAIN_BINDING)
			return -EOPNOTSUPP;

		/* 从netlink中提取注册钩子函数所需要的信息，包括当前链的类型 * 优先级、hooknum等，并存放到nft_chain_hook结构体中。 */
		err = nft_chain_parse_hook(net, nla, &hook, family, true);
		if (err < 0)
			return err;

		/* 链在内核中采用nft_chain结构体表示。该结构体主要保存了 * 链与表、规则之间的内容和关系。每个nft_chain都内嵌在 * nft_base_chain结构体中，这个结构体保存了链与netfilter * 之间的相关内容，包括注册到netfilter中的nf_hook_ops、 * 链的类型等。 */
		basechain = kzalloc(sizeof(*basechain), GFP_KERNEL);
		if (basechain == NULL) { 
   
			nft_chain_release_hook(&hook);
			return -ENOMEM;
		}
		chain = &basechain->chain;

		if (nla[NFTA_CHAIN_COUNTERS]) { 
   
			stats = nft_stats_alloc(nla[NFTA_CHAIN_COUNTERS]);
			if (IS_ERR(stats)) { 
   
				nft_chain_release_hook(&hook);
				kfree(basechain);
				return PTR_ERR(stats);
			}
			rcu_assign_pointer(basechain->stats, stats);
			static_branch_inc(&nft_counters_enabled);
		}

		/* 初始化bashchain，包括使用hook里的优先级、HOOK点来初始化 * bashchain->ops，使用type里的hook_fn来初始化钩子函数。 */
		err = nft_basechain_init(basechain, family, &hook, flags);
		
    [......]

	/* 将ops注册到netfilter。对于非NAT类型的链，这里会调用 * nf_register_net_hook()来直接将basechain->ops进行注册； * 对于NAT类型的链，会调用chain_type里的注册方法进行注册。 * 以ipv4为例，这里会调用nf_nat_ipv4_register_fn()进行注册。 */
	err = nf_tables_register_hook(net, table, chain);
	if (err < 0)
		goto err_destroy_chain;

	[......]

四、conntrack与nat

4.1 conntrack基本原理

conntrack即连接跟踪（connect track），是用来跟踪系统中所有的连接状态的，包括tcp、udp、icmp等各种协议。conntrack也是基于netfilter的，不同的协议族其conntrack的框架也稍有不同，目前支持的协议族包括ipv4、ipv6、bridge（网桥设备），这个可以从nf_ct_netns_do_get()函数中看出来。这里以ipv4为例来讲解conntrack实现的大体框架。

从ipv4_conntrack_ops定义我们可以得到上图的原理图。ipv4的conntrack使用了netfilter中的四个HOOK点，分别是PREROUTING、LOCAL_OUT、LOCAL_IN和POSTROUTINTG。我们可以对这四个HOOK点进行分类，其中前两个为报文进入到IP协议层的HOOK点，后两个为报文离开IP层的HOOK点。

首先我们来介绍一下内核用来进行conntrack的数据结构吧。ct的核心数据结构为struct nf_conn，这里可以重点看一下其中的tuplehash字段的说明。一条ct记录实际上维护了一条连接的两个方向的状态，这两个方向称为ORIGIN和REPLY。顾名思义，ORIGIN即原始方向，可以理解为创建ct的时候的那个报文的方向；REPLY为响应方向，即响应报文的方向。为了维护一个连接的两个方向，nf_conn使用了一个长度为2的类型为struct nf_conntrack_tuple_hash的数组：

struct nf_conn { 
   
	[...]

#ifdef CONFIG_NF_CONNTRACK_ZONES
	struct nf_conntrack_zone zone;
#endif
	/* 这个可以说是conntrack里最重要是一个字段了，他是一个数组，长度为2， * 类型为struct nf_conntrack_tuple_hash。 * * struct nf_conntrack_tuple_hash是用来表示一个连接的，例如本机A * 向服务器B建立了一条TCP连接，那么这个数组中的第一个元素的代表着 * A -> B的连接，tuplehash[0].src存储了A的地址和端口，tuplehash[0].dst * 存储了B的地址和端口。 * * 由于conntrack跟踪的是双向连接，因此tuplehash[1]存储的是这个连接 * 中B -> A的连接，即tuplehash[1].src存储了B的地址和端口， * tuplehash[1].dst存储了B的地址和端口。 */
	struct nf_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];

	/* 当前ct的状态标志，包括是否confirm、是否收到过响应包等。 */
	unsigned long status;

	u16		cpu;
    /* 所属于的网络命名空间。 */
	possible_net_t ct_net;

#if IS_ENABLED(CONFIG_NF_NAT)
	struct hlist_node	nat_bysource;
#endif
	/* all members below initialized via memset */
	struct { 
    } __nfct_init_offset;

	/* If we were expected by an expectation, this will be it */
	struct nf_conn *master;

#if defined(CONFIG_NF_CONNTRACK_MARK)
	u_int32_t mark;
#endif

#ifdef CONFIG_NF_CONNTRACK_SECMARK
	u_int32_t secmark;
#endif

	/* Extensions */
	struct nf_ct_ext *ext;

	/* * 协议相关的内容，比如TCP的窗口信息等。 */
	union nf_conntrack_proto proto;
};

接下来我们要介绍以下ct的几个状态和一些标志位。下面几个是ct的几个标志（会设置在上面的status字段中）：

enum ip_conntrack_status { 
   
	/* It's an expected connection: bit 0 set. This bit never changed */
	IPS_EXPECTED_BIT = 0,
	IPS_EXPECTED = (1 << IPS_EXPECTED_BIT),

	/* 当前ct是否收到过REPLY方向的报文。 */
	IPS_SEEN_REPLY_BIT = 1,
	IPS_SEEN_REPLY = (1 << IPS_SEEN_REPLY_BIT),

	/* Conntrack should never be early-expired. */
	IPS_ASSURED_BIT = 2,
	IPS_ASSURED = (1 << IPS_ASSURED_BIT),

	/* 当前ct是否被confirm过了。这里的confirm可以理解为生效，报文 * 在离开IP协议层的时候新创建的ct会被确认，并加入到哈希表中。 * * 没有被确认的ct是没有生效的。 */
	IPS_CONFIRMED_BIT = 3,
	IPS_CONFIRMED = (1 << IPS_CONFIRMED_BIT),

	/* 标志着这个连接需要进行SNAT */
	IPS_SRC_NAT_BIT = 4,
	IPS_SRC_NAT = (1 << IPS_SRC_NAT_BIT),

	/* 标志着这个连接需要进行DNAT */
	IPS_DST_NAT_BIT = 5,
	IPS_DST_NAT = (1 << IPS_DST_NAT_BIT),

	/* Both together. */
	IPS_NAT_MASK = (IPS_DST_NAT | IPS_SRC_NAT),

	/* Connection needs TCP sequence adjusted. */
	IPS_SEQ_ADJUST_BIT = 6,
	IPS_SEQ_ADJUST = (1 << IPS_SEQ_ADJUST_BIT),

	/* 标志着SNAT初始化完成。 */
	IPS_SRC_NAT_DONE_BIT = 7,
	IPS_SRC_NAT_DONE = (1 << IPS_SRC_NAT_DONE_BIT),

	/* 标志着DNAT初始化完成了。 */
	IPS_DST_NAT_DONE_BIT = 8,
	IPS_DST_NAT_DONE = (1 << IPS_DST_NAT_DONE_BIT),

	/* Both together */
	IPS_NAT_DONE_MASK = (IPS_DST_NAT_DONE | IPS_SRC_NAT_DONE),

	[...]
};

除了ct拥有状态，当前skb上也维护了一个代表当前报文所处于的方向上的一些状态，存储在skb中。根据这个状态，可以判断出当前报文是ORIGIN方向的还是REPLY方向的（根据状态值是否大于IP_CT_IS_REPLY来判断）。这个值会在ct初始化或者恢复的时候设置到skb上。

enum ip_conntrack_info { 
   
	/* ct已经建链。这个在收到响应报文后就会进入这个状态。 */
	IP_CT_ESTABLISHED,

	/* 与NEW类似，还没搞清楚干啥的 */
	IP_CT_RELATED,

	/* ct刚创建 */
	IP_CT_NEW,

	/* 这是个分割线，下面的都是REPLY方向的状态。 */
	IP_CT_IS_REPLY,

	/* REPLY方向建链 */
	IP_CT_ESTABLISHED_REPLY = IP_CT_ESTABLISHED + IP_CT_IS_REPLY,
	/* REPLY方向 */
	IP_CT_RELATED_REPLY = IP_CT_RELATED + IP_CT_IS_REPLY,
	
	IP_CT_NUMBER,
};

4.2 conntrack的初始化

conntrack会在报文刚进入到IP层的时候进行conntrack记录（下面简称ct）的初始化，这个可以从ipv4_conntrack_in()/ipv4_conntrack_local()的实现看出来，这两个函数都会调用nf_conntrack_in()，这个函数会从conntrack的哈希表中根据当前报文的元组信息查找对应的ct，并恢复到skb报文上。如果没有找到对应的ct，那么就会调用init_conntrack()创建新的ct，整个过程可以从resolve_normal_ct()看出来。查找到（或者创建）ct后，内核会将ct以及上面说的状态设置到skb的_nfct字段上（通过nf_ct_set函数）。

由于NAT、IPVS等模块都会使用到ct，因此这里的钩子函数要先于其他模块执行，其优先级也比较高，为NF_IP_PRI_CONNTRACK。

在将ct设置到skb上之后，内核还会调用特定协议的处理函数还对ct进行进一步的处理，这个由nf_conntrack_handle_packet()来完成。以TCP为例，TCP会在ct上维护一些TCP特有的状态信息（如SYN_SEND、SYN_RECEIVE等）以及做一些合法性校验等。比如在TCP报文的序列号或者ACK号不在窗口范围内，那么会重置skb上的ct，不对其进行trace。

4.3 conntrack的确认

在报文离开IP协议层之前，内核会对ct进行确认。ct的确认只会进行一次，确认过后会设置对应的标志位，在后续的报文中不会再重复确认。ipv4的确认会调用ipv4_confirm，最终会调用__nf_conntrack_confirm。所谓的确认，就是将ct插入到nf_conntrack_hash这个哈希表中。由于报文从进入到离开IP层，报文内容可能会被修改（如NAT、IPVS等），所以confirm需要在最后进行，这也是为什么在POSTROUTING的HOOK点中conntrack的钩子函数的优先级是最低的。

ct的插入函数为__nf_conntrack_hash_insert()：

static void __nf_conntrack_hash_insert(struct nf_conn *ct,
				       unsigned int hash,
				       unsigned int reply_hash)
{ 
   
	hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
			   &nf_conntrack_hash[hash]);
	hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_REPLY].hnnode,
			   &nf_conntrack_hash[reply_hash]);
}

从这个函数里可以看出，进行哈希插入的时候插入的并不是ct，而是ct上的tunplehash，其对tunplehash[0]和tunplehash[1]分别进行了哈希。这是合理的，以下图的一个简单的转发（forward）报文为例，同一个连接的ct需要能够根据两个方向的报文来进行哈希查找，因此需要把两个方向的元组加入到哈希表。同时，根据查找到的元组是哪一个（第一个还是第二个）可以判断出当前报文的方向（ORIGIN或者REPLY）。

4.4 NAT原理

netfilter的NAT模块与conntrack是分不开的，因此这里就一块介绍吧。NAT可以分为SNAT（源地址转发）和DNAT（目的地址转发），能够进行NAT的模块由iptables、nftables等。需要注意的是无论是iptables还是nftables，其使用的NAT都是netfilter提供的，是在netfilter中实现的，iptables/nftables本身只是对netfilter的NAT的简单调用。这里同样以IPV4的NAT为例来进行一下介绍。

static const struct nf_hook_ops nf_nat_ipv4_ops[] = { 
   
	/* Before packet filtering, change destination */
	{ 
   
		.hook		= nf_nat_ipv4_in,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_PRE_ROUTING,
		.priority	= NF_IP_PRI_NAT_DST,
	},
	/* After packet filtering, change source */
	{ 
   
		.hook		= nf_nat_ipv4_out,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_POST_ROUTING,
		.priority	= NF_IP_PRI_NAT_SRC,
	},
	/* Before packet filtering, change destination */
	{ 
   
		.hook		= nf_nat_ipv4_local_fn,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_LOCAL_OUT,
		.priority	= NF_IP_PRI_NAT_DST,
	},
	/* After packet filtering, change source */
	{ 
   
		.hook		= nf_nat_ipv4_fn,
		.pf		= NFPROTO_IPV4,
		.hooknum	= NF_INET_LOCAL_IN,
		.priority	= NF_IP_PRI_NAT_SRC,
	},
};

NAT的钩子点可以说是与conntrack的相辅相成，也是在那四个HOOK点上注册的钩子函数。这四个钩子函数最终都会调用相同的函数nf_nat_inet_fn()，所以我们只需要看这一个函数就够了。

这里需要澄清几个概念。首先是代码里的maniptype，这个是用来区分SNAT和DNAT的HOOK点的，它的值包括：

• NF_NAT_MANIP_SRC：代表当前HOOK点需要检查是否需要进行SNAT，这个在包括POSTROUTING和LOCAL_IN两个HOOK点
• NF_NAT_MANIP_DST：代表当前HOOK点需要检查是否需要进行DNAT，这个包括PREROUTING和LOCAL_OUT两个HOOK点

其次是NAT初始化的问题。在ct从创建到被确认这段期间，会完成对ct上的NAT状态的初始化的工作。其中，在NF_NAT_MANIP_SRC处会进行SNAT状态的初始化；在NF_NAT_MANIP_DST处进行DNAT状态的初始化。这里的初始化是实现NAT的关键，从下面的switch语句可以看出在当前ct未进入到ESTABLISHED状态（收到了REPLY报文）都会走到初始化流程。

这里需要再说明一下NAT的钩子函数的注册。上面已经分析了，netfilter在四个HOOK点上注册钩子，那么加入我们使用nftable/iptables往加一条NAT类型的链会发生什么呢？此时这个链对应的nf_hook_ops不会注册到netfilter的HOOK点上，而是会注册到对应的HOOK点上的NAT的钩子函数的私有字段中去。当NAT的钩子函数发现自己身上注册了别的钩子，那么就会调用这些钩子去进行NAT的初始化，也就是在这里netfilter将控制权交给nftables/iptables的。如果没有找到钩子，那么就会调用netfilter默认的初始化函数nf_nat_alloc_null_binding()来进行NAT的初始化。

unsigned int
nf_nat_inet_fn(void *priv, struct sk_buff *skb,
	       const struct nf_hook_state *state)
{ 
   
	struct nf_conn *ct;
	enum ip_conntrack_info ctinfo;
	struct nf_conn_nat *nat;
	/* maniptype == SRC for postrouting. */
	enum nf_nat_manip_type maniptype = HOOK2MANIP(state->hook);

	/* 该函数为netfilter进行NAT的核心函数，在prerouting、postrouting、 * local_out和local_in处都会被调用。 */

	/* NAT收发包处理逻辑。首先检查是否存在conntrack信息，如果没有的话就直接 * 返回ACCEPT。 CONNTRACK模块会先于NAT模块进行conntrack信息的创建。 * * conntrack的创建发生于PREROUTING（ipv4_conntrack_in()函数里）或者 * LOCAL_OUT（ipv4_conntrack_local()函数），由此可以看出内核会对所有 * 本地发送出去的报文和接收到的报文进行conntrack跟踪。 */

	ct = nf_ct_get(skb, &ctinfo);
	if (!ct)
		return NF_ACCEPT;

	nat = nfct_nat(ct);

	switch (ctinfo) { 
   
	case IP_CT_RELATED:
	case IP_CT_RELATED_REPLY:
		/* Only ICMPs can be IP_CT_IS_REPLY. Fallthrough */
	case IP_CT_NEW:

		/* 进行NAT两个方向上的初始化。这个过程一般在触发conntrack * 记录创建的那个报文的处理过程中完成。 * * 在PREROUTING/LOCAL_OUT处会完成DNAT的初始化； * 在POSTROUTING/LOCAL_IN处会完成SNAT的初始化。 */
		if (!nf_nat_initialized(ct, maniptype)) { 
   
			struct nf_nat_lookup_hook_priv *lpriv = priv;
			struct nf_hook_entries *e = rcu_dereference(lpriv->entries);
			unsigned int ret;
			int i;

			if (!e)
				goto null_bind;

			/* 遍历当前ops上的entries，并进行报文的处理。如果当前 * HOOK点上存在ops且对该报文进行了NAT，那么ct上的NAT * 信息就会被初始化，然后跳转到do_nat。 */

			for (i = 0; i < e->num_hook_entries; i++) { 
   
				ret = e->hooks[i].hook(e->hooks[i].priv, skb,
						       state);
				if (ret != NF_ACCEPT)
					return ret;
				if (nf_nat_initialized(ct, maniptype))
					goto do_nat;
			}
null_bind:
			/* 缺省的NAT初始化函数（不进行NAT） */
			ret = nf_nat_alloc_null_binding(ct, state->hook);
			if (ret != NF_ACCEPT)
				return ret;
		} else { 
   
			pr_debug("Already setup manip %s for ct %p (status bits 0x%lx)\n",
				 maniptype == NF_NAT_MANIP_SRC ? "SRC" : "DST",
				 ct, ct->status);
			if (nf_nat_oif_changed(state->hook, ctinfo, nat,
					       state->out))
				goto oif_changed;
		}
		break;
	default:
		/* ESTABLISHED */
		WARN_ON(ctinfo != IP_CT_ESTABLISHED &&
			ctinfo != IP_CT_ESTABLISHED_REPLY);
		if (nf_nat_oif_changed(state->hook, ctinfo, nat, state->out))
			goto oif_changed;
	}
do_nat:
	/* 在ct中的NAT信息初始化好后，调用这里来进行报文内容的修改。这里会 * 在ct->status标记为启用了NAT的情况下使用ct里的信息来修改报文的 * 内容（地址、端口等）。 */
	return nf_nat_packet(ct, ctinfo, state->hook, skb);

oif_changed:
	nf_ct_kill_acct(ct, ctinfo, skb);
	return NF_DROP;
}

无论是默认的初始化函数，还是默认的初始化函数，最终都会调用nf_nat_setup_info()这个函数。这个函数的作用包括：

• 从range里选取一个可用的（未被使用）的元组，并设置到ct的REPLY方向的那个元组上
• 设置NAT初始化的状态

注意这里的range，其里面存放的是元组的范围。如果当前函数是由默认的初始化函数调用，那么range存放的就是原始元组（参考nf_nat_alloc_null_binding()的实现），使用get_unique_tuple()获取到的新元组必定和原来一样；如果是nftables/iptables的钩子函数，那么这里的range存放的就是目标元组（SNAT的话，是源地址、端口信息；DNAT的话，是目的地址信息），获取到的新元组必定与原来的不一样（可参考nft_nat_eval()函数的实现）。

unsigned int
nf_nat_setup_info(struct nf_conn *ct,
		  const struct nf_nat_range2 *range,
		  enum nf_nat_manip_type maniptype)
{ 
   
	struct net *net = nf_ct_net(ct);
	struct nf_conntrack_tuple curr_tuple, new_tuple;

	/* Can't setup nat info for confirmed ct. */
	if (nf_ct_is_confirmed(ct))
		return NF_ACCEPT;

	/* 该函数进行conntrack记录中NAT的状态初始化工作，包括从range里获取 * 可用元组、进行ct状态的设置等。 */

	WARN_ON(maniptype != NF_NAT_MANIP_SRC &&
		maniptype != NF_NAT_MANIP_DST);

	if (WARN_ON(nf_nat_initialized(ct, maniptype)))
		return NF_DROP;

	/* What we've got will look like inverse of reply. Normally * this is what is in the conntrack, except for prior * manipulations (future optimization: if num_manips == 0, * orig_tp = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple) */
	nf_ct_invert_tuple(&curr_tuple,
			   &ct->tuplehash[IP_CT_DIR_REPLY].tuple);

	/* 获取可用的元组（存放到tuple变量中）。该方法会先检查当前元组 * （origin_tuple）是否可用，如果可用的话就直接使用。判断是否可用的依据 * 是使用nf_nat_used_tuple()判断元组是否已经被占用。 * * 如果已经被占用，那么就会从可选区域中查找可用的地址或者端口，并存放到 * tunple中。 * * 对于NAT来说，一般像iptables/nftables会调用nf_nat_setup_info()来 * 初始化SNAT或者DNAT里的元组信息，初始化的时候将range设定为自己想要的 * 值。在初始化完成后，netfilter会调用nf_nat_packet()来根据ct里的信息 * 来修改报文。 * * 注意：对于SNAT或者DNAT操作，new_tuple和curr_tuple不会相等，因为 * range里会限定要修改的地址或者端口范围。所以，对于SNAT或者DNAT， * ct->status标志位中一定设置了IPS_SRC_NAT或者IPS_DST_NAT。 */
	get_unique_tuple(&new_tuple, &curr_tuple, range, ct, maniptype);

	if (!nf_ct_tuple_equal(&new_tuple, &curr_tuple)) { 
   
		struct nf_conntrack_tuple reply;

		/* 如果新元组与老的不一样，那说明发送了SNAT或者DNAT。此时，将 * 新的元组应用到ct上。 */
		/* Alter conntrack table so will recognize replies. */
		nf_ct_invert_tuple(&reply, &new_tuple);
		nf_conntrack_alter_reply(ct, &reply);

		/* 根据当前的HOOK点判断是发生了SNAT还是DNAT。 */
		if (maniptype == NF_NAT_MANIP_SRC)
			ct->status |= IPS_SRC_NAT;
		else
			ct->status |= IPS_DST_NAT;

		if (nfct_help(ct) && !nfct_seqadj(ct))
			if (!nfct_seqadj_ext_add(ct))
				return NF_DROP;
	}

	if (maniptype == NF_NAT_MANIP_SRC) { 
   
		unsigned int srchash;
		spinlock_t *lock;

		srchash = hash_by_src(net,
				      &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple);
		lock = &nf_nat_locks[srchash % CONNTRACK_LOCKS];
		spin_lock_bh(lock);
		hlist_add_head_rcu(&ct->nat_bysource,
				   &nf_nat_bysource[srchash]);
		spin_unlock_bh(lock);
	}

	/* 走到这里，说明NAT冲突检测已经完成，已经进入了可以进行NAT的状态。 */
	if (maniptype == NF_NAT_MANIP_DST)
		ct->status |= IPS_DST_NAT_DONE;
	else
		ct->status |= IPS_SRC_NAT_DONE;

	return NF_ACCEPT;
}

在完成了NAT的初始化后，nf_nat_inet_fn -> nf_nat_packet函数会被调用，这个函数是用来根据ct里的元组信息对报文内容进行修改的：

unsigned int nf_nat_packet(struct nf_conn *ct,
			   enum ip_conntrack_info ctinfo,
			   unsigned int hooknum,
			   struct sk_buff *skb)
{ 
   
	enum nf_nat_manip_type mtype = HOOK2MANIP(hooknum);
	enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
	unsigned int verdict = NF_ACCEPT;
	unsigned long statusbit;

	/* 判断当前的HOOK点是SNAT还是DNAT，并且与ct是在进行SNAT还是DNAT进行 * 对比，如果一致的话就说明需要进行NAT（修改报文）。 */
	if (mtype == NF_NAT_MANIP_SRC)
		statusbit = IPS_SRC_NAT;
	else
		statusbit = IPS_DST_NAT;

	/* 如果报文是响应报文，那么判断的方向也应该取反。比如SNAT，这里认为 * PREROUTING的HOOK点应该要对响应报文做处理。 */
	if (dir == IP_CT_DIR_REPLY)
		statusbit ^= IPS_NAT_MASK;

	/* Non-atomic: these bits don't change. */
	if (ct->status & statusbit)
		verdict = nf_nat_manip_pkt(skb, ct, mtype, dir);

	return verdict;
}

从上面的流程中可以看出来，nftables/iptables中的NAT规则只有在ct刚创建的时候会被使用，一旦ct创建完成，后面的报文都不会再使用NAT规则，只会根据ct上的信息来进行NAT。这里可以看出，即使删除对应的NAT规则，也不会影响到现有连接的进行。

这里需要说明的是，conntrack、nat的钩子是在被使用的时候才会注册。nat依赖于conntrack，所以nat的钩子注册的时候会触发conntrack钩子的注册；nftables/iptables的NAT依赖于netfilter的NAT，因此当nftables添加NAT类型的链的时候会触发netfilter的NAT的钩子的注册（注销也是同样的原理）。