netfilter_netfilter 锁开销_netfilter iptables(14)

以上的代表所表示的发送或应答的状态如下图所示：

6. ip_confirm

以上的工作事实上都很简单，基本思路是：

一个包来了，转换其tuple，看其在连接跟踪表中没有，有的话，更新其状态，以其做一些与协议相关的工作，如果没有，则分配一个新的连接表项，并与skb_buff关连，但是问题是，这个表项，还没有被加入连接表当中来。其实这样做的理由很简单，因为这个时候，这个包是否有机会活命还是个未知数，例如被其它模块给Drop了……所以，要等到一切安全了，再来将这个表项插入至连接跟踪表。

这个“一切安全”当然是Netfilter所有的模块处理完了，最完全了。

当数据包要离开Netfilter时，它会穿过NF_IP_POST_ROUTINGHook点，状态跟踪模块在这里注册了ip_refrag函数（前面谈到过它的优先级是很低的）。这个Hook函数的工作，也可以猜测到了：“判断表项是否已经在连接跟踪表中了，如果没有，就将其插入表中”！

static unsigned int ip_refrag(unsigned int hooknum,

			      struct sk_buff **pskb,

			      const struct net_device *in,

			      const struct net_device *out,

			      int (*okfn)(struct sk_buff *))

{

	struct rtable *rt = (struct rtable *)(*pskb)->dst;



	/* ip_confirm函数用于处理将tuple加入hash表等重要的后续处理 */

	if (ip_confirm(hooknum, pskb, in, out, okfn) != NF_ACCEPT)

		return NF_DROP;



	/* 在连接跟踪开始之前，对分片包进行了重组，这里判断数据包是否需要分片，如果要分片，就调用ip_fragment分片函数将数据包分片发送出去，因为数据包已经被发送走了，所以，在它之后的任何Hook函数已经没有意思了 */

	if ((*pskb)->len > dst_mtu(&rt->u.dst) &&

	    !skb_shinfo(*pskb)->tso_size) {

		/* No hook can be after us, so this should be OK. */

		ip_fragment(*pskb, okfn);

		return NF_STOLEN;

	}

	return NF_ACCEPT;

}

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-31885-14.html