linux的netfilter框架设计.pdfVIP

Netfilter简介 Linux2.4.x开始引入Netfilter子系统（以下简称NF），它作为一个通用的、抽象的框架， 提供一整套的 hook 函数的管理机制，使得诸如数据包过滤、网络地址转换(NAT)和基于协 议类型的连接跟踪成为了可能。内核在网络协议栈的关键点引入NF_HOOK 宏，从而搭建 起了整个 Netfilter 框架。 NF数据流向 对于收到的每个数据包，都从 “A”点进来，经过路由判决，如果是发送给本机的就经 过 “B”点，然后往协议栈的上层继续传递；否则，如果该数据包的目的地是不本机，那么 就经过 “C”点，然后顺着 “E”点将该包转发出去。 对于发送的每个数据包，首先也有一个路由判决，以确定该包是从哪个接口出去，然后 经过 “D”点，最后也是顺着 “E”点将该包发送出去。 协议栈那五个关键点 A，B，C，D 和 E 就是NF埋伏的地方。对应到NF框架，各称谓如 下图： 钩子函数调用流程 NF 中的不同钩子点调用了不同的钩子函数，其调用的流程框架如下图所示。图中所示箭头 为调用流程。 钩子函数的存储机制 钩子函数由一个全局二维链表数组 nf_hooks 保存，其按照协议族归类存储，在每个协 议族中，根据钩子点顺序排列，在钩子点内则根据钩子函数的优先级依次排列。钩子函数的 存储图如下图所示，链表中的每个节点都是一个 nf_hook_ops 结构，nf_hook_ops 实际存 储了钩子函数的内容，其结构如图所示。在相应的钩子点调用钩子函数时，则根据协议 族和钩子点找到相应的链表入口，然后依次调用该链中的每一个钩子函数对数据包进行操 作。 钩子函数的管理机制 如果需要在相应的钩子点挂载钩子函数，则需要首先定义一个 nf_hook_ops 结构，在其 中实现实际的钩子函数，再调用函数 nf_register_hook()将该钩子函数注册到上图所示的二维 链表中，nf_register_hook()函数的定义如下： intnf_register_hook(structnf_hook_ops*reg) { structlist_head*i; interr; err=mutex_lock_interruptible(nf_hook_mutex); if(err0) returnerr; list_for_each(i,nf_hooks[reg-pf][reg-hooknum]) { if(reg-priority((structnf_hook_ops*)i)-priority) break; } list_add_rcu(reg-list,i-prev); mutex_unlock(nf_hook_mutex); return0; } 钩子函数返回值 在每个关键点上，有很多已经按照优先级预先注册了的回调函数(这些函数称为 “钩子 函数”)埋伏在这些关键点，形成了一条链。对于每个到来的数据包会依次被那些回调函数 “调戏”一番再视情况是将其放行，丢弃还是怎么滴。但是无论如何，这些回调函数最后必 须向 Netfilter 报告一下该数据包的死活情况， 因为毕竟每个数据包都是 Netfilter 从人家 协议栈那儿借调过来给兄弟们 Ha y 的，协议栈再怎么滴也总得 “活要见人，死要见尸” 吧。每个钩子函数最后必须向 Netfilter 框架返回下列几个值其中之一： NF_ACCEPT 继续正常传输数据报。这个返回值告诉 Netfilter：到目前为止，该数据包 还是被接受的并且该数据包应当被递交到网络协议栈的下一个阶段。 NF_DROP 丢弃该数据报，不再传输，并且为这个数据包申请的所有资源都要得到释 放。 NF_STOLEN 接管数据报，告诉 Netfilter “忘掉”该数据报。也就是说钩子函数会在这 里对这个数据包进行完全处理。但是，这并不意味着该数据包的资源已经 被释放。这个数据包以及它独自的 sk_buff 数据结构仍然有效，只是回调 函数从 Netfilter 获取了该数据包的所有权。 NF_QUEUE 让这个数据包在用户空间排队(通常用于将数据报给用户空间的进程进 行处理) NF_REPEAT 当用户改变了该数据包包头的某些信息时，那可以请求netfilter再次调 用这个钩子函数对它进行操作。应当谨慎使用这个值，以免造成死循环。 协议，hook点，ho