https://lwn.net/Articles/747504

bpfilter 的基本思想是它可以处理 iptables 查询和在用户空间中将它们转换为 BPF 程序。

bpfilter 的核心设计功能之一是能够将现有的 iptables 规则转换为 BPF 程序。此功能旨在使现有防火墙配置能够轻松转移到新方案，甚至系统管理员都不知道正在发生这种情况。

我们可能不会在近期看到 bpfilter 进入主线内核。但考虑到参与开发的开发人员，bpfilter 显然是一项严肃的计划，其最终目标是进入主线。

结论：xdp的ebpf只能作为netfilter的cache存在，无状态，功能有限，全靠map关联状态，且关联到interface，所以完全替代netfilter当前是不可能的。

为什么内核社区要用 BPF 重写 iptables

作者注：本文由长期从事 Linux 内核网络开发人员和 Cilium 项目创建者的 Thomas Graf 撰写

Linux 内核社区最近宣布了bpfilter，它将用 Linux BPF 重写 iptables 在内核态工作的那部分代码，同时保证 Linux 用户的无中断过渡。

1. iptables 和顺序过滤的根源

多年来，iptables 一直是在 Linux 上实现防火墙和数据包过滤器的主要工具。iptables 及其前身 ipchains 从很早以前就成为我个人 Linux 之旅的一部分。最初是作为用户，后来是作为内核开发人员。多年来，iptables 既是福音也是祸害：福音在于它的灵活性和快速修复。在调试 5K 个规则 的 iptables 设置时，祸害就来了。

我们知道，Linux防火墙架构经历了 ip firewall, ipchains, iptables, nftables, 越发完美，但是性能一直都是问题，毕竟不管何种框架，防火墙规则都是以某种 列表 的形式存在的，内核并没有对列表进行任何处理，在内核协议栈的处理经路上顺序callback一堆list回调函数，这是问题的根源。

更加可恶的是，iptables规则不支持增量配置，因此无论是规则的增删改查，其时间复杂度均为O(n)。

2. 中间解决方法：ipset

随着时间的推移，网络速度不断提高，iptables 设置也从十几条规则增加到数千条规则。从性能和延迟的角度来看，遍历连续的 iptables 列表已经变得难以忍受。

社区很快发现了最常见的瓶颈：一长串规则要么拒绝，要么允许单个 IP 地址和端口组合。这导致了ipset的引入。ipset 允许将匹配 IP 地址和/或端口组合的规则列表压缩到哈希表中，以减少 iptables 规则的总体数量。此后，这一直是一种解决方法，而没有解决核心问题本身。

不幸的是，ipset 并不能解决所有问题。一个突出的例子是 ，它是Kubernetes kube-proxy的一个组件，它使用 iptables 和规则为服务提供负载平衡。它为服务所服务的每个后端安装多个 iptables 规则。对于添加到 Kubernetes 的每个服务，要遍历的 iptables 规则列表会呈指数级增长。-j DNAT

最近的KubeCon 演讲 详细分析了 kube-proxy 的性能。演讲中展示了一些测量结果，表明随着服务数量的增加，延迟不可预测且性能下降。它还揭示了 iptables 的另一个主要弱点：缺乏增量更新。每次添加新规则时，都必须替换整个规则列表。这导致安装代表 20K Kubernetes 服务的 160K iptables 规则总共需要 5 个小时。

使用基于 IP/端口的机制通常有许多其他明显的缺点，特别是在应用程序容器时代。容器频繁部署和拆除。这可能导致单个 IP 地址的生命周期很短。一个 IP 地址可能只被一个容器使用几秒钟，然后在几秒钟后被另一个容器重新使用。这给依赖于使用 IP 地址进行安全过滤的系统带来了压力，因为集群中的所有节点都必须不断了解最新的 IP 到容器的映射。虽然这在集群内并不难，但在集群之间就变得极具挑战性。深入探讨细节超出了这篇博文的范围，所以我们将留到以后的文章中。

3. 一个 BPF 统治一切

近年来，BPF 的发展速度非常快，解锁了以前超出内核范围的功能。这得益于 BPF 提供的强大而高效的可编程性。以前需要自定义内核开发和内核重新编译的任务现在可以在 BPF 沙箱的安全边界内使用高效的 BPF 程序来实现。

BPF 演变过程中的最新进展是一个令人兴奋的提议，即以对用户完全透明的方式用 BPF 完全替换 iptables 的内核部分，即现有的 iptables 客户端二进制文件和库将继续工作。

必须注意的是，bpfilter 和 BPF 本身无法解决 iptables 使用顺序列表所导致的性能问题。要解决这些问题，需要像 Cilium 项目那样原生使用BPF 。

4. 概括

我认为 BPF 是多年来最令人兴奋的 Linux 开发成果。我们仅仅触及了它的潜力，它仍在不断发展。用 BPF 替换 iptables 的内核部分是合乎逻辑的第一步。真正的过渡将是转向 BPF 原生工具，并摆脱传统的以 IP 地址/端口为中心的结构。

上一篇 « 下一篇 »