是不是要重新設計Netfilter的HOOK點位置了？無疑這是一個沒有意義的問題，因為你無法證明新的方案更好，你可能只是看上了另一個平台的方案而已，而這個方案和Netfilter的方案是不同的。事實上，我就是這樣一個人。
Cisco的ACL可以被編譯在端口上，事實上Cisco設備的網絡端口角色是可以被定義的，Linux的理念和此完全不同，Linux內核認為定義角色這種事是用戶態的職責，如何要實現一個具有完備性的，不依賴用戶態配置的數據包攔截機制，那就必須在協議棧路徑上進行攔截。換句話說，Netfilter是完全基於skb本身來攔截並處理數據包的，這一點可以從NF_HOOK宏的參數看得出來，但是你可以看到，它還有兩個net_device參數，基於這一點，我們就可以模仿Cisco設備的方式將規則綁定到設備了，這麼做是有好處的，可以大大提高效率。比如如果你配置了10000條規則，如果有不相關網口設備進來的數據包，那麼這些數據包就不必經過iptables規則的過濾。
需要修改的地方比較少，這裡只給出ipt_hook的修改：
static unsigned int
ipt_hook(unsigned int hook,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
struct netns_table_per_dev {
struct list_head list;
struct net_device *dev;
struct xt_table *table;
};
// dev_net(in)->ipv4.iptable_filter不再是一個xt_table，而是一個list
struct wrap_table {
struct list_head *tb_list;
};
struct xt_table *table;
struct netns_table_per_dev *table_dev;
struct list_head *pos;
struct wrap_table *tb_list = (struct wrap_table *)dev_net(in)->ipv4.iptable_filter;
list_for_each(pos, tb_list->tb_list) {
table_dev = list_entry(pos, struct netns_table_per_dev, dev);
if (table_dev->dev == in) {
table = table_dev->table;
}
}
if (table == NULL) {
return NF_ACCEPT;
}
return ipt_do_table(skb, hook, in, out, table);
}
一個在協議棧攔截，一個在設備攔截，該手術做的有點大，顛覆了既有的理念，不知道會不會有後遺症。
不管怎樣，不能走火入魔。
