netfilter如何理解Netfilter中的连接跟踪机制

网络适配器下面出现netfilter device #518 620 等等 总共7个 不知道啥意思 求解

你给的资料不够详细。

。

简单来说，驱动不匹配。

试着解决： 1.禁用设备，再启用，不要自动查找驱动，用你确认正确的驱动去安装。

2.安装驱动精灵，让驱动精灵自动上网安装（前提是你得通过别的方式上网，比如无线网卡或3G网卡等，现在好多手机也都能充当调制解调器拨号上网） 3.如果是台式机，实在不行就买个USB网卡，25RMB，简单了事。

可以禁用netfilter device吗？

你可以在“我的电脑”右键“属性”，在设备管理器中，那个有“叹号”filter device #XXX，右键“卸载”驱动，在“确认设备卸载”对话柜下方的“删除设备的驱动程序软件”选项选中，再“确认”即可！

在Linyx 系统中， Netfilter包过滤防火墙主要工作在OSI参考模型的（ ）

不管什么系统，只要是遵循OSI七层参考模型的，数据包始终是工作在第三层网络层上的，数据帧始终是工作在第二层数据链路层上的，二进制比特流始终是工作在最底层物理层上的。

开机显示netfilter device #193，是什么意思，谢谢高手指点

是不是开机蓝屏出现这个错误提示？不filter是什么？是不是写错了？通常这种问题的解决方法有以下几点：1.先尝试将硬盘、光驱的数据线拔下清洁之后插上去看能不能解决。

2.拔掉光驱数据线单接硬盘看看是否能解决，有可能是光驱故障引起的。

3.查看BIOS中硬盘信息是否准确，有可能是硬盘电路板有问题。

4.用MHDD扫描一下硬盘是否有坏道。

5.内存清洁也十分必要。

6.如果以上都试过仍未解决就重装一下系统。

关键是你提着问题没有详细的描述无法具体分析。

如何理解Netfilter中的连接跟踪机制

连接跟踪定义很简单：用来记录和跟踪连接的状态。

　　为什么又需要连接跟踪功能呢？因为它是状态防火墙和NAT的实现基础。

　　Neftiler为了实现基于数据连接状态侦测的状态防火墙功能和NAT地址转换功能才开发出了连接跟踪这套机制。

那就意思是说：如果编译内核时开启了连接跟踪选项，那么Linux系统就会为它收到的每个数据包维持一个连接状态用于记录这条数据连接的状态。

接下来我们就来研究一下Netfilter的连接跟踪的设计思想和实现方式。

　　之前有一副图，我们可以很明确的看到：用于实现连接跟踪入口的hook函数以较高的优先级分别被注册到fitler的NF_IP_PRE_ROUTING和NF_IP_LOCAL_OUT两个hook点上；用于实现连接跟踪出口的hook函数以非常低的优先级分别被注册到filter的NF_IP_LOCAL_IN和NF_IP_POST_ROUTING两个hook点上。

　　其实PRE_ROUTING和LOCAL_OUT点可以看作是整filter的入口，而POST_ROUTING和LOCAL_IN可以看作是其出口。

在只考虑连接跟踪的情况下，一个数据包无外乎有以下三种流程可以走： 　　一、发送给本机的数据包 　　流程：PRE_ROUTING----LOCAL_IN---本地进程，如果是新的包，在PREROUTING处生成连接记录，通过POSTROUTING后加到hash表 　　二、需要本机转发的数据包 　　流程：PRE_ROUTING---FORWARD---POST_ROUTING---外出，在PREROUTING处生成连接记录，在LOCAL_IN处把生成的连接记录加到hash表 　　三、从本机发出的数据包 　　流程：LOCAL_OUT----POST_ROUTING---外出，在LOCAL_OUT处生成连接记录，在POSTROUTING处把生成的连接记录加到hash表。

　　我们都知道在INET层用于表示数据包的结构是大名鼎鼎的sk_buff{}(后面简称skb)，如果你不幸的没听说过这个东东，那么我强烈的建议你先补一下网络协议栈的基础知识再继续阅读这篇文章。

在skb中有个成员指针nfct，类型是struct nf_conntrack{}，该结构定义在include/linux/skbuff.h文件中。

该结构记录了连接记录被公开应用的计数，也方便其他地方对连接跟踪的引用。

连接跟踪在实际应用中一般都通过强制类型转换将nfct转换成指向ip_conntrack{}类型(定义在include/filter_ipv4/ip_conntrack.h里)来获取一个数据包所属连接跟踪的状态信息的。

即：Neftilter框架用ip_conntrack{}来记录一个数据包与其连接的状态关系。

　　同时在include/filter_ipv4/ip_conntrack.h文件中还提供了一个非常有用的接口：struct ip_conntrack *ip_conntrack_get(skb, ctinfo)用于获取一个skb的nfct指针，从而得知该数据包的连接状态和该连接状态的相关信息ctinfo。

从连接跟踪的角度来看，这个ctinfo表示了每个数据包的几种连接状态： 　　l IP_CT_ESTABLISHED 　　Packet是一个已建连接的一部分，在其初始方向。

　　l IP_CT_RELATED 　　Packet属于一个已建连接的相关连接，在其初始方向。

　　l IP_CT_NEW 　　Packet试图建立新的连接 　　l IP_CT_ESTABLISHED+IP_CT_IS_REPLY 　　Packet是一个已建连接的一部分，在其响应方向。

　　l IP_CT_RELATED+IP_CT_IS_REPLY 　　Packet属于一个已建连接的相关连接，在其响应方向。

　　在连接跟踪内部，收到的每个skb首先被转换成一个ip_conntrack_tuple{}结构，也就是说ip_conntrack_tuple{}结构才是连接跟踪系统所“认识”的数据包。

那么skb和ip_conntrack_tuple{}结构之间是如何转换的呢？这个问题没有一个统一的答案，与具体的协议息息相关。

例如，对于TCP/UDP协议，根据“源、目的IP+源、目的端口”再加序列号就可以唯一的标识一个数据包了；对于ICMP协议，根据“源、目的IP+类型+代号”再加序列号才可以唯一确定一个ICMP报文等等。

对于诸如像FTP这种应用层的“活动”协议来说情况就更复杂了。

本文不试图去分析某种具体协议的连接跟踪实现，而是探究连接跟踪的设计原理和其工作流程，使大家掌握连接跟踪的精髓。

因为现在Linux内核更新的太快的都到3.4.x，变化之大啊。

就算是2.6.22和2.6.21在连接跟踪这块还是有些区别呢。

一旦大家理解了连接跟踪的设计思想，掌握了其神韵，它再怎么也万变不离其宗，再看具体的代码实现时就不会犯迷糊了。

俗话说“授人一鱼，不如授人一渔”，我们教给大家的是方法。

有了方法再加上自己的勤学苦练，那就成了技能，最后可以使得大家在为自己的协议开发连接跟踪功能时心里有数。

这也是我写这个系列博文的初衷和目的。

与君共勉。

　　在开始分析连接跟踪之前，我们还是站在统帅的角度来俯视一下整个连接跟踪的布局。

这里我先用比较粗略的精简流程图为大家做个展示，目的是方便大家理解，好入门。

当然，我的理解可能还有不太准确的地方，还请大牛们帮小弟指正。

　　我还是重申一下：连接跟踪分入口和出口两个点。

谨记：入口时创建连接跟踪记录，出口时将该记录加入到连接跟踪表中。

我们分别来看看。

　　入口： 　　整个入口的流程简述如下：对于每个到来的skb，连接跟踪都将其转换成一个tuple结构，然后用该tuple去查连接跟踪表。

如果该类型的数据包没有被跟踪过，将为其在连接跟踪的hash表里建立一个连接记录项，对于已经跟踪过了的数据包则不用此操作。

紧接着，调用该报文所属协议的连接跟踪模块的所提供的packet()回调函数，最后根据状态改变连接跟踪记录的状态。

　　出口： 　　整个出口的流程简述如下：对于每个即将离开Netfilter框架的数据包，如果用于处理该协议类型报文的连接跟踪模块提供了helper函数，那么该数据包首先会被helper函数处理，然后才去判断，如果该报文已经被跟踪过了，那么其所属连接的状态，决定该包是该被丢弃、或是返回协议栈继续传输，又或者将其加入到连接跟踪表中。

　　连接跟踪的协议管理： 　　我们前面曾说过，不同协议其连接跟踪的实现是不相同的。

每种协议如果要开发自己的连接跟踪模块，那么它首先必须实例化一个ip_conntrack_protocol{}结构体类型的变量，对其进行必要的填充，然后调用ip_conntrack_protocol_register()函数将该结构进行注册，其实就是根据协议类型将其设置到全局数组ip_ct_protos[]中的相应位置上。

　　ip_ct_protos变量里保存连接跟踪系统当前可以处理的所有协议，协议号作为数组唯一的下标，如下图所示。

　　结构体ip_conntrack_protocol{}中的每个成员，内核源码已经做了很详细的注释了，这里我就不一一解释了，在实际开发过程中我们用到了哪些函数再具体分析。

　　连接跟踪的辅助模块： 　　Netfilter的连接跟踪为我们提供了一个非常有用的功能模块：helper。

该模块可以使我们以很小的代价来完成对连接跟踪功能的扩展。

这种应用场景需求一般是，当一个数据包即将离开Netfilter框架之前，我们可以对数据包再做一些最后的处理。

从前面的图我们也可以看出来，helper模块以较低优先级被注册到了Netfilter的LOCAL_OUT和POST_ROUTING两个hook点上。

　　每一个辅助模块都是一个ip_conntrack_helper{}结构体类型的对象。

也就是说，如果你所开发的协议需要连接跟踪辅助模块来完成一些工作的话，那么你必须也去实例化一个ip_conntrack_helper{}对象，对其进行填充，最后调用ip_conntrack_helper_register{}函数将你的辅助模块注册到全局变量helpers里，该结构是个双向链表，里面保存了当前已经注册到连接跟踪系统里的所有协议的辅助模块。

　　全局helpers变量的定义和初始化filter/nf_conntrack_helper.c文件中完成的。

　　最后，我们的helpers变量所表示的双向链表一般都是像下图所示的这样子： 　　由此我们基本上就可以知道，注册在Netfilter框架里LOCAL_OUT和POST_ROUTING两个hook点上ip_conntrack_help()回调函数所做的事情基本也就很清晰了：那就是通过依次遍历helpers链表，然后调用每个ip_conntrack_helper{}对象的help()函数。