9.8. Netfilter 和 IP Tables (2.4 内核)

在开发 IP 防火墙链时，Paul Russell 认为 IP 防火墙应该更容易使用；他随即开始简化内核防火墙代码中数据报处理的各个方面，并生成了一个更加清晰且更灵活的过滤框架。他将这个新框架称为 netfilter。

那么 IP chains 到底有什么问题呢？ 它们极大地提高了防火墙规则的效率和管理。 但是它们处理数据报的方式仍然很复杂，尤其是在结合防火墙相关功能（如 IP 伪装（在第 11 章中讨论））和其他形式的地址转换时。 这种复杂性的一部分存在是因为 IP 伪装和网络地址转换是独立于 IP 防火墙代码开发的，并在以后集成，而不是从一开始就被设计为防火墙代码的真正组成部分。 如果开发人员想要在数据报处理序列中添加更多功能，他将难以找到插入代码的位置，并且将被迫更改内核才能做到这一点。

不过，仍然存在其他问题。 特别是，“input”链将输入描述为整个 IP 网络层的输入。 input 链影响目的地为此主机的报文和由此主机路由的报文。 这有点违反直觉，因为它将 input 链的功能与 forward 链的功能混淆了，后者仅适用于要转发的数据报，但始终遵循 input 链。 如果您想以不同于转发的数据报的方式处理发送到此主机的数据报，则需要构建复杂的规则来排除其中一个或另一个。 同样的问题也适用于 output 链。

不可避免地，这种复杂性的一部分会蔓延到系统管理员的工作中，因为它反映在必须设计规则集的方式中。 此外，对过滤的任何扩展都需要直接修改内核，因为所有过滤策略都在那里实现，并且无法为其提供透明的接口。 netfilter 通过在内核中实现一个通用框架来解决旧解决方案的复杂性和刚性，该框架简化了数据报的处理方式，并提供了一种扩展过滤策略的能力，而无需修改内核。

让我们看一下所做的两个主要更改。图 9-8 说明了 IP chains 实现中如何处理数据报，而图 9-9 说明了 netfilter 实现中如何处理它们。 主要区别在于从核心代码中删除了伪装功能，以及 input 和 output 链的位置发生了变化。 为了配合这些更改，创建了一个新的可扩展的配置工具，称为 iptables。

在 IP chains 中，input 链适用于主机接收的所有数据报，无论它们是发往本地主机还是路由到其他主机。 在 netfilter 中，input 链仅适用于发往本地主机的数据报，而 forward 链仅适用于发往另一台主机的数据报。 同样，在 IP chains 中，output 链适用于离开本地主机的所有数据报，无论该数据报是在本地主机上生成的还是从其他主机路由的。 在 netfilter 中，output 链仅适用于在此主机上生成的数据报，而不适用于从另一主机路由的数据报。 仅此更改就极大地简化了许多防火墙配置。

在图 9-8中，标记为“demasq”和“masq”的组件是单独的内核组件，负责伪装数据报的传入和传出处理。 这些已重新实现为 netfilter 模块。

考虑这样一种配置，其中每个 input、forward 和 output 链的默认策略是拒绝。 在 IP chains 中，需要六条规则才能允许任何会话通过防火墙主机：input、forward 和 output 链中各有两条规则（一条规则涵盖每个转发路径，另一条规则涵盖每个返回路径）。 您可以想象，当您想要混合可以路由的会话和可以连接到本地主机而不被路由的会话时，这很容易变得非常复杂且难以管理。 IP chains 允许您创建可以简化此任务的链，但设计并不明显，并且需要一定的专业知识。

在带有 iptables 的 netfilter 实现中，这种复杂性完全消失了。 对于要跨防火墙主机路由但不在本地主机上终止的服务，只需要两条规则：forward 链中每个正向和反向方向各一条规则。 这是设计防火墙规则的显而易见的方法，并且将极大地简化防火墙配置的设计。

PACKET-FILTERING-HOWTO 提供了已进行的更改的详细列表，因此让我们在这里重点关注更实际的方面。