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

[[423263]]

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

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

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

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

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

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

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

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

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

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

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