本来上周末想实现一个Cisco风格的Linux版本ACL，也就是说将rule绑定在Interface上而不是HOOK点，然而发现net_device的private data非常不好用，就把半拉子工作仍在那里了...其实即使实现了Cisco风格的ACL，还是基于Netfilter实现的，然而FORWARD上的ruleset就简单多了，变成了下面这个样子：
这样效率的提供就不依赖iptables规则的配置顺序了，如果该接口上没有配置ruleset，则直接就ACCEPT了，将Interface从普通match提升到了一个ruleset宿主的位置。
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 ruleset *rs = (struct ruleset *)get_obj(in->private, IDX_RULESET); if(rs == NULL) return NF_ACCEPT; return rule_XXX(rs, hook, skb, in, out, okfn); }
这样效率的提供就不依赖iptables规则的配置顺序了，如果该接口上没有配置ruleset，则直接就ACCEPT了，将Interface从普通match提升到了一个ruleset宿主的位置。
Cisco以接口的入站和出站方向控制所有流量，而Netfilter则在协议栈的5个位置控制所有流量，接口对于它来讲仅仅是一个match。无论在配置，在理解还是在效率上，Cisco的方式都更胜一筹，这一点上，Cisco真正的将用户配置接口和内部实现相分离了，实际上，Cisco IOS的内部实现估计也是类似Netfiler的那种。Netfilter就很不同，它的实现和iptables用户接口(ipt只是Netfilter的用户接口之一，很多其它机制也是Netfilter实现的，比如ipvs等)基本是一致的，初学者不得不彻底理解这5个HOOK，理解Chain，table等概念才能写出正确高效的规则。ipt的使用者无法集中精力去针对数据包做规则，不得不花费大量时间和精力来摆平ipt的chain，table，顺序之间的关系......
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1268865
