Netfilter是Linux2.4内核实现数据包过滤、数据包处理、NAT等的功能框架。该文讨论了linux 2.4内核的netfilter功能框架，还对基于netfilter框架上的包过滤，NAT和数据包处理(packet mangling)进行了讨论。阅读本文需要了解2.2内核中ipchains的原理和使用方法作为预备知识，若你没有这方面的知识，请阅读IPCHAINS-HOWTO。
一、什么是Netfilter
Netfilter比以前任何一版Linux内核的防火墙子系统都要完善强大。Netfilter提供了一个抽象、通用化的框架，该框架定义的一个子功能的实现就是包过滤子系统。因此不要在2.4中期望讨论诸如"如何在2.4中架设一个防火墙或者伪装网关"这样的话题，这些只是Netfilter功能的一部分。Netfilter框架包含以下三部分：
1.为每种网络协议(IPv4、IPv6等)定义一套钩子函数（IPv4定义了5个钩子函数),这些钩子函数在数据报流过协议栈的几个关键点被调用。在这几个点中，协议栈将把数据报及钩子函数标号作为参数调用netfilter框架。
2.内核的任何模块可以对每种协议的一个或多个钩子进行注册，实现挂接，这样当某个数据包被传递给netfilter框架时，内核能检测是否有任何模块对该协议和钩子函数进行了注册。若注册了，则调用该模块的注册时使用的回调函数，这样这些模块就有机会检查(可能还会修改)该数据包、丢弃该数据包及指示netfilter将该数据包传入用户空间的队列。
3.那些排队的数据包是被传递给用户空间的异步地进行处理。一个用户进程能检查数据包，修改数据包，甚至可以重新将该数据包通过离开内核的同一个钩子函数中注入到内核中。
所有的包过滤/NAT等等都基于该框架。内核网络代码中不再有到处都是的、混乱的修改数据包的代码了。当前netfilter框架在IPv4、IPv6及Decnet网络栈中被实现。
二、为什么需要Netfilter
其实这个问题也可以变为ipchains有什么缺点导致被抛弃？下面只是其中的几个原因：
因为基于2.2内核的ipchains没有提供传递数据包到用户空间的框架，所以任何需要对数据包进行处理的代码都必须运行在内核空间，而内核编程却非常复杂，而且只能用C语言实现，并且容易出现错误并对内核稳定性造成威胁。
透明代理实现非常复杂，必须查看每个数据包来判断是否有专门处理该地址的socket。网络栈代码中在11个文件中共出现了34个"#ifdef"条件编译。
创建一个不依赖于接口地址的数据报过滤规则是不可能实现的。我们必须利用本地接口地址来判断数据报是本地发出、还是发给本地的或是转发的。转发链只有输出接口的信息，因此管理员必需考虑数据报的源。
伪装和数据包过滤都在同一个模块内实现，导致防火墙代码过于复杂。
IPchains代码即不模块化又不易于扩展(例如对mac地址的过滤)
三、Netfilter的作者
Netfilter框架的概念的提出及主要实现是由Rusty Russell完成的，他是ipchains的合作完成者及当前linux内核IP防火墙的维护者。还有Marc BoUCher、James Morris、Harald Welte等都参与了Netfilter项目。
四、Netfilter在IPv4中的结构
一个数据包按照如下图所示的过程通过Netfilter系统：
--->[1]--->[ROUTE]--->[3]--->[4]--->
^
local
[ROUTE]
v
[2] [5]
^
v
从图中可以看到IPv4一共有5个钩子函数，分别为：
1 NF_IP_PRE_ROUTING
2 NF_IP_LOCAL_IN
3 NF_IP_FORWARD
4 NF_IP_POST_ROUTING
5 NF_IP_LOCAL_OUT
数据报从左边进入系统，进行IP校验以后，数据报经过第一个钩子函数NF_IP_PRE_ROUTING[1]进行处理；然后就进入路由代码，其决定该数据包是需要转发还是发给本机的；若该数据包是发被本机的，则该数据经过钩子函数NF_IP_LOCAL_IN[2]处理以后然后传递给上层协议；若该数据包应该被转发则它被NF_IP_FORWARD[3]处理；经过转发的数据报经过最后一个钩子函数NF_IP_POST_ROUTING[4]处理以后，再传输到网络上。
[1] [2] 下一页
本地产生的数据经过钩子函数NF_IP_LOCAL_OUT [5]处理可以后，进行路由选择处理，然后经过NF_IP_POST_ROUTING[4]处理以后发送到网络上。
五、Netfilter基础
从上面关于IPv4的netfilter的例子讨论，可以看到钩子函数是如何被激活的。
内核模块可以对一个或多个这样的钩子函数进行注册挂接，并且在数据报经过这些钩子函数时被调用，从而模块可以修改这些数据报，并向netfilter返回如下值：
NF_ACCEPT 继续正常传输数据报
NF_DROP 丢弃该数据报，不再传输
NF_STOLEN 模块接管该数据报，不要继续传输该数据报
NF_QUEUE 对该数据报进行排队(通常用于将数据报给用户空间的进程进行处理)
NF_REPEAT 再次调用该钩子函数
六、使用iptables进行数据报选择
一个基于Netfilter框架的、称为iptables的数据报选择系统在Linux2.4内核中被应用，其实它就是ipchains的后继工具，但却有更强的可扩展性。
内核模块可以注册一个新的规则表(table)，并要求数据报流经指定的规则表。这种数据报选择用于实现数据报过滤(filter表)，网络地址转换(Nat表)及数据报处理(mangle表)。
Linux2.4内核提供的这三种数据报处理功能都基于netfilter的钩子函数和IP表。它们是独立的模块，相互之间是独立的。它们都完美的集成到由Netfileter提供的框架中。
包过滤
filter表格不会对数据报进行修改，而只对数据报进行过滤。iptables优于ipchains的一个方面就是它更为小巧和快速。它是通过钩子函数NF_IP_LOCAL_IN, NF_IP_FORWARD及NF_IP_LOCAL_OUT接入netfilter框架的。因此对于任何一个数据报只有一个地方对其进行过滤。这相对ipchains来说是一个巨大的改进，因为在ipchains中一个被转发的数据报会遍历三条链。
NAT
NAT表格监听三个Netfilter钩子函数：NF_IP_PRE_ROUTING、NF_IP_POST_ROUTING及NF_IP_LOCAL_OUT。 NF_IP_PRE_ROUTING实现对需要转发的数据报的源地址进行地址转换而NF_IP_POST_ROUTING则对需要转发的数据包的目的地址进行地址转换。对于本地数据报的目的地址的转换则由NF_IP_LOCAL_OUT来实现。
NAT表格不同于filter表格，因为只有新连接的第一个数据报将遍历表格，而随后的数据报将根据第一个数据报的结果进行同样的转换处理。
NAT表格被用在源NAT,目的NAT，伪装(其是源NAT的一个特例)及透明代理(其是目的NAT的一个特例)。
数据报处理(Packet mangling)
mangle表格在NF_IP_PRE_ROUTING和NF_IP_LOCAL_OUT钩子中进行注册。使用mangle表，可以实现对数据报的修改或给数据报附上一些带外数据。当前mangle表支持修改TOS位及设置skb的nfmard字段。
七、连接跟踪
连接跟踪是NAT的基础，但是已经作为一个单独的模块被实现。该功能用于对包过滤功能的一个扩展，使用连接跟踪来实现“基于状态”的防火墙。
（出处：http://www.sheup.com）
上一页 [1] [2]
七、连接跟踪
连接跟踪是NAT的基础，但是已经作为一个单独的模块被实现。该功能用于对包过滤功能的一个扩展，使用连接跟踪来实现“基于状态”的防火墙。
（出处：http://www.sheup.com）
上一页 [1] [2] [3]