夜已深然未央，準(zhǔn)備接著講述有關(guān)Netfilter的故事，行文有點松散，由于未打草稿，有點隨意識而流，一氣呵成不知是自夸還是自嘲，權(quán)當(dāng)小時候?qū)懙娜沼洶?#xff0c;自幼喜歡每天寫日記，中學(xué)時更是以退士為名折騰了幾箱子抄本，前幾年由于喝酒就改為周記了，現(xiàn)在意識到了生命短暫，時間甚是不夠用，不能在迷迷糊糊 中得過且過，就準(zhǔn)備把自己知道的關(guān)于Linux網(wǎng)絡(luò)的東西一點一滴記錄下來，本來想繼續(xù)行文于紙上，然而發(fā)現(xiàn)在個人電腦智能手機(jī)時代，很多字早就不會寫 了...上回沒有說完關(guān)于iptables的故事，本文繼續(xù)...

一.nftables前傳-iptables之弊端

iptables幾乎是無人不知無人不曉，人們被卷入了框框也就覺得任何事情都是理所當(dāng)然，但我例外，和其他很多事情一樣，在這個領(lǐng)域，我依然做并且樂于做那個“被排除的人”。

iptables的諸多弊端已經(jīng)不能再視而不見，然而只有很少的人看到了這些，大多數(shù)的人作為使用者，僅僅是使用罷了。在此我不會吐槽很多了。以下的弊端來自nftables的宣傳文檔，但是即使是在國外，也引發(fā)了超級多的爭論：

1.iptables框架在內(nèi)核態(tài)知道得太多，以至于產(chǎn)生了大量的代碼冗余。

這一點是顯而易見的，比如對于TCP和UDP而言，取sport，dport沒有什么不同，但是iptables卻使用了兩套代碼，這只是一個例子，類似的還有很多。

2.iptables的rule結(jié)構(gòu)設(shè)計不合理。

1.iptables的結(jié)構(gòu)

iptables由表，鏈，規(guī)則組成，其中規(guī)則又由match，target組成。如下面的結(jié)構(gòu)所示：

Table{Chain[Rule(match,match,match,...)->target,Rule(match,match,match,...)->target,...],Chain[...],... }

2.iptables的規(guī)則匹配執(zhí)行流程

iptables的規(guī)則是按照配置順序順序匹配的，在每一張表的每一個鏈上依次匹配每一條規(guī)則，在每一條規(guī)則依次匹配每一個match，全部匹配的match執(zhí)行該規(guī)則的target，由target決定：

• a.繼續(xù)匹配下一條規(guī)則
• b.對數(shù)據(jù)包做一些修改
• c.跳轉(zhuǎn)到其它的鏈(即開始從該鏈依次匹配該鏈上的每一條規(guī)則)
• d.返回引發(fā)跳轉(zhuǎn)的鏈(即繼續(xù)匹配跳轉(zhuǎn)前的鏈的下一條規(guī)則)
• e.丟棄數(shù)據(jù)包
• f.接收數(shù)據(jù)包(即不再繼續(xù)往下匹配，直接返回)
• g.記錄日志
• h....

資料直通車：最新Linux內(nèi)核源碼資料文檔+視頻資料

學(xué)習(xí)直通車：Linux內(nèi)核源碼/內(nèi)存調(diào)優(yōu)/文件系統(tǒng)/進(jìn)程管理/設(shè)備驅(qū)動/網(wǎng)絡(luò)協(xié)議棧

整個iptables框架執(zhí)行的流程如下：

循環(huán)1:static breakrule = 0;遍歷一個chain的每一條rule {nomatch = 0;循環(huán)2:遍歷一條rule的每一個match {result = rule->match[curr](skb, info);if(result != MATCH) {nomatch = 1;break;}}if (nomatch == 1) {continue該chain的下一條rule;}result = rule->target(skb, info);if (result == DROP) {break丟棄數(shù)據(jù)包 } else if (result == ACCEPT) {break接受數(shù)據(jù)包} else if (result == GOTO) {breakrule = rule;跳轉(zhuǎn)到相應(yīng)的chain，執(zhí)行循環(huán)1} else if (result == RETURN) {break返回調(diào)用chain，執(zhí)行其breakrule的下一條rule} ... }

看了上述的代碼就基本知道了iptables的命令實現(xiàn)，程序員能做的就是擴(kuò)展iptables的功能，具體的做法有兩個：寫一個match以及寫一個target。除此之外，程序員就沒轍了，剩下的就看使用者的想象力了...

通過上面的流程，可以發(fā)現(xiàn)，包過濾的流程最終要落實到規(guī)則匹配，而過濾的動作最終落實到了該規(guī)則的target，前面的所有的match匹配返回結(jié)果就是0或者非0表示是否匹配，只有所有的match均匹配，才會執(zhí)行target。這就決定了下面幾件事：

a.如果你想實現(xiàn)多個target，就不得不寫多條規(guī)則

比如實現(xiàn)log和drop，那么就要寫兩條規(guī)則，或者擴(kuò)展一個LOG_and_DROP target，前者影響效率，后者需要編程。你很在乎性能，同時你又不是程序員不懂編程，你就抓狂了...

b.你可以寫一個match，在里面偷偷摸摸做一點事情，但是外部不知道

這一切太不正規(guī)了，你可以在一個match里面把一個數(shù)據(jù)包的校驗碼改掉，也可以在里面做log，做NAT什么的，但是iptables的框架的本意雖不允許你這么做但是又沒有阻止你的行為。

我們可以在iptables執(zhí)行流的一個細(xì)節(jié)(上述的流程中未畫出)中看到另一個細(xì)節(jié)，即iptables在match中僅僅確定“是否匹配”真的已經(jīng)很 不夠，就連代碼都設(shè)計得很勉強。如果你看ipt_do_table這個核心函數(shù)，會發(fā)現(xiàn)一個控制變量名叫hotdrop，這個變量是干什么的呢？按照注釋 的意思是：

@hotdrop: drop packet if we had inspection problems

這 個hotdrop作為傳出參數(shù)傳入每一個match回調(diào)函數(shù)，用于在match內(nèi)部指示將一個數(shù)據(jù)包丟棄。這就暴露出了設(shè)計的不足，丟棄一個數(shù)據(jù)包不是 target要做的嗎？一個match的職責(zé)是選擇該數(shù)據(jù)包是否匹配，干嘛要指示丟棄它呢？這不是越級么？這只是一個細(xì)節(jié)，你可以說出一千個理由表明它是 合理的，但是它卻是丑陋的！

二.一點小歷史

弄清楚歷史總是能明白更多，這絕對是一句真話，但是恰恰是專業(yè)化阻止了大多數(shù)的程序員去讀歷史，哪怕是IT的歷史。最好的歷史資料就是原著，Netfilter的歷史不長，從Linux 2.3.15內(nèi)核版本被引入至今，不會像老子莊子那樣被篡改地體無完膚。

我們當(dāng)然要看iptables被引入的那段歷史。

iptables被引入旨在替掉ipchains，因為當(dāng)時ipchains的維護(hù)者Rusty Russell認(rèn)識到它擁有諸多的弊端。總的說來，弊端有兩個，其它的都是由這兩個而發(fā)：

a.內(nèi)核的firewall框架僅僅設(shè)置了3個檢查點，即input，forward，output，對于環(huán)回包以及indev，outdev的控制力很弱；

b.代碼寫死，匹配項固定，沒有可擴(kuò)展性。

問 題就在這里的b。針對問題a，Rusty Russell提出了Netfilter的設(shè)計，精心設(shè)計了5個HOOK點，解決了幾乎所有的控制點的問題，特別是OUTPUT點的設(shè)計頂級絕妙，它被安 放在路由之后，原因在于Linux協(xié)議棧的路由操作之后才會給出完整的過濾匹配項，比如源IP地址，出口設(shè)備等，路由之后的OUTPUT同時給了調(diào)用者再 次路由的權(quán)限。FORWARD和INPUT作為路由的二分，同時保持了無用功最少化，因為如果你沒有打開ip_forward選項，即便不是INPUT的 數(shù)據(jù)包也不會進(jìn)入FORWARD，如果根本就沒有找到路由，則既不會到達(dá)INPUT，也不會到達(dá)FORWARD。對于PREROUTING而言，它可以通 過conntrack區(qū)分本地環(huán)回流量和網(wǎng)卡進(jìn)入流量...不管怎么說，這是內(nèi)核的工作，這個Netfilter的設(shè)計十分完美，至今依然被使用。

對于問題b，Rusty Russell提出了iptables，它是一個高度可擴(kuò)展的框架，也就是從此時起，iptables擁有了match/target配對的擴(kuò)展方式，每 當(dāng)需要擴(kuò)展的時候，每一個match/target除了有用戶態(tài)的lib之外，還有用內(nèi)核態(tài)的支持，它將ipchains時代的固定匹配模式變成了可以自 己編程擴(kuò)展的了。

針對ipchains的弊端，Rusty Russell可謂是給出了完美的解決方案，然而僅此而已！任何一個來自同一作者的新的框架幾乎均是為了解決上一個框架的弊端的，iptables作為一 個新秀，在獲得歡呼的時候，不會有人去考慮它的弊端，任何事情都是這樣，不是嗎？

iptables的弊端是被逐步發(fā)現(xiàn)的，Rusty Russell作為ipchains和iptables的共同作者，它對待后者取代前者的態(tài)度永遠(yuǎn)都是保守的，一個全新的框架需要另一個人或者團(tuán)隊來提 出，而不可能出現(xiàn)在Rusty Russell本人手里以及iptables團(tuán)隊的內(nèi)部。

針對Netfilter，Rusty寫了大量的文檔，均在Netfilter網(wǎng)站上可以找到：?http://people.netfilter.org/rusty/unreliable-guides/不可否認(rèn)，這些都是珍貴的第一手資料，對于我們理解Netfilter，可能沒有比這些更好的了。任何人都可以從這些原著中找到“XX為何會這樣”這種問題的蛛絲馬跡，同時它們也是指導(dǎo)你如何改進(jìn)現(xiàn)有框架的明燈。

三.nftables登場

鑒于iptables的諸多缺點(其實并不是缺點，但是match/target配對的擴(kuò)展方式導(dǎo)致了開發(fā)者延伸了劣勢，最終將其確定為缺點)，nftables旨在一個個地改進(jìn)它們。

首先是兩個問題：

a.如何使用一種統(tǒng)一的方式來解析數(shù)據(jù)包

在這個問題的解決上，u32 match給了作者思路

b.如何執(zhí)行多個action

事 實上，是iptables的matches/target配對的方式限制了開發(fā)者的思路。為何非要區(qū)分match和target呢？iptables框架 的執(zhí)行流程限制了match的結(jié)果就是個布爾型，所有的動作都在target中執(zhí)行，如果去掉了這個限制，將整個流程都開放給開發(fā)者，那就靈活多了。 nftables就在這樣的背景下登場了。事實證明，nftables做的比修正弊端更多，走的更遠(yuǎn)。

首先nftables采用了“虛擬機(jī)解釋字節(jié)碼”的方式，使一條rule真的成了“為一個數(shù)據(jù)包做一些事情”這樣靈活的命令，而去掉了“匹配所有的 match之后執(zhí)行一個target”這樣的限制。虛擬機(jī)執(zhí)行字節(jié)碼的方式早就被BPF采用了，我們熟知的tcpdump抓包程序就是利用的它來過濾的數(shù) 據(jù)包。我們來看一下nftables框架的執(zhí)行流程：

循環(huán)1:static breakrule = 0;遍歷一個chain的每一條rule {nomatch = 0;reg[MAX]循環(huán)2:遍歷一條rule的每一個expression {void rule->expression[curr]->operations->expr(skb, info, reg)if(reg[VERDICT] != CONTINUE) {break;}}if (reg[VERDICT] == CONTINUE) {continue該chain的下一條rule;} else if (reg[VERDICT] == DROP) {break丟棄數(shù)據(jù)包 } else if (reg[VERDICT] == ACCEPT) {break接受數(shù)據(jù)包} else if (reg[VERDICT] == GOTO) {breakrule = rule;跳轉(zhuǎn)到相應(yīng)的chain，執(zhí)行循環(huán)1} else if (reg[VERDICT] == RETURN) {break調(diào)用chain，執(zhí)行其breakrule的下一條rule} ... }

光從這個流程上看，就已經(jīng)可以和iptables分出勝負(fù)了。可以看到，nftables沒有match和target，而是將一 條rule抽象成了若干條的表達(dá)式，即expression，所謂的表達(dá)式就是一個主語加謂詞的式子，它是“可執(zhí)行”的，它可以“做任何事情”，而不僅僅 是計算一個匹配結(jié)果。除此之外，nftables內(nèi)置了一組寄存器，其中之一是verdict寄存器，它指示了“下一步要怎么做”。

每一條 expression執(zhí)行完了之后，會取出該寄存器，由該寄存器的值來采取下一步的行動。這個verdict寄存器替換了iptables中target 返回值，這就可以在一條rule中采取多個動作，每條動作可以解析成一個expression，每一個expression在執(zhí)行后將verdict寄存 器設(shè)置為CONTINUE即可！

除了執(zhí)行流程的顯著區(qū)別之外，nftables最大的意義在于它對expression進(jìn)行了抽象，nftables的內(nèi)核框架可以注冊很多種的 expression，每一種都有一個操作集，其中expr回調(diào)函數(shù)執(zhí)行具體的expression表達(dá)式。典型的expression有：

payload表達(dá)式：

將一個數(shù)據(jù)包的某一段數(shù)據(jù)拷貝到一個nftables寄存器指示的緩沖區(qū)，除了出錯之外verdict寄存器均為CONTINUE。

compare表達(dá)式：

將某段數(shù)據(jù)和nftables寄存器指示的緩沖區(qū)作比較，若不相等則設(shè)置verdict寄存器為BREAK。

counter表達(dá)式：

按照數(shù)據(jù)包的大小遞增字節(jié)計數(shù)器以及包計數(shù)器的值，保持verdict寄存器為CONTINUE。

log表達(dá)式：

對數(shù)據(jù)包記錄日志，保持verdict寄存器為CONTINUE。

nat表達(dá)式：

按照nftables寄存器的數(shù)值對數(shù)據(jù)包做NAT，verdict寄存器設(shè)置為NAT操作的結(jié)果，注意，NAT的參考數(shù)據(jù)均來自nftables寄存器。

compat表達(dá)式：

保 持對iptables的兼容性。細(xì)分為match寄存器以及target寄存器，其中match表達(dá)式調(diào)用iptables rule的match，若匹配設(shè)置verdict寄存器為CONTINUE，否則為BREAK；target表達(dá)式調(diào)用iptables rule的target，并根據(jù)target的結(jié)果設(shè)置verdict寄存器。

回到nftables的執(zhí)行流程，結(jié)合上述的表達(dá)式，看看這一切像什么？

這難道不就是一個解釋器嗎？類似高級語言比如Python的解釋器，將每一個表達(dá)式解釋執(zhí)行，我們可以將一條nftables rule分解為一系列的表達(dá)式，僅此而已，如下所示：

expr1: reg[verdict] = CONTINUE; reg[0] = skb[m...n]; expr2: info[0] = something from userspace; ret = compare(reg[0], info[0]);if (ret == true) ; then reg[verdict] = CONTINUE; else reg[verdict] = BREAK; break; fi expr3: log_packet(skb); expr4: ret = do_nat_packet(skb, reg[i]/*address to trans*/...); if (ret == true) ; then reg[verdict] = CONTINUE; else reg[verdict] = BREAK; break; fi ...

看看吧，一條規(guī)則做了多少事情啊啊啊！解釋器按照expr1到expr4的順序執(zhí)行expression，每次執(zhí)行下一個expression之前要檢查verdict寄存器，那么誰是解釋器，當(dāng)然就是上面的nftables的執(zhí)行流程啦！

nftables到底是什么玩意兒？實則一個虛擬機(jī)！那么這部虛擬機(jī)執(zhí)行的指令來自何方？來自用戶態(tài)的配置。用戶態(tài)怎么配置？當(dāng)然是使用nft命令。nft是什么命令？是類似iptables的命令。nft命令能否舉一個例子？能：

nft add rule ip filter input ip saddr 1.1.1.1 drop

這 條命令怎么和諸多的表達(dá)式對應(yīng)？答案是nft命令行工具內(nèi)置了一個”編譯器“，將一條human readable命令編譯成了一個個的expression代碼。編譯的細(xì)節(jié)是什么？可以寫一本書，但是了解一下tcpdump的方式也就該能理解了。 tcpdump命令最終會將編譯好的指令注入到內(nèi)核的BPF系統(tǒng)，以下是一條很常見的tcpdump命令：

tcpdump -i eth0 dst 1.1.1.1

它會翻譯成什么代碼呢？后面跟上-dd參數(shù)就可以看出來：

root@debian:/usr/local/etc/nftables# tcpdump -i eth0 dst 1.1.1.1 -dd { 0x28, 0, 0, 0x0000000c }, { 0x15, 0, 2, 0x00000800 }, { 0x20, 0, 0, 0x0000001e }, { 0x15, 4, 5, 0x01010101 }, { 0x15, 1, 0, 0x00000806 }, { 0x15, 0, 3, 0x00008035 }, { 0x20, 0, 0, 0x00000026 }, { 0x15, 0, 1, 0x01010101 }, { 0x6, 0, 0, 0x0000ffff }, { 0x6, 0, 0, 0x00000000 },

具 體是什么意思請參考BPF的手冊。nftables設(shè)置的規(guī)則最終也會被”編譯“成類似的”指令“注入到內(nèi)核的nftables系統(tǒng)，形成一個個的 expression。要注意，并不是所有的規(guī)則指令都是可以編譯的，比如iptables兼容指令就不能編譯，log指令也不能被編譯。

nftables就是這樣一個具有美感的包過濾框架，理解了它的運行方式之后，你就可以擴(kuò)展它了，和iptables擴(kuò)展match/target不同， 對于nftables，你只需要擴(kuò)展expression即可，就是說你要自己編寫expression，然后讓nftables虛擬機(jī)(即上面的執(zhí)行流 程)執(zhí)行它就可以了。最后，我們來看一下nftables框架的結(jié)構(gòu)：

Table{Chain[Rule(expression,expression,expression,...)Rule(expression,expression,expression,...)...],Chain[...],... } expression := expression | datatype | operation | expression | datatype operation := + | - | * | / | memcpy | contain | ... datatype := u8 | u16 | u16 | ... | container | ... container := hash | map | tree | set | list | array | ...

四.這一切到底怎么了

值得注意的是，雖然nftables在美學(xué)角度上完勝iptables，但是作為一個框架，它的性能并不十分高效。和nf-hipac相 比，iptables并不比nftables輸?shù)酶鼞K些。事實上，nftables和iptables一樣，對于一條chain上的所有rule，也是逐 條遍歷的，所不同的只是遍歷每條rule時執(zhí)行具體匹配的方式有所不同。那么和nf-hipac相比，nftables為何成功了？

其實nftables還遠(yuǎn)遠(yuǎn)沒有成功，它的阻力不是來自性能，而是來自iptables的陣營！nftables作為一個優(yōu)美的框架，考慮的不僅僅是性 能，事實上性能只是其考慮的極小的一方面。作為一個框架，它首先要考慮的是擴(kuò)展性以及和iptables的兼容性。反對的聲音分分鐘響徹于 耳，iptables并沒有錯，match/target配對的方式并沒有錯，match就是要返回true or false，最終的結(jié)果就是要target來執(zhí)行，總之就是要區(qū)分match和target，并且各司其職！！

覺得iptables不能執(zhí)行多個動作的為何不自己寫一個可以執(zhí)行多個動作的target啊啊啊？！

覺得iptables逐條執(zhí)行且不能完成nf-hipac創(chuàng)舉的為何不將nf-hipac封裝成一個單獨的match啊啊啊？！

封裝成單獨match的nf-hipac看起來會是：

iptables -A INPUT -m hipac --match-hipac hipac_test -j NOTHING nf-hipac create hipac_test nf-hipac add hipac_test -s 1.1.1.1 -j DROP ...

看到iptables的優(yōu)勢了吧，人家根本就不是來和nf-hipac拼性能的，人家是海納百川的，人家有容乃大！難道姓毛的椅子男要上戰(zhàn)場拚*** 嗎？NO！NO！NO！姑且不談nf-hipac，和上面類似的還有ipset，ipset不就是被封裝成一個match而和iptables聯(lián)動的 嗎？iptables并不差，錯在人們根本就不該直接將每一個簡單功能擴(kuò)展成一套match/target聯(lián)合體，最終形成令人作嘔的代碼！是這樣嗎？

好吧！我承認(rèn)上面的YY都是對的！但是看看nftables，它是不是也可以這么玩并且玩得更high呢？！是啊！是吧！nftables內(nèi)部直接內(nèi)置了 諸多的容器類數(shù)據(jù)類型，比如rbtree，hash等，作為一種復(fù)合容器，你往里面放東西就是了，還用寫match嗎？我這么說的意思是，寫過 match/target的都知道，要例行多少公事啊，你要注冊match或者target，還要復(fù)制很多管理代碼，看過xtables-addons的 都知道其中之苦。

使用nftables的話，如果你想為iptables擴(kuò)展一個功能模塊，很多工作都可以在用戶態(tài)完成，換句話說，如果僅僅是基于 skb(即數(shù)據(jù)包)的內(nèi)容做過濾，那么nftables便是協(xié)議無關(guān)的，因為不管什么協(xié)議，你都可以將過濾表達(dá)式用 payload，compare，bit等簡單的expression開表示，協(xié)議解析的工作在用戶態(tài)編譯nftables指令的時候完成即可，到了內(nèi)核 態(tài)，nftables虛擬機(jī)只執(zhí)行表達(dá)式，不管協(xié)議！

世界在向前走，我們要向前看！看看Linux的包過濾框架，從最初的移植BSD的實現(xiàn)，到現(xiàn)在的nftables，中間經(jīng)歷了多少的坎坷曲折，每次有新東 西進(jìn)來總是會有復(fù)古者的謾罵！這下可好，這下可好，Linux內(nèi)核在主干上直接內(nèi)置了nftables的支持，正如當(dāng)初Netfilter進(jìn)入主干時的情 形一樣。

Just do it，劃時代的nftables，我并不是說它有多么猛，而是說，它真的很干凈。

tables，chains，這名字叫得真不好，可是無論如何它也只是個名字而已。iptables要不是因為名字，我也不會為了理解它糾結(jié)那么久，現(xiàn)在 又來個nftables...Cisco管類似的東西叫做list，即ACL，也只是個名字，如果說tables不好聽，list是不是顯得更低級呢？不 管低級不低級，華為也延續(xù)了Cisco的叫法。因此下一代的包過濾框架也叫做tables，估計顯示文化上的認(rèn)同要比其實質(zhì)更加有用吧，特別是對待起名字 這件事上。iptables已經(jīng)深入人心，nftables這個名字會讓人更容易接受。當(dāng)初iptables替代ipchains，那是革命性的替換，而 這次，更多的顯示出來的是成熟Linux機(jī)制的一種自然而然的演變，或者說進(jìn)化更合適些吧。

五.nftables用起來

我第一時間想的是在2.6.32上將nftables跑起來，然而失敗了，根本就沒有辦法編譯。那么下面就是想辦法了，看了很多的宣傳文檔和HOWTO以及nftables的主站，花了好久clone了git映像，編譯通過，終于跑起來了。

后來我干脆直接在http://kernel.org上下載3.17版本的內(nèi)核，在make config的時候?qū)ft相關(guān)的東西都給選上，然后編譯更新內(nèi)核。同時下載用戶態(tài)的nftables-0.3版本utils，編譯之，過程中缺什么補什 么，最終很順利。在make install之后，首先執(zhí)行：

nft -f /usr/local/etc/nftables/ipv4-filter

這條命令是在內(nèi)核中載入了filter表，除了執(zhí)行預(yù)先配置好的文件，你也可以手工載入table。

在table，chain就緒之后，就是在自己希望的chain上添加rule了：

nft add rule ip filter output ip daddr 1.2.3.4 drop

其它的用法請man nft，非常詳細(xì)但不詳盡的文檔，另外的好資料在?https://home.regit.org/netfilter-en/nftables-quick-howto以及?https://home.regit.org/2014/01/why-you-will-love-nftables！

我為何沒有將其移植到低版本的內(nèi)核上呢？因為我覺得這太簡單了，為何出此狂言？因為nftables僅僅和Netfilter的 nf_register/unregister_hooks接口，其它的都是其框架內(nèi)部做的，其復(fù)雜性在于nft_expr_ops，而這個是非常獨立 的，和既有的內(nèi)核沒有任何關(guān)系。對于用戶態(tài)utils，本身就有一個nftables項目存在，就是一個編譯問題，而這個編譯是本來就能通過編譯的。

六.配置防火墻變成了編程

本文的最后，我來從全局的角度看一下nftables和iptables的最終區(qū)別。

=我已經(jīng)從內(nèi)部原理的角度分析了nftables帶來的改變，那么這些給用戶到底能帶來多少實惠呢？如果沒有實惠，那么在用戶群中是不會有動力切換到 nftables的。實惠不多，只有一個，但是僅此就夠了，那就是：nftables讓用戶可以按照編程的思想來組織自己的配置邏輯。

=怎么說呢？我們來看一個wiki上展示的例子吧：

nft add rule ip filter input ip protocol vmap { tcp : jump tcp-chain,udp : jump udp-chain , icmp : jump icmp-chain }

這是什么？這是一條“編程語句”，它擁有一個簡單的if-else if-else if邏輯，或者你把它當(dāng)成switch-case也可以。注意，這可是在一條規(guī)則中完成的！如果用iptables的話，你不得不獨立寫多條規(guī)則。以上的語句多么像是：

這是什么？這是一條“編程語句”，它擁有一個簡單的if-else if-else if邏輯，或者你把它當(dāng)成switch-case也可以。注意，這可是在一條規(guī)則中完成的！如果用iptables的話，你不得不獨立寫多條規(guī)則。以上的語句多么像是：

proto = skb->net_hdr->proto; if (proto == tcp) {tcp_chain(skb); } else if (proto == udp) {udp_chain(skb); } else if (proto == icmp) {icmp_chain(skb); }

nftables變成了真正的編程語言！既然成了編程語言，如果支持變量將會是多么靈活的一件事啊，幸運的是，哦，不，不能說幸運，而是nftables原生的性質(zhì)，nftables支持“變量”！注意下面的命令：

nft add set filter blackhole { type ipv4_addr\;} nft add rule ip input ip saddr @blackhole drop nft add element filter blackhole { 192.168.1.4, 192.168.1.5 }

雖然iptables的ipset match也可以這樣做，但是那畢竟只是一個match而已，nftables原生就支持這種語法！甚至，甚至還可以用字典映射策略的語法：

nft add map filter mydict { type ipv4_addr : verdict\; } nft add rule filter input ip saddr vmap @mydict nft add element filter mydict { 192.168.0.10 : drop, 192.168.0.11 : accept }

這樣一來，管理員將會像程序員一樣靈活組織自己的邏輯。

七.一個有點悲觀的事實

去 搜一下ipchain的文檔，幾乎沒有幾個能打開的，然后去搜iptables的，目前人氣還很旺，nftables的呢？能搜到結(jié)果，但是想用起來要費 點勁。這就是前仆后繼的過程，可以設(shè)想將來的某天，nftables也會像ipchain一樣逐漸冷淡，淡出人們的視線...這難道就是Linux環(huán)境包 過濾框架的宿命嗎？

這并不是技術(shù)發(fā)展的必然，老牌的UNIX工具vi，Emacs直到現(xiàn)在依然是黑客們的利器，網(wǎng)絡(luò)工具netcat也是小巧便攜經(jīng)久不衰...而Linux 的包過濾框架短短的15年間更新?lián)Q代了多次。令人感到希望的是Netfilter這個底層的框架基本已經(jīng)穩(wěn)定，不管是iptables還是 nftables，都是基于Netfilter來開發(fā)的，而早期的ipfw則不是，那時的(Linux 2.3.15內(nèi)核之前的)底層包過濾框架及其簡陋，因此Netfilter一出現(xiàn)就上位了。值得注意的是，這里面包含了太多的是開發(fā)者Rusty Russell的個人風(fēng)格，Netfilter是他完成的，ipchains也是他，這不禁讓人想起了破立有秩的Ingo Molnar，引入了O(1)調(diào)度器，然后卻用更好的CFS調(diào)度器替換了它...UNIX則非常不同，個人因素少之又少...

總結(jié)

以上是生活随笔為你收集整理的万字总结Linux内核过滤框架（Nftables）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。