所属分类：IPtables Linux基础
不知不觉，已经总结了13篇IPTABLES文章，这些文章中有一些需要注意的地方。
此处，我们对前文中的一些注意点进行总结，我们可以理解为对"常用套路"的总结。
记住这些套路，能让我们事半功倍。
阅读这篇文章之前，请确定你已经阅读了之前的文章，否则你有可能会不理解为什么要这样做。
1、规则的顺序非常重要。
如果报文已经被前面的规则匹配到，IPTABLES则会对报文执行对应的动作，通常是ACCEPT或者REJECT，报文被放行或拒绝以后，即使后面的规则也能匹配到刚才放行或拒绝的报文，也没有机会再对报文执行相应的动作了（前面规则的动作为LOG时除外），所以，针对相同服务的规则，更严格的规则应该放在前面。
2、当规则中有多个匹配条件时，条件之间默认存在"与"的关系。
如果一条规则中包含了多个匹配条件，那么报文必须同时满足这个规则中的所有匹配条件，报文才能被这条规则匹配到。
3、在不考虑1的情况下，应该将更容易被匹配到的规则放置在前面。
比如，你写了两条规则，一条针对sshd服务，一条针对web服务。
假设，一天之内，有20000个请求访问web服务，有200个请求访问sshd服务，
那么，应该将针对web服务的规则放在前面，针对sshd的规则放在后面，因为访问web服务的请求频率更高。
如果将sshd的规则放在前面，当报文是访问web服务时，sshd的规则也要白白的验证一遍，由于访问web服务的频率更高，白白耗费的资源就更多。
如果web服务的规则放在前面，由于访问web服务的频率更高，所以无用功会比较少。
换句话说就是，在没有顺序要求的情况下，不同类别的规则，被匹配次数多的、匹配频率高的规则应该放在前面。
4、当IPTABLES所在主机作为网络防火 墙时，在配置规则时，应着重考虑方向性，双向都要考虑，从外到内，从内到外。
5、在配置IPTABLES白名单时，往往会将链的默认策略设置为ACCEPT，通过在链的最后设置REJECT规则实现白名单机制，而不是将链的默认策略设置为DROP，如果将链的默认策略设置为DROP，当链中的规则被清空时，管理员的请求也将会被DROP掉。
好了，套路就总结到这里，希望能够对你有所帮助。