iptables match順序問題

wendaozhe

能靠前就靠前，需建鏈就建鏈。
其他不敢亂說。

platinum

和 module 前后順序有關(guān)
iptables 匹配時會根據(jù) modules 的鏈表逐一使用模塊匹配
如果 m1 m2 m3 所耗 CPU 不同，建議把最耗 CPU 的放在最后面，把最可能過濾掉數(shù)據(jù)的放在最前面

例如有 3 個模塊，time、layer7、tos
需要把 BT 協(xié)議，在周日使用時、TOS 值是 128 的數(shù)據(jù)包阻斷（僅是一個例子，未必有實用價值）
那么合理的順序是 -m tos -m time -m layer7

因為 tos 檢測最簡單，time 可以濾掉 1/7 的數(shù)據(jù)（因為一周內(nèi)只有一個“周日”），最后都符合的采取檢查是否是 BT 協(xié)議

zhoutao0712

原帖由 wendaozhe 于 2010-1-19 09:26 發(fā)表
能靠前就靠前，需建鏈就建鏈。

受教了。

找到一個 源自<<Linux Firewalls, Third Edition>>有關(guān)于iptables優(yōu)化的建議：



http://blog.chinaunix.net/u1/47765/showart_374120.html

zhoutao0712

這樣理解：

把最簡單，最容易分辨數(shù)據(jù)包是否匹配的match  放在一條規(guī)則的前面。

而把使用最頻繁的 而且 -j ACCEPT或DROP的規(guī)則放在 一個 鏈的前面。

建立自定義鏈 使得一個數(shù)據(jù)包“遍歷”整個iptables的規(guī)則數(shù)最少。

ok_lin

原帖由 platinum 于 2010-1-19 10:42 發(fā)表
和 module 前后順序有關(guān)
iptables 匹配時會根據(jù) modules 的鏈表逐一使用模塊匹配
如果 m1 m2 m3 所耗 CPU 不同，建議把最耗 CPU 的放在最后面，把最可能過濾掉數(shù)據(jù)的放在最前面

例如有 3 個模塊，time、la ...

iptables 匹配時會根據(jù) modules 的鏈表逐一使用模塊匹配,應該是沒有錯的，但不一定是m1 m2 m3， 因為m2可能在m1之前先加載了，那么匹配時的順序應該是
m2 m1 m3。
另外我在2.4內(nèi)核，iptables-1.2.*中測試，具體的匹配順序跟iptables中一個叫initext.c的文件相關(guān)。各位大俠能幫我說明一下嗎。（我的iptables在編譯時不生成共享庫）

后查找發(fā)現(xiàn)：
...
#ifdef NO_SHARED_LIBS
        init_extensions();
#endif
以上代碼為沒有定義共享庫的話，要執(zhí)行init_extensions()。這里我們假設不使用共享庫，所以調(diào)用該函數(shù)。該函數(shù)實在執(zhí)行make的時候extensions/自動生成的initext.c中的函數(shù)。在該函數(shù)里調(diào)用了所有擴展模塊的init函數(shù)。
注冊所有的match，以及標準和擴展的target。
所有的match和target都加入到iptables.c中對應的全局鏈表之中。以后find_match和find_target是就是搜索的這兩個鏈表。
/* Keeping track of external matches and targets: linked lists.  */
struct iptables_match *iptables_matches = NULL;
struct iptables_target *iptables_targets = NULL;
這樣在不使用共享庫的情況下，每次下命令之前都要初始化一下全局的鏈表，當然已經(jīng)存在的話，就不會再次register的。
....

[ 本帖最后由 ok_lin 于 2010-1-20 11:21 編輯 ]

platinum

原帖由 ok_lin 于 2010-1-20 10:36 發(fā)表
iptables 匹配時會根據(jù) modules 的鏈表逐一使用模塊匹配,應該是沒有錯的，但不一定是m1 m2 m3， 因為m2可能在m1之前先加載了

不知道你這里指的 “加載” 是什么意思？

ok_lin

原帖由 platinum 于 2010-1-20 11:21 發(fā)表

不知道你這里指的 “加載” 是什么意思？

insmod  m2  

先insmod m2

后寫規(guī)則，那m1在系統(tǒng)中鏈表的位置在m2后，那先進行的是m2匹配，再進行m1.

platinum

和這個沒有關(guān)系吧，iptables 是靠 match 鏈表工作的，這和 insmod 哪個先哪個后也有關(guān)？
你的意思是如果系統(tǒng)啟動后 insmod m1 m2 m3 的順序，策略使用 m3 m2 m1 的順序，結(jié)果是按照加載的順序來的？

如果可能，你可以做一個實驗，自己寫 m1 m2 m3 三個匹配模塊，分別在處理時設置 skb->mark 為固定數(shù)值，看之后 mark 到底是多少

[ 本帖最后由 platinum 于 2010-1-20 11:40 編輯 ]

ok_lin

原帖由 platinum 于 2010-1-20 11:39 發(fā)表
和這個沒有關(guān)系吧，iptables 是靠 match 鏈表工作的，這和 insmod 哪個先哪個后也有關(guān)？
你的意思是如果系統(tǒng)啟動后 insmod m1 m2 m3 的順序，策略使用 m3 m2 m1 的順序，結(jié)果是按照加載的順序來的？

如果可 ...

系統(tǒng)啟動后 insmod m1 m2 m3
策略使用 m3 m2 m1 的順序測試

發(fā)現(xiàn)既不是按照m1 m2 m3  也不是按照m3 m2 m1

是按照當你輸入iptables -vnL查看時打印出來的順序來匹配的。

我后來研究發(fā)現(xiàn)，iptables打印出來的順序是文件iptables/extensions/initext.c中的順序一樣。

initext.c文件內(nèi)容如下：

extern void ipt_ah_init(void);
extern void ipt_connlimit_init(void);
。。。
extern void ipt_string_init(void);

void init_extensions(void) {
        ipt_ah_init();
        ipt_connlimit_init();
        。。。
        ipt_string_init();
}

搞得我莫名其妙啊。
說明一下我的iptables是不生成動態(tài)庫的啊。

ok_lin

我做了類似的實驗，結(jié)果和我說的一樣啊。 版主說的按match鏈表順序匹配應該沒錯，但這個鏈表好像不是按照策略使用 m3 m2 m1 的順序來的。