每一条iptables配置的rule都包含了匹配条件(match)部分和目标(target)。当报文途径HOOK点时,Netfilter会逐个遍历挂在该钩子点上的表的rule,若报文满足rule的匹配条件,内核就会执行目标(target)。

扩展匹配条件的表示

而匹配条件又可以分为标准匹配扩展匹配两部分,其中前者有且只有一个,而后者有零到多个。在Netfilter中,标准匹配条件用ipt_entry表示(这个在上一篇文章中已经说过了),其中包括源地址和目的地址等基本信息,而扩展匹配条件用ipt_entry_match表示:

这个结构上面是一个union,下面是一个柔性数组。union的元素有三个,抛开最后一个用于对齐的match_size,前两个元素表示它在用户空间和内核空间的有不同的解释(这个结构在linux内核代码和iptables应用程序代码中定义一样)

什么意思呢? 还是以本文开头的那条rule为例,这条rule使用了tcp扩展模块,匹配条件为--dport 80,所以用户态的iptables程序会这样理解这个结构:

当内核收到这条rule时,会根据名字"tcp"去从Netfilter框架中"搜索"已注册的扩展匹配条件,若找到,就设置其match指针.这样,从内核Netfilter的角度来看,扩展匹配条件就变成了这样:

扩展匹配条件的注册

上面的过程之所以能搜索到扩展匹配条件,有一个隐含的前提就是"tcp"这个xt_match事先被注册到Netfilter框架了。这部分工作是在xt_tcpudp.c定义的内核模块中完成的。

通过xt_register_match接口,各个内核模块可以完成扩展匹配条件的注册。

扩展匹配条件的匹配时机

当数据包真的到达时,Netfilter会调用各个表安装的钩子函数,这些钩子函数用表中的每条rule去尝试匹配数据包