B.1. 模块装载问题

装载模块时，您可能会碰到几个问题，比如，有错误提示说明没有您指定名字的那种模块：

insmod: iptable_filter: no module by 

that name found

这个提示是无关紧要的，因为那些模块很有可能已被静态地编译进内核了。当您碰到这个信息时，这是您应该首先想到的。至于是否真的如我们所想，最简单的测试方就是敲一个用到那个模块功能的命令试试。对于上面的情况，可能是filter表没有装入，从而就没有相应的功能，当然不能使用filter表了。为了检查 filter表是否装入，能够用下面的命令来试试：

iptables -t filter -L

   

这个命令会输出filter表里任何的链，或是运行失败，给出错误提示信息。假如一切正常，输出结果类似下面的情况，当然，这还要看您是否已在filter表里加入了规则（译者注：在这个例子里，表是空的）。

Chain INPUT (policy ACCEPT)

target     prot opt source               destination



Chain FORWARD (policy ACCEPT)

target     prot opt source               destination



Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

    

假如您确实没有装载filter表，得到的就是如下信息：

iptables 

v1.2.5: can't initialize iptables table `filter': Table      does not exist (do you need to insmod?)

Perhaps iptables or your kernel needs to be upgraded.

    

这个问题就有些严重了，从此提示中我们能得到两个信息：第一，我们确实没有把相应的功能编译进内核里；第二，在模块一般应在的目录中没有找到这个模块。这意味着问题是，您或忘记了装载想用的模块，或没有用depmod -a命令更新模块数据库，或没有把相应的功能编译进内核（不论是静态的还是作为模块）。当然还可能是其他原因，但这些是主要的，不管怎样，大部分原因是很容易解决的。比如，第一个问题能够简单地通过在内核源码目录里运行make modules_install 命令来解决，这当然是有前提的，就是源码已编译（compile）而且模块已构建（build）。第二个问题的解决办法也很简单，只要运行一下depmod -a命令，之后再看看能否正常工作即可。第三个问题有点超出我们的范围了，而且这个问题或多或少会让您感到发晕。更多的信息能够在Linux文档计划里找到。

在运行iptables时，您还可能得到另外一个错误信息：

iptables: No chain/target/match by that name

   

这说明您要用的链或target、或match不存在，原因有很多，但最普遍的是您拼错了名字。当您想使用一个不可用的模块时也会产生这种错误。模块之所以不可用，可能是因为您没有装载正确的模块，或内核里不包含那个模块，或是iptables自动装载模块时失败了。通常，您不止应该考虑上面提到的任何解决办法，还要考虑规则中target的拼写错误，或其他的原因。

B.2. 未配置SYN的NEW状态包

iptables有个“特点”没有被很好地给以说明，所以很多人（当然，也包括我）都忽视了他。这个“特点”就是：假如您使用状态NEW，那么未配置SYN的包也会通过防火墙。之所以有这个特点，是因为在某些情况下，我们想把那样的包看作某个（比如是和另一个防火墙有关的）已处于ESTABLISHED状态的连接的一部分。这个特点使拥有两个或更多的防火墙协同工作成为可能，而且可使数据在服务器间无丢失的传输，如辅助防火墙能够接受子网的防火墙的操作。但他也会导致这样的事情：状态 NEW会允许几乎任何的TCP连接进入，而不管是否有3次握手。为了处理这个问题，我们需要在防火墙的 INPUT链、OUTPUT链和FORWARD链加入如下规则（译者注：此规则作者称为“NEW not SYN rules”，下一小节还会提到）：

$IPTABLES -A 

INPUT -p tcp ! --syn -m state --state NEW -j LOG      --log-prefix "New not syn:"

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

    

警告，在Netfilter/iptables项目中，这个特点所拥有的行为缺少文档说明，更明确的说，在您的防火墙上，他是个很不安全的因素。

注意，这个规则用于microsoft的TCP/IP（微软实现的TCP/IP就是不行，至少现在不行）产生的包时还是有些问题。假如包是由microsoft的产品生成的，且被标为状态NEW，那么就会被此规则记录然后丢弃。看起来规则工作很正常啊，是吧。但问题就出在这儿了，因为连接无法中断了。这个问题出现在关闭连接时，在最后一个包即FIN/ACK包发出后，Netfilter的状态机制就会关闭连接、删除连接跟踪表里的相应记录。但就在这时，Microsoft那不完善的程式会发送另外一个包，这个包就是那种未配置SYN且被认为是NEW状态的包，因此他就会被上面的规则匹配。换句话说，就是对这个规则无需过于关注，假如您很在意他，就在规则里加入选项--log-headers吧。这样，您就能够把包头记录下来，从而能够更好地了解相应的包。

对于这个规则，更有一些已知的问题。比如，某个连接（比如是从LAN发出的）已连接到防火墙，而且有个脚本要在启动PPP时激活。当您启动PPP连接时，刚才提到的那个连接可能就会被干掉（be killed）。当然，这只会在特定的情况下才能发生，就是您把conntrack和nat作为模块运行，并且每次运行那个脚本时这两个模块都要被装入和卸载。假如您在防火墙之外的机子上运行telnet，而且又通过这个telnet连接运行脚本

文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!