Linux 內核是一個快速發展的項目，但有時候一些改動的進展仍是出乎意料的緩慢。替換內核數據包過濾子系統(packet-filtering subsystem)的 nftables 項目起源于 2008 年，但仍未被大多數(甚至可能更多)生產系統中的防火墻場景使用起來。不過，正如 8 月 19 日發布的 nftables 1.0.0 所強調的那樣，這一變化可能已經越來越近了。

[[423263]]

第一個公開的 nftables 版本是由 Patrick McHardy 在 2009 年初發布的。當時，內核有一個以 iptables 這個形式存在的具備類似功能的數據包過濾子系統，當然，它雖然一直被人們廣泛使用，但有一些問題促使著人們提出了改動。這些問題包括：內核存在著(并且現在仍然是這樣)好幾個包過濾機制：一個用于 IPv4，另一個用于 IPv6，還有一個用于 ARP，等等。這些子系統中的每一個基本上都是完全獨立的，有很多重復代碼。除此之外，iptables 還包含了太多的內置協議相關的信息，并且 API 比較難用，所以很難在不替換整個規則集的情況下來更新其中的一個規則。

nftables 核心理念是要丟棄所有的協議感知(protocol-aware)那些機制，取而代之的是一個可以從用戶空間來開發配置的簡單的虛擬機。管理員仍然可以寫出一些涉及到特定的數據包頭字段之類的規則，但用戶空間的工具會將這些規則轉化為更底層的獲取和比較操作，然后將生成的東西加載到內核中去。這樣一來數據包過濾引擎就更加小巧靈活了，可能會表現更好。總的來說，一旦能將大量用戶過渡過來的話，應該是一件有好處的事情。

nftables 在推出時引起了一些轟動，但后來就陷入困境并從人們的視線中消失了，也許是因為 McHardy 花了更多精力去進行更多的法律訴訟了。不過在 2013 年的時候 Pablo Neira Ayuso 重新啟動了這個項目，他的想法是盡快將代碼并入主線，在這一點上他成功了，在 2014 年初的時候 nftables 進入了 3.13 內核。

此后的工作一直是在努力填補空缺功能，使 nftables 能具有足夠的吸引力讓用戶愿意遷移過來。編寫過濾規則的語言已經獲得了許多許多功能，包括有狀態跟蹤(stateful tracking)、創建地址映射、高效處理地址間隔(address intervals)和大規模的規則鏈，以及支持了眾多協議。當然，還包括文檔。nftables 維基頁面就有很多信息介紹這一切是如何工作的。

當然，要讓大家從 iptables 過渡過來，還有一個很大的阻礙：大量早已部署的、使用 iptables 的防火墻。在許多情況下，重寫防火墻規則可能是最好的行動方案，因為許多復雜的過濾配置在新方案中可以更有效地表達出來。但是，對于那些只想讓他們之前辛辛苦苦開發出來的防火墻能繼續工作的管理員來說，nftables 可能就沒有人們想象的那么吸引人了。nftables 的開發者已經開發了一套腳本，將 iptables 防火墻翻譯成 nftables 的描述，這應該會有所幫助，但遷移仍是一個很大的變化。

某些情況下，用戶可能實際上會在不知不覺中完成這個大轉變。Linux 發行版中已經支持 nftables 一段時間了，而且正在努力將紅帽的 firewalld 等工具移植到 nftables。這樣以來，用戶可能一開始接觸到的就不是 iptables 規則，因此他足夠幸運的話，就完全不會注意到底層機制已經改變了。

這種變化何時會發生呢?還有點難說。2018 年 Netfilter 研討會宣稱，iptables 是“一個過時的工具”，它的日子已經不多了。2019 年的 Debian 10 “buster” 版本中默認切換到了 nftables，而 Ubuntu 直到 21.04 版本才跟進。雖然幾乎所有的發行版都搭載了 nftables，但很多還沒有默認使用起來。

nftables 1.0.0 的發布可以被看作是一個信號，即現在是那些落伍者需要更認真地考慮進行切換的時候了。雖然 iptables 的支持應該不太可能會很快地被移除掉，但完全可以預料到維護 iptables 的熱情會持續減弱。新的功能將會在 nftables 中出現，而用戶最終則需要遷移過來才能利用好這些新功能。雖然 只 花了 13 年時間，但這個過渡似乎終于要進入最后階段了。

不過還有一個有趣的問題。2018 年 BPF 開發者宣布了 bpfilter，一個運行在 BPF 虛擬機上的數據包過濾機制，在當時引起了一些關注。BPF 過去的發展勢頭非常好(而且現在也保持著)，它做了很多工作來優化虛擬機并使其可以安全地工作。可以說，合理的策略應該是使用它，而不是維護另一個單單只用于包過濾工作的虛擬機。這樣就可以去掉一堆代碼，把維護工作集中在 BPF 上。

bpfilter 代碼在 4.18 內核發布時被包含了進去，并且帶來了一個“用戶模式 blobs”機制，旨在促進防火墻規則向新方案的轉變。然而，從那時起這段代碼的開發就停止了。在 2021 年間，net/bpfilter 的代碼只有兩次(而且都是微不足道)的修改。2020 年 6 月討論了要不要刪除這段代碼，但當時它幸存了下來。從那時起，塵封的蛛網只會越積越厚，似乎可以判斷說，bpfilter 目前并不是一個在活躍開發的領域，而且它似乎也不太可能很快取代 nftables 了。

還很難說這個判斷是否是“正確的”。也許 nftables 所使用的專門用途的虛擬機比起通用用途的 BPF 能更好地解決這個特有領域的問題。或者說，nftables 之所以能夠勝出，僅僅是因為它背后的開發者持續活躍著并推動著項目的發展。內核開發成功的關鍵之一很簡單，就是要有持續性。對于像數據包過濾這樣關鍵的子系統來說，這一點更是如此，知道開發人員是長期投入參與進來的，是會讓人們非常安心的。