Hi，小伙伴们，小编又来报道啦！在上一期中，小编围绕一张ACL结构图展开介绍，让大家了解了ACL的概念、作用和分类，并且知道了ACL是通过规则匹配来实现报文过滤的。但ACL到底是如何进行规则匹配的，相信大家还是一头雾水。本期，小编就将带领大家深入ACL内部，说一说关于“ACL匹配”的那些事儿。

1 、ACL匹配机制

首先，小编为大家介绍ACL匹配机制。上一期提到，ACL在匹配报文时遵循“一旦命中即停止匹配”的原则。其实，这句话就是对ACL匹配机制的一个高度的概括。当然，ACL匹配过程中，还存在很多细节。比如，ACL不存在系统会怎么处理？ACL存在但规则不存在系统会怎么处理？为了对整个ACL匹配过程展开详细的介绍，小编画了一张ACL匹配流程图，相信对大家理解ACL匹配机制能有所帮助。

从整个ACL匹配流程可以看出，报文与ACL规则匹配后，会产生两种匹配结果：“匹配”和“不匹配”。

l  匹配（命中规则）：指存在ACL，且在ACL中查找到了符合匹配条件的规则。不论匹配的动作是“permit”还是“deny”，都称为“匹配”，而不是只是匹配上permit规则才算“匹配”。

l  不匹配（未命中规则）：指不存在ACL，或ACL中无规则，再或者在ACL中遍历了所有规则都没有找到符合匹配条件的规则。切记以上三种情况，都叫做“不匹配”。

小编提醒大家，无论报文匹配ACL的结果是“不匹配”、“允许”还是“拒绝”，该报文最终是被允许通过还是拒绝通过，实际是由应用ACL的各个业务模块来决定的。不同的业务模块，对命中和未命中规则报文的处理方式也各不相同。例如，在Telnet模块中应用ACL，只要报文命中了permit规则，就允许通过；而在流策略中应用ACL，如果报文命中了permit规则，但流行为动作配置的是deny，该报文会被拒绝通过。在后续连载的《访问控制列表-细说ACL那些事儿（应用篇）》中，小编将结合各类ACL应用，为大家细说各个业务模块的区别。

2 、ACL规则匹配顺序

从上面的ACL匹配报文流程图中，可以看到，只要报文未命中规则且仍剩余规则，系统会一直从剩余规则中选择下一条与报文进行匹配。

系统是根据什么样的顺序来选择规则进行报文匹配的呢？

回答这个问题之前，先来看个例子。假设我们先后执行了以下两条命令进行配置：

rule deny ip destination 1.1.0.0 0.0.255.255   //表示拒绝目的IP地址为1.1.0.0网段的报文通过

rule permit ip destination 1.1.1.0 0.0.0.255   //表示允许目的IP地址为1.1.1.0网段的报文通过，该网段地址范围小于1.1.0.0网段范围

这条permit规则与deny规则是相互矛盾的。对于目的IP=1.1.1.1的报文，如果系统先将deny规则与其匹配，则该报文会被禁止通过。相反，如果系统先将permit规则与其匹配，则该报文会得到允许通过。

因此，对于规则之间存在重复或矛盾的情形，报文的匹配结果与ACL规则匹配顺序是息息相关的。下面，小编就为大家介绍ACL定义的两种规则匹配顺序：配置顺序（config）和自动排序（auto）。

配置顺序，即系统按照ACL规则编号从小到大的顺序进行报文匹配，规则编号越小越容易被匹配。后插入的规则，如果你指定的规则编号更小，那么这条规则可能会被先匹配上。

小编提醒，ACL规则的生效前提，是要在业务模块中应用ACL。当ACL被业务模块引用时，你可以随时修改ACL规则，但规则修改后是否立即生效与具体的业务模块相关。关于ACL的应用，在后续连载的应用篇中，小编还将为大家详细介绍。

自动排序，是指系统使用“深度优先”的原则，将规则按照精确度从高到底进行排序，系统按照精确度从高到低的顺序进行报文匹配。规则中定义的匹配项限制越严格，规则的精确度就越高，即优先级越高，那么该规则的编号就越小，系统越先匹配。例如，有一条规则的目的IP地址匹配项是一台主机地址2.2.2.2/32，而另一条规则的目的IP地址匹配项是一个网段2.2.2.0/24，前一条规则指定的地址范围更小，所以其精确度更高，系统会优先将报文与前一条规则进行匹配。

小编提醒，在自动排序的ACL中配置规则，不允许自行指定规则编号。系统能自动识别出该规则在这条ACL中对应的优先级，并为其分配一个适当的规则编号。

例如，在auto模式的acl 3001中，存在以下两条规则。

如果在acl 3001中插入rule deny ip destination 1.1.1.1 0（目的IP地址是主机地址，优先级高于上图中的两条规则），系统将按照规则的优先级关系，重新为各规则分配编号。插入新规则后，新的排序如下。

可以看到，rule deny ip destination 1.1.1.1 0的优先级最高，排列最靠前。

3、ACL规则匹配项

最后，我们来说说ACL规则最核心的部分：规则匹配项。

在上一期中，小编在介绍ACL分类时，就已经提到各类ACL的规则定义描述。比如，基本ACL可以使用报文的源IP地址作为匹配选项；高级ACL则更高一筹，不仅可以使用源IP地址，还能使用目的IP地址、协议类型、端口号等等。

今天小编为大家讲解几个最常用的匹配选项：协议类型、目的地址和生效时间段。

PS:源地址的使用方法与目的地址同理，小编不再赘述。

协议类型

格式为：protocol-number | icmp | tcp | udp | gre | igmp | ip | ipinip | ospf

高级ACL支持过滤的报文类型很多，常用的协议类型包括： ICMP（协议号1）、TCP（协议号6）、UDP（协议号17）、GRE（协议号47）、IGMP（协议号2）、IP（指任何IP层协议）、IPinIP（协议号4）、OSPF（协议号89）。protocol-number取值可以是1～255。

什么情况下可以使用协议类型作为匹配项？

例如，交换机某个接口下的用户存在大量的攻击者，你希望能够禁止这个接口下的所有用户接入网络。这时，通过指定协议类型为IP来屏蔽这些用户的IP流量，就可以达到目的。配置如下：

rule deny ip //表示拒绝IP报文通过

再如，交换机上打开透明防火墙功能后，在缺省情况下，透明防火墙会在域间丢弃所有入域间的报文，包括业务报文和协议报文。如果你希望像OSPF这样的动态路由协议报文能正常通过防火墙，保证路由互通，这时，通过指定协议类型为OSPF即可解决问题。配置如下：

rule permit ospf  //表示允许OSPF报文通过

目的地址

格式为：destination { destination-address destination-wildcard | any }

?  destination-address：指定报文的目的地址。

?  destination-wildcard：指定通配符掩码。可以为0，相当于0.0.0.0，表示目的地址为主机地址。

?  any：表示对任意目的地址都匹配。

什么情况下可以使用目的地址作为匹配项？

例如，某公司有一台非常重要的服务器，其IP地址为1.1.1.1，现希望对该服务器的访问权限进行限制。这时，你可以通过指定目的地址为匹配选项来解决该问题。配置如下：

rule deny ip destination 1.1.1.1 0  //表示拒绝目的地址是1.1.1.1的报文通过

小编提醒：在将目的地址定义为ACL规则匹配项时，还需要同时指定通配符掩码，用来与目的地址字段共同确定一个地址范围。

通配符掩码的格式与IP地址相同，也是一个32比特位的数字字符串，用于指示目的IP地址中的哪些位将被检查。各比特位中，0表示“检查相应的位”，1表示“不检查相应的位”，

概括为一句话就是“检查0，忽略1”。 如图所示，以8比特为例，通配符的低8位如果为全0，就表示对目的IP地址的低8位全部进行检查；全1就表示全部忽略。有多少位为0，就表示检查多少位；有多少位为1，就表示忽略多少位。

为了进一步加深对通配符掩码的理解，小编特出一道考题来考考大家：

destination-address =172.30.16.0  destination -wildcard = 0.0.15.255 ，表示什么范围的地址？

1.    首先，分析该目的地址和通配符掩码共同确定的地址范围的高两个字节。目的地址高两个字节是“172.30”，通配符掩的高两个字节是“0.0”，按照“检查0”原则，该目的地址和通配符掩码确定的地址的高两个字节必然是“172.30”。

2.    然后，再分析第三个字节。通配符掩码的第三个字节是15，转换为二进制比特是00001111。根据“检查0，忽略1”原则，小编将分析过程画图如下。

3.    由于通配符掩码的高4位是0000、后四位是1111，所以得出该目的地址和通配符掩码确定的地址的第三个字节，是00010000~00011111这样一个地址范围，转化成十进制是16~31。同理，目的地址的最后一个字节是0，通配符掩码的最后一个字节是255（转换成二进制比特是全1），按照“忽略1”原则，该目的地址和通配符掩码确定的地址的第四个字节也是一个地址范围00000000~11111111，转化成十进制是0~255。

基于以上分析，我们得到最终结果是：destination-address =172.30.16.0  destination-wildcard = 0.0.15.255共同确定的地址范围为172.30.16.0/24~172.30.31.0/24，最小的IP地址是172.30.16.0，最大的IP地址是172.30.31.255。小伙伴们，你们答对了吗？

生效时间段 time-range

?  第一种模式——相对时间段：以星期为参数来定义时间范围。

格式为：time-range time-name start-time to end-time { days } &<1-7>

• time-name：时间段名称，以英文字母开头的字符串。  
• start-time to end-time：开始时间和结束时间。格式为[小时:分钟] to [小时:分钟]。  
• days：有多种表达方式：  
• Mon、Tue、Wed、Thu、Fri、Sat、Sun中的一个或者几个的组合，也可以用数字表达，0表示星期日，1表示星期一，……6表示星期六。    
• working-day：从星期一到星期五，五天。    
• daily：包括一周七天。    
• off-day：包括星期六和星期日，两天。    

?  第二种模式——绝对时间段：从某年某月某日的某一时间开始，到某年某月某日的某一时间结束。

格式为：time-range time-name from time1 date1 [ to time2 date2 ]

• time：格式为 [小时:分钟]。  
• date：格式为[YYYY/MM/DD],表示年/月/日。  

什么情况下可以使用生效时间段作为匹配项？

例如，每天20:00～22:00为网络流量的高峰期，大量P2P、下载类业务的使用影响了其他数据业务的正常使用，此时通过设置在这个时间段内降低P2P、下载类业务的带宽，可以防止网络拥塞。配置如下：

time-range time1 20:00 to 22:00 daily

再举一例，某公司对外开放服务器的访问权限，但开放时间限制为：从2014年1月1日零点开始生效，到2014年12月31日晚上23:59截止。此时通过设置在这个时间段内访问服务器的报文才允许通过，就可以达到基于时间的访问权限控制的效果。配置如下：

time-range time2 from 00:00 2014/1/1 to 23:59 2014/12/31

最后，小遍提醒大家，配置完时间段，千万别忘记要将时间段与ACL规则关联起来，这样才是一条基于时间的ACL的完整配置过程。配置如下：

acl acl-number

rule [ rule-id ] { deny | permit } other-options time-range time-name

好啦，说完ACL规则的匹配项，本文也要接近尾声了。回顾全文，小编围绕ACL匹配机制、ACL匹配顺序和ACL匹配项展开了介绍，让大家了解了ACL匹配报文的整个流程，知道了ACL存在哪些匹配结果、ACL按照什么样的顺序进行规则匹配，并且掌握了最常用的ACL规则匹配项的使用方法。现在大家对ACL的认识，是不是又进一步加深了呢？

在下一期连载系列中，小编将为大家带来ACL的应用篇，让大家了解ACL可以应用的范围，并将带领大家一起动手配置真实的ACL应用案例。敬请期待哟！

想要了解更多精彩内容，请猛戳我：交换机在江湖汇总贴

推荐ACL系列技术贴：