ACL 详解(不错的文档)

A 公司的某位可怜的网管目前就面临了一堆这样的问题。 A 公司建设了一个企业网，并通过一台路由器接入到互联网。在网络核心使用一台基于 IOS 的多层交换机，所有的二层交换机也为可管理的基于 IOS 的交换机，在公司内部使用了 VLAN 技术，按照功能的不同分为了 6 个 VLAN 。分别是网络设备与网管 (VLAN1 ， 10.1.1 .0/24) 、内部服务器 (VLAN2) 、 Internet 连接 (VLAN3) 、财务部（ VLAN4 ）、市场部 (VLAN5) 、研发部门（ VLAN6 ），出口路由器上 Fa0/0 接公司内部网，通过 s0/0 连接到 Internet 。每个网段的三层设备（也就是客户机上的缺省网关）地址都从高位向下分配，所有的其它节点地址均从低位向上分配。该网络的拓朴如下图所示：　　  

　　自从网络建成后麻烦就一直没断过，一会儿有人试图登录网络设备要捣乱；一会儿领导又在抱怨说互联网开通后，员工成天就知道泡网；一会儿财务的人又说研发部门的员工看了不该看的数据。这些抱怨都找这位可怜的网管，搞得他头都大了。那有什么办法能够解决这些问题呢？答案就是使用网络层的访问限制控制技术 �D�D 访问控制列表（下文简称 ACL ）。

　　那么，什么是 ACL 呢？ ACL 是种什么样的技术，它能做什么，又存在一些什么样的局限性呢？

　　 ACL 的基本原理、功能与局限性

　　网络中常说的 ACL 是 Cisco IOS 所提供的一种访问控制技术，初期仅在路由器上支持，近些年来已经扩展到三层交换机，部分最新的二层交换机如 2950 之类也开始提供 ACL 的支持。只不过支持的特性不是那么完善而已。在其它厂商的路由器或多层交换机上也提供类似的技术，不过名称和配置方式都可能有细微的差别。本文所有的配置实例均基于 Cisco IOS 的 ACL 进行编写。

　　基本原理： ACL 使用包过滤技术，在路由器上读取第三层及第四层包头中的信息如源地址、目的地址、源端口、目的端口等，根据预先定义好的规则对包进行过滤，从而达到访问控制的目的。

　　功能：网络中的节点资源节点和用户节点两大类，其中资源节点提供服务或数据，用户节点访问资源节点所提供的服务与数据。 ACL 的主要功能就是一方面保护资源节点，阻止非法用户对资源节点的访问，另一方面限制特定的用户节点所能具备的访问权限。

　　配置 ACL 的基本原则： 在实施 ACL 的过程中，应当遵循如下两个基本原则：

　　 最小特权原则：只给受控对象完成任务所必须的最小的权限

　　 最靠近受控对象原则：所有的网络层访问权限控制

　　局限性：由于 ACL 是使用包过滤技术来实现的，过滤的依据又仅仅只是第三层和第四层包头中的部分信息，这种技术具有一些固有的局限性，如无法识别到具体的人，无法识别到应用内部的权限级别等。因此，要达到 end to end 的权限控制目的，需要和系统级及应用级的访问权限控制结合使用。

　　 ACL 基本配置

　　 ACL 配置技术详解

　　 “ 说那么多废话做什么，赶快开始进行配置吧。 ” ， A 公司的网管说。呵呵，并不是我想说那么多废话，因为理解这些基础的概念与简单的原理对后续的配置和排错都是相当有用的。说说看，你的第一个需求是什么。

　　 “ 做为一个网管，我不期望普通用户能 telnet 到网络设备 ”�D�DACL 基础

　　 “ 补充一点，要求能够从我现在的机器 ( 研发 VLAN 的 10.1.6 .66) 上 telnet 到网络设备上去。 ” 。 hamm ，是个不错的主意，谁都不希望有人在自己的花园中撤野。让我们分析一下，在 A 公司的网络中，除出口路由器外，其它所有的网络设备段的是放在 Vlan1 中，那个我只需要在到 VLAN 1 的路由器接口上配置只允许源地址为 10.1.6.66 的包通过，其它的包通通过滤掉。这中只管源 IP 地址的 ACL 就叫做

　　标准 IP ACL ：

　　我们在 SWA 上进行如下的配置：

　　 access-list 1 permit host 10.1.6.66

　　 access-list 1 deny any

　　 int vlan 1

　　 ip access-group 1 out

　　这几条命令中的相应关键字的意义如下：

　　 access-list ： 配置均 ACL 的关键字，所有的 ACL 均使用这个命令进行配置。

　　 access-list 后面的 1 ： ACL 号， ACL 号相同的所有 ACL 形成一个组。在判断一个包时，使用同一组中的条目从上到下逐一进行判断，一遇到满足的条目就终止对该包的判断。 1-99 为标准的 IP ACL 号，标准 IP ACL 由于只读取 IP 包头的源地址部分，消耗资源少。

　　 permit/deny ： 操作。 Permit 是允许通过， deny 是丢弃包。

　　 host 10.1.6.66/any ： 匹配条件，等同于 10.1.6.66 0.0.0.0 。刚才说过，标准的 ACL 只限制源地址。 Host 10.1.6.66(10.1.6.66 0.0.0.0) 的意思是只匹配源地址为 10.1.6.66 的包。 0.0.0.0 是 wildcards ，某位的 wildcards 为 0 表示 IP 地址的对应位必须符合，为 1 表示 IP 地址的对应位不管是什么都行。简单点说，就是 255.255.255.255 减去子网掩码后的值， 0.0.0.0 的 wildcards 就是意味着 IP 地址必须符合 10.1.6.66 ，可以简称为 host 10.1.6.66 。 any 表示匹配所有地址。

　　注意： IOS 中的 ACL 均使用 wildcards ，并且会用 wildcards 对 IP 地址进行严格的对齐，如你输入一条 access-list 1 permit 10.1.1.129 0.0.0.31 ，在你 show access-list 看时，会变成 access-list 1 permit 10.1.1.128 0.0.0.31 ， PIXOS 中的 ACL 均使用 subnet masks ，并且不会进行对齐操作。

　　 int vlan1///ip access-group 1 out ： 这两句将 access-list 1 应用到 vlan1 接口的 out 方向。其中 1 是 ACL 号，和相应的 ACL 进行关联。 Out 是对路由器该接口上哪个方向的包进行过滤，可以有 in 和 out 两种选择。

　　注意：这里的 in/out 都是站在路由器或三层模块（以后简称 R ）上看的， in 表示从该接口进入 R 的包， out 表示从该接口出去的包。

　　好了，这就是一个最基本的 ACL 的配置方法。什么，你说普通用户还能 telnet 到 RTA ？那你在 int vlan3 上现加一个 ip access-group 1 out 吧。 Hammmm ，等等，你这样加上去普通用户就访问不了 internet 了。让我们把刚才的 ACL 去掉，重新写一个。

　　回忆一下，我们的目的是除了 10.1.6.66 能够进行 telnet 操作外，其它用户都不允许进行 telnet 操作。刚才我们说过，标准的 IP ACL 只能控制源 IP 地址，不能控制到端口。要控制到第四层的端口，就需要使用到：

　　扩展的 IP ACL 的配置

　　先看看配置实例吧。在 SWA 上进行如下配置：

　　 int vlan 1

　　 no ip access-group 1 out

　　 exit

　　 no access-list 1

　　 access-list 101 permit tcp host 10.1.6.66 any eq telnet

　　 access-list 101 deny tcp any any eq telnet

　　 int vlan 1

　　 ip access-group 101 out

　　 int vlan 3

　　 ip access-group 101 out

　　你应该注意到到这里的 ACL 有一些变化了，现在对变化的部分做一些说明：

　　 access-list 101 ： 注意这里的 101 ，和刚才的标准 ACL 中的 1 一样， 101 是 ACL 号，表示这是一个扩展的 IP ACL 。扩展的 IP ACL 号范围是 100-199 ，扩展的 IP ACL 可以控制源 IP 、目的 IP 、源端口、目的端口等，能实现相当精细的控制，扩展 ACL 不仅读取 IP 包头的源地址 / 目的地址，还要读取第四层包头中的源端口和目的端口，的 IP 在没有硬件 ACL 加速情况下，会消耗大量的 CPU 资源。

　　 int vlan 1///no ip access-group 1 out///exit///no access-list 1 ： 取消 access-list 1 ，对于非命名的 ACL ，可以只需要这一句就可以全部取消。注意，在取消或修改一个 ACL 前，必须先在它所应用的接口上先把应用给 no 掉，否则会导致相当严重的后果。

　　 tcp host 10.1.6.66 any eq telnet ：匹配条件。完整格式为：协议 源地址 源 wildcards [ 关系 ] [ 源端口 ] 目的地址 目的 wildcards [ 关系 ] [ 目的端口 ] 。 其中协议可以是 IP 、 TCP 、 UDP 、 EIGRP 等， [] 内为可选字段。仅在协议为 tcp/udp 等具备端口号的协议才有用。关系可以是 eq( 等于 ) 、 neq （不等于）、 lt( 大于 ) 、 range （范围）等。端口一般为数字的 1-65535 ，对于周知端口，如 23( 服务名为 telnet) 等可以用服务名代替。源端口和目的端口不定义时表示所有端口。

　　把这个 ACL 应用上去后，用户们开始打电话来骂娘了，因为他们都访问不了 Internet 了，是哪里出了问题了呢？

　　注意：所有的 ACL ，缺省情况下，从安全角度考虑，最后都会隐含一句 deny any( 标准 ACL) 或 deny ip any any （扩展 IP ACL ）。所以在不了解业务会使用到哪些端口的情况下，最好在 ACL 的最后加上一句 permit ip any any ，在这里就是 access-list 101 permit ip any any 。

　　现在用户倒是能够访问 Internet 了，但我们的可怜的网管却发现普通用户还是能够 telnet 到他的 SWA 上面，因为 SWA 上面有很多个网络接口，而且使用扩展的 ACL 会消耗很多的资源。有什么简单的办法能够控制用户对网络设备的 Telnet 访问，而又不消耗太多的资源呢？这就需要使用到：

　　对网络设备自身的访问如何进行控制的技术

　　让我们先把刚才配置的 ACL 都取掉 ( 具体配置略，不然后读者会以为我在骗稿费了。 ) ，再在每台网络设备上均进行如下配置：

　　 access-list 1 permit host 10.1.6.66

　　 line vty 0 4( 部分设备是 15)

　　 access-class 1 in

　　这样就行了， telnet 都是访问的设备上的 line vty ，在 line vty 下面使用 access-class 与 ACL 组进行关联， in 关键字表示控制进入的连接。

　　就这么简单？ wk ，你丫是不是在玩我们，为什么还要绕一大圈？臭鸡蛋和烂西红柿开始在 70 的脑袋上方狂飞。 (5555555 ，偶也只是想向大家把 ACL 的基础知识讲的明白一些的嘛 ) 。经过刚才的配置，我们可以理出一个简单的 ACL 配置步骤了：

　　 分析需求，找清楚需求中要保护什么或控制什么；为方便配置，最好能以表格形式列出。在本文的后面会举例的。

　　 分析符合条件的数据流的路径，寻找一个最适合进行控制的位置；

　　 书写 ACL ，并将 ACL 应用到接口上；

　　 测试并修改 ACL 。

　　当 A 公司的领导知道在网管能够控制普通用户对网络设备的访问后，我们的可怜的网管就收到了很多看起来很难的要求。领导要求网管：

　　 ACL 执行顺序

　　 “ 使用 ACL 技术对网络访问进行精细化控制 ”�D�DACL 进阶配置

　　命名的 IP ACL

　　由于最近服务器网段的机器老是被人用 telnet 、 rsh 等手段进行攻击，我们只对员工开放 web 服务器 (10.1.2.20) 所提供的 http 、 FTP 服务器 (10.1.2.22) 提供的 FTP 服务和数据库服务器 (10.1.2.21 ： 1521) 。好吧，我们着手进行配置，可是我们的 ACL 刚写到一半，发现前面写的几句好像有问题，一个 no 命令输进去，整个 ACL 都没了，唉，一切都得重来，难道就没有一个变通的办法么？有，这里我就需要用到：

　　命名的 IP acl 提供的两个主要优点是：

　　 l 解决 ACL 号码不足的问题。

　　 l 可以自由的删除 ACL 中的一条语句，而不必删除整个 ACL 。

　　命名的 ACL 的主要不足之处在于无法实现在任意位置加入新的 ACL 条目。比如上面那个例子中，我们进行了如下的配置：

　　 ip access-list extend server-protect

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.20 eq www

　　 permit tc p 10.0.0 .0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.22 eq ftp

　　配置到这里，我们发现 permit tc p 10.0.0 .0 0.0.255.255 host 10.1.2.21 eq 1521 这句配错了，我们得把它给取掉并重新配置， OK ，我样可以简单的进行如下配置：

　　 ip access-list extend server- protect

　　 no permit tc p 10.0.0 .0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tc p 10.1.0 .0 0.0.0.255 host 10.1.2.21 eq 1521

　　 exit

　　 int vlan 2

　　 ip access-group server- protect

　　就可以了。现在对命名的 IP access-list 的配置方法解释如下：

　　 ip access-list extend server-access-limit ： ip access-list 相当于使用编号的 access-list 中的 access-list 段。 extend 表明是扩展的 ACL( 对应地， standard 表示标准的 ACL) 。 server-access-limit 是 access-list 的名字，相当于基于编号的 ACL 中的编号字段。

　　 permit tc p 10.1.6 .0 0.0.0.255 host 10.1.2.21 eq 1521 ： 这一段和使用编号的 access-list 的后半段的意义相同，都由操作和条件两段组成。

　　其实基于名字的 IP ACL 还有一个很好的优点就是可以为每个 ACL 取一个有意义的名字，便于日后的管理与维护。所以 Ultra 工作室强烈建议各位看官在实际工作中均使用命名的 ACL 。

　　进一步完善对服务器数据的保护 �D�DACL 执行顺序再探讨

　　在服务器网段中的数据库服务器中存放有大量的市场信息，市场部门的人员不希望研发部门访问到数据库服务器，经过协商，同意研发部门的领导的机器（ IP 地址为 10.1.6.33 ）可以访问到数据库服务器。这样，我们的服务器网段的的访问权限部分如下表所示：

协议	源地址	源端口	目的地址	目的端口	操作
TCP	10.1/16	所有	10.1.2 .20/32	80	允许访问
TCP	10.1/16	所有	10.1.2 .22/32	21	允许访问
TCP	10.1/16	所有	10.1.2 .21/32	1521	允许访问
TCP	10.1.6 /24	所有	10.1.2 .21/32	1521	禁止访问
TCP	10.1.6 .33/32	所有	10.1.2 .21/32	1521	允许访问
IP	10.1/16	N/A	所有	N/A	禁止访问

　　于是，网管就在 server-protect 后面顺序加了两条语句进去，整个 ACL 变成了如下形式：
ip access-list extend server-protect

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.20 eq www

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.22 eq ftp

　　 deny tc p 10.1.6 .0 0.0.0.255 host 10.1.2.21 eq 1521

　　 permit tcp host 10.1.6.33 host 10.1.2.21 eq 1521

　　做完之后发现根本没起到应有的作用，研发部门的所有机器还是可以访问到数据库服务器。这是为什么呢？

　　前面我们提到过， ACL 的执行顺序是从上往下执行，一个包只要遇到一条匹配的 ACL 语句后就会停止后续语句的执行， 在我们的这个 ACL 中，因为前面已经有了一条 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.21 eq 1521 语句。 内部网上所有访问 10.1.2.21 的 1521 端口的在这儿就全部通过了，跟本不会到后面两句去比较。所以导致达不到我们的目的。应该把 server-protect 这个 ACL 按如下形式进行修改才能满足我们的要求：

　　 ip access-list extend server-protect

　　 permit tcp host 10.1.6.33 host 10.1.2.21 eq 1521

　　 deny tc p 10.1.6 .0 0.0.0.255 host 10.1.2.21 eq 1521

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.21 eq 1521

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.20 eq www

　　 permit tc p 10.1.0 .0 0.0.255.255 host 10.1.2.22 eq ftp

　　这个例子告诉我们在写 ACL 时，一定要遵循最为精确匹配的 ACL 语句一定要写在最前面的原则 ，只有这样才能保证不会出现无用的 ACL 语句。

　　基于时间的 ACL

　　在保证了服务器的数据安全性后，领导又准备对内部员工上网进行控制。要求在上班时间内 (9:00-18:00) 禁止内部员工浏览 internet ，禁止使用 QQ 、 MSN 。而且在 2003 年 6 月 1 号到 2 号的所有时间内都不允许进行上述操作。但在任何时间都可以允许以其它方式访问 Internet 。天哪，这可叫人怎么活呀，但领导既然这样安排，也只好按指示做了。

　　首先，让我们来分析一下这个需求，浏览 internet 现在基本上都是使用 http 或 https 进行访问，标准端口是 TCP/80 端口和 TCP/443 ， MSN 使用 TCP/1863 端口， QQ 登录会使用到 TCP/UDP8000 这两个端口，还有可能使用到 udp/4000 进行通讯。而且这些软件都能支持代理服务器，目前的代理服务器主要布署在 TCP 8080 、 TCP 3128 （ HTTP 代理）和 TCP1080(socks) 这三个端口上。这个需求如下表所示：

应用	协议	源地址	源端口	目的地址	目的端口	操作
IE	TCP	10.1/16	所有	所有	80	限制访问
IE	TCP	10.1/16	所有	所有	443	限制访问
MSN	TCP	10.1/16	所有	所有	1863	限制访问
QQ	TCP	10.1/16	所有	所有	8000	限制访问
QQ	UDP	10.1/16	所有	所有	8000	限制访问
QQ	UDP	10.1/16	所有	所有	4000	限制访问
HTTP 代理	TCP	10.1/16	所有	所有	8080	限制访问
HTTP 代理	TCP	10.1/16	所有	所有	3128	限制访问
Socks	TCP	10.1/16	所有	所有	1080	限制访问
All other	IP	10.1/16	N/A	所有	N/A	允许访问

　　然后，让我们看看 ACL 应该在哪个位置配置比较好呢？由于是对访问 Internet 进行控制，涉及到的是公司内部所有的网段，这们这次把 ACL 就放到公司的 Internet 出口处。在 RTA 上进行如下的配置，就能够满足领导的要求了：

　　 time-range TR1

　　 absolute start 00:00 1 June 2003 end 00:00 3 June 2003

　　 periodic weekdays start 9:00 18:00

　　 exit

　　 ip access-list extend internet_limit

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 80 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 443 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 1863 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 8000 time-range TR1

　　 deny ud p 10.1.0 .0 0.0.255.255 any eq 8000 time-range TR1

　　 deny ud p 10.1.0 .0 0.0.255.255 any eq 4000 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 3128 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 8080 time-range TR1

　　 deny tc p 10.1.0 .0 0.0.255.255 any eq 1080 time-range TR1

　　 permit ip any any

　　 int s0/0

　　 ip access-group internet_limit out

　　或 int fa0/0

　　 ip access-group internet_limit in

　　或者将 ACL 配置在 SWA 上，并

　　 int vlan 3

　　 ip access-group internet_limit out

　　呵呵，现在让我们来看看在基于时间的访问列表中都有哪些新内容吧：

　　 time-range TR1 ： 定义一个新的时间范围，其中的 TR1 是为该时间范围取的一个名字。

　　 absolute ：为绝对时间。只使用一次。可以定义为 1993-2035 年内的任意一个时点。具体的用法请使用？命令查看。

　　 Periodic ：为周期性重复使用的时间范围的定义。完整格式为 periodic 日期关键字 开始时间 结束时间。 其中日期关键字的定义如下所示：

　　 Monday 星期一

　　 Tuesday 星期二

　　 Wednesday 星期三

　　 Thursday 星期四

　　 Friday 星期五

　　 Saturday 星期六

　　 Sunday 星期天

　　 daily 每天

　　 weekdays 周一至五

　　 weekend 周末

　　 access-list 101 deny i p 10.1.0 .0 0.0.255.255 any time-range TR1: 注意这一句最后的 time-range TR1 ，使这条 ACL 语句与 time-range TR1 相关联，表明这条语句在 time-range TR1 所定义的时间范围内才起作用。

　　注意：给出三种配置位置是帮助大家深刻理解关于 in/out 的区别的。 acl 是对从一个接上流入 (in) 或流出 (out) 路由器的包进行过滤的。

　　网管发问了， “ 你是怎么找到这些应用的所使用的端口的？ ” 。呵呵，在如下文件中可以找到大多数应用的端口的定义：

　　 Win9x:%windir%\services

　　 WinNT/2000/XP ： %windir%\system32\drivers\etc\services

　　 Linux ： /etc/services

　　对于在 services 文件中找不到端口的应用，可以在运行程序的前后，运行 netstat �Cap 来找出应用所使用的端口号。

　　单向访问控制

　　使用 IP ACL 实现单向访问控制

　　 A 公司准备实行薪资的不透明化管理，由于目前的薪资收入数据还放在财务部门的 Vlan 中，所以公司不希望市场和研发部门能访问到财务部 Vlan 中的数据，另一方面，财务部门做为公司的核心管理部门，又希望能访问到市场和研发部门 Vlan 内的数据。我们的网管在接到这个需求后就在 SWA 上做了如下的配置：

　　 ip access-list extend fi-access-limit

　　 deny ip any 10.1.4.0 0.0.0.255

　　 permit ip any any

　　 int vlan 5

　　 ip access-group fi-access-limit in

　　 int vlan 6

　　 ip access-group fi-access-limit in

　　配置做完后，测试了一下，市场和研发部门确实访问不到财务部了，刚准备休息一下，财务部打电话过来说为访问不到市场与研发部门的数据了。这是怎么回事呢？

　　让我们回忆一下，在两台主机 A 与 B 之间要实现通讯，需要些什么条件呢？答案是既需要 A 能向 B 发包，也需要 B 能向 A 发包，任何一个方向的包被阻断，通讯都不能成功，在我们的例子中就存在这样的问题，财务部访问市场或研发部门时，包到到市场或研发部门的主机，由这些主机返回的包在到达路由器 SWA 时，由于普通的 ACL 均不具备检测会话状态的能力 ，就被 deny ip any 10.1.4.0 0.0.0.255 这条 ACL 给阻断了，所以访问不能成功。

　　要想实现真正意义上的单向访问控制应该怎么办呢？我们希望在财务部门访问市场和研发部门时，能在市场和研发部门的 ACL 中临时生成一个反向的 ACL 条目，这样就能实现单向访问了。这里就需要使用到反向 ACL 技术。我们可以按照如下配置实例就可以满足刚才的那个单向访问需求：

　　 ip access-list extend fi-main

　　 permit tcp any 10.1.0.0 0.0.255.255 reflect r-main timeout 120

　　 permit udp any 10.1.0.0 0.0.255.255 reflect r-main timeout 200

　　 permit icmp any 10.1.0.0 0.0.255.255 reflect r-main timeout 10

　　 permit ip any any

　　 int vlan 4

　　 ip access-group fi-main in

　　 ip access-list extend fi-access-limit

　　 evaluate r-main

　　 deny ip any 10.1.4.0 0.0.0.255

　　 permit ip any any

　　 int vlan 5

　　 ip access-group fi-access-limit in

　　 int vlan 6

　　 ip access-group fi-access-limit in

　　现在对反向 ACL 新增加的内容一一解释如下：

　　新增了一个 ACL(fi-main) 并应用在具备访问权限的接口下 ( 财务部所在的 vlan4) 的 in 方向，使用该 acl 中具备 reflect 关键字的 acl 条目来捕捉建立反向 ACL 条目所需要的信息。我们将该 ACL 称为主 ACL 。

　　 reflect r-main timeout xxx ： 其中的 reflect 关键字表明该条目可以用于捕捉建立反向的 ACL 条目所需要的信息。 r-main 是 reflect 组的名字，具备相同 reflect 组名字的所有的 ACL 条目为一个 reflect 组。 timeout xxx 表明由这条 ACL 条目所建立起来的反向 ACL 条目在没有流量的情况下，多长时间后会消失（缺省值为 300 秒），单位为秒。

　　 evaluate r-main ： 我们注意到在 fi-access-limit( 我们把它称为反 ACL) 增加了这样一句，这一句的意思是有符合 r-main 这个 reflect 组中所定义的 acl 条目的流量发生时，在 evaluate 语句所在的当前位置动态生成一条反向的 permit 语句。

　　反向 ACL 的局限性：

　　 必须使用命名的 ACL ，其实这不能叫局限性，应该算注意事项吧；

　　 对多通道应用程序如 h323 之类无法提供支持。

　　好了，到现在我们从 IP ACL 的基础知识讲起，中间讲述了标准的 IP ACL 、扩展的 IP ACL 、基于名字的 ACL 、基于时间的 ACL 、反向 ACL 等诸多内容，这些 ACL 在 ios 的基本 IP 特性集中都能提供支持，在一般的企业网或校园网中也应该完全够用了。如果各位看官还需要了解更加深入的知识，如 CBAC 之类能够为多通道应用程序提供良好支持的配置技术的，请参考《 Cisco IOS Security Configuration Guide ， Part 3: Traffic Filtering and Firewalls 》。

　　 “ 站住！ ” ， 70 正想开溜，只听那网管一声大吼， “ 有什么办法能知道 ACL 都过滤了从哪儿来，到哪儿去的流量？？ ” 。呵呵，刚才忘记说了，你只需要在需要记录的 acl 条目的最后加一个 log 关键字，这样在有符合该 ACL 条目数据包时，就会产生一条日志信息发到你的设备所定义的日志服务器上去。谢谢大家的捧场，本文到此为止。