三层设备ACL配置实战：通配符掩码、自反ACL与时间ACL详解

发布时间：2026/10/15 19:55:38
三层设备ACL配置实战：通配符掩码、自反ACL与时间ACL详解
1. 为什么要在三层设备上折腾ACL很多人第一次接触ACL是在二层接入交换机上做端口隔离或者简单的MAC过滤。但真正让ACL发挥出完整价值的场景是在三层设备上——也就是具备路由能力的交换机或路由器。三层设备上的ACL不只是拦或者放这么简单它直接决定了不同网段之间能不能通、哪些流量能通、通的路径是什么。换句话说ACL在三层设备上扮演的是交通警察的角色而不是小区门口的保安。我见过不少刚入行的朋友拿到一台三层交换机VLAN也划了SVI也配了路由也通了结果一加ACL整个网络全断了连管理口都进不去。这种情况十有八九是因为ACL的匹配顺序或者应用方向搞反了。所以这篇内容我想把三层设备上ACL的配置逻辑从头到尾捋一遍包括它和二层ACL的本质区别、通配符掩码的计算方法、应用接口和方向的选取原则以及我自己踩过的几个印象比较深的坑。这篇内容适合已经了解VLAN和基础路由概念、但对ACL还停留在知道个大概阶段的读者。如果你已经能熟练配ACL也可以看看后面关于自反ACL和基于时间的ACL部分那是我在实际项目里用得比较多的高级玩法。全文会以华为VRP和思科IOS两大主流平台为参照来写因为这两个平台的ACL语法差异不小混着用很容易出错。2. 三层ACL和二层ACL到底差在哪2.1 匹配字段的维度差异二层ACL主要看的是源MAC、目的MAC、以太网类型这些链路层信息。三层ACL看的是源IP、目的IP、协议号、端口号这些网络层和传输层信息。这个差异看起来很简单但它决定了两者能解决的问题完全不同。举个例子同一个VLAN里两台主机互访二层设备只能通过MAC来区分但MAC地址是可以伪造的而且管理起来非常麻烦。三层设备就不一样了它可以通过IP地址来精确控制还能细化到只允许A访问B的80端口不允许访问22端口这种粒度。这就是为什么核心层和汇聚层的访问控制一定要用三层ACL来做。2.2 应用位置的差异二层ACL通常应用在交换机的物理端口或者VLAN上作用范围局限在同一个广播域内。三层ACL可以应用在SVI接口、三层物理接口、甚至VLAN组上作用范围跨越多个网段。这里有一个很容易混淆的点三层ACL应用在SVI上时它控制的是进入这个SVI所代表的网段或者从这个网段出去的流量而不是控制某个物理端口上的流量。很多人在SVI上配了ACL发现不生效就是因为没搞清楚这个逻辑。2.3 处理顺序的差异三层设备处理ACL的顺序和二层设备有本质区别。三层设备在收到一个包之后先查路由表确定出接口然后再在出接口方向检查ACL。如果是入方向则先检查ACL再查路由表。这个顺序直接影响了ACL的编写逻辑。我个人的经验是入方向ACL尽量简单出方向ACL可以写得细一些。因为入方向ACL在路由之前执行如果写得太复杂会影响设备的路由性能出方向ACL在路由之后执行此时设备已经知道包该往哪走了可以更精确地匹配。3. 通配符掩码ACL里最容易算错的东西3.1 通配符掩码和子网掩码的本质区别子网掩码里1表示网络位0表示主机位。通配符掩码正好反过来0表示必须匹配1表示忽略不匹配。这个反直觉的设计是很多人算错ACL的根本原因。比如你要匹配192.168.1.0/24这个网段子网掩码是255.255.255.0对应的通配符掩码是0.0.0.255。再比如你要匹配192.168.1.0/25子网掩码是255.255.255.128通配符掩码就是0.0.0.127。3.2 精确匹配和任意匹配的写法精确匹配一个IP地址通配符掩码是0.0.0.0。在华为设备上可以简写为host关键字在思科设备上也是host。匹配任意IP地址通配符掩码是255.255.255.255华为用any思科也用any。这里有一个细节华为设备上写rule 5 permit ip source 192.168.1.1 0和写rule 5 permit ip source 192.168.1.1 0.0.0.0是等价的但前者更简洁。思科设备上则必须写完整的0.0.0.0或者用host关键字。3.3 奇数网段和偶数网段的匹配技巧这是通配符掩码最实用的一个技巧。假设你要匹配所有偶数网段比如192.168.0.0/24、192.168.2.0/24、192.168.4.0/24通配符掩码可以写成0.0.254.0。因为第三段是偶数二进制最后一位是0通配符掩码对应位写1表示忽略写0表示必须匹配0。同理匹配奇数网段就是0.0.1.0。这个技巧在写汇总ACL的时候特别有用能大幅减少ACL的条目数量。匹配需求网络地址通配符掩码说明单个IP192.168.1.10.0.0.0精确匹配/24网段192.168.1.00.0.0.255匹配整个C类/25网段192.168.1.00.0.0.127匹配前半段偶数网段192.168.0.00.0.254.0匹配第三段为偶数的奇数网段192.168.1.00.0.1.0匹配第三段为奇数的任意地址0.0.0.0255.255.255.255等价于any注意通配符掩码不要求二进制连续这是它比子网掩码灵活的地方但也是容易出错的地方。写完ACL之后一定要用display acl或者show access-lists确认匹配计数。4. 基础ACL配置从需求到落地4.1 需求分析先想清楚要控制什么假设有这样一个场景某公司有三个网段分别是办公区192.168.10.0/24、服务器区192.168.20.0/24、访客区192.168.30.0/24。需求是办公区可以访问服务器区的Web服务和文件共享访客区只能访问服务器区的Web服务服务器区不能主动访问其他两个区。这个需求看起来简单但拆解下来至少涉及三条ACL规则第一条允许办公区到服务器区的80和443端口第二条允许办公区到服务器区的445端口第三条允许访客区到服务器区的80和443端口最后默认拒绝所有其他流量。4.2 华为VRP平台配置示例先创建高级ACL编号3000到3999是高级ACL的范围acl number 3000 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 80 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 443 rule 15 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 445 rule 20 permit tcp source 192.168.30.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 80 rule 25 permit tcp source 192.168.30.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 443 rule 100 deny ip然后在服务器区的SVI接口上应用interface Vlanif20 traffic-filter inbound acl 3000这里用inbound方向意思是进入服务器区网段的流量要检查ACL。为什么用入方向而不是出方向因为服务器区是被保护的对象在入口处拦截最直接而且不会影响服务器区主动发出的流量。4.3 思科IOS平台配置示例思科用命名ACL或者编号ACL都可以编号1300到1999是扩展ACL的范围ip access-list extended SERVER_PROTECT permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 80 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 445 permit tcp 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 80 permit tcp 192.168.30.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443 deny ip any any应用到SVI接口interface Vlan20 ip access-group SERVER_PROTECT in思科的扩展ACL末尾默认隐含deny ip any any但华为的ACL末尾默认是permit。这个差异非常重要华为设备上如果不手动加rule 100 deny ipACL末尾会放行所有流量等于白配。4.4 验证和调试方法配完ACL之后不要急着走开。先用display acl 3000华为或show ip access-lists SERVER_PROTECT思科查看规则和匹配计数。然后从办公区的一台主机上ping服务器区的主机应该不通访问服务器的Web页面应该能打开。再从访客区的主机测试Web能访问但ping不通。如果发现Web也访问不了先检查ACL规则里的端口号写对没有再检查应用方向是不是反了。我遇到过好几次把inbound写成outbound的情况结果ACL完全不生效因为流量根本不从那个方向走。5. 自反ACL让回程流量自动放行5.1 为什么需要自反ACL普通ACL是单向的。你允许了办公区访问服务器区的80端口但服务器区返回给办公区的响应流量是另一个方向的需要另外写一条ACL来放行。如果每个需求都要写两条ACL条目数量会翻倍管理起来很麻烦。自反ACLReflexive ACL解决了这个问题。它能在出方向流量通过时自动生成一条临时的入方向规则只放行对应的回程流量。会话结束后临时规则自动删除。5.2 华为平台的自反ACL配置华为叫自反ACL配置稍微复杂一些acl number 3000 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 destination-port eq 80 reflect web-session acl number 3001 rule 5 permit tcp source 192.168.20.0 0.0.0.255 destination 192.168.10.0 0.0.0.255 destination-port eq 80 established web-session然后在接口上应用两个ACL一个入方向一个出方向。5.3 思科平台的自反ACL配置思科的写法更直观一些ip access-list extended OUTBOUND permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 80 reflect WEB_TRAFFIC permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443 reflect WEB_TRAFFIC ip access-list extended INBOUND evaluate WEB_TRAFFIC deny ip any any自反ACL的优点是显而易见的规则自动生成、自动老化不需要手动维护回程规则。但它的缺点也很明显配置复杂度高排错困难而且不是所有平台都支持。我在实际项目中一般只在安全要求比较高的边界设备上用自反ACL内部网络还是用普通ACL加状态检测防火墙更省心。6. 基于时间的ACL上班时间才生效6.1 时间范围的定义基于时间的ACL允许你指定规则生效的时间段。比如只允许员工在上班时间访问娱乐网站或者下班后禁止访问服务器区。华为平台的时间范围定义time-range WORK_TIME 08:00 to 18:00 working-day思科平台的时间范围定义time-range WORK_TIME periodic weekdays 8:00 to 18:006.2 将时间范围绑定到ACL规则华为平台acl number 3000 rule 5 permit ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255 time-range WORK_TIME思科平台ip access-list extended TIME_BASED permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 time-range WORK_TIME6.3 时间ACL的坑时间ACL最大的坑是设备时钟。如果设备的时钟不准时间ACL就会在错误的时间生效。所以配时间ACL之前一定要先配NTP同步确保设备时间准确。另一个坑是时间ACL的匹配精度。华为设备的时间范围匹配精度是分钟级思科也是分钟级。如果你需要秒级的精度时间ACL满足不了得用其他方案。还有一个容易被忽略的点时间ACL在时间范围之外的行为。华为设备上如果ACL规则绑定了时间范围在时间范围之外这条规则不生效会继续往下匹配。思科设备上也是一样。所以如果你写了一条permit绑定了时间范围在时间范围之外这条规则不生效可能会被后面的deny规则匹配到。这个逻辑一定要想清楚。7. 那些年我踩过的ACL坑7.1 坑一华为ACL末尾默认放行这是我踩过最多次的坑。华为的ACL和思科不一样思科的ACL末尾隐含deny ip any any华为的ACL末尾隐含permit。如果你在华为设备上写了一条deny规则就以为万事大吉了实际上所有不匹配这条规则的流量都会被放行。正确的做法是在华为ACL的最后手动加一条rule 100 deny ip。注意规则编号要留出足够的空间方便以后在中间插入新规则。7.2 坑二ACL应用方向搞反ACL应用在接口上有两个方向inbound和outbound。inbound是进入接口的流量outbound是从接口出去的流量。这个进入和出去是相对于设备而言的不是相对于网段而言的。我见过有人在服务器区的SVI上配了outbound方向的ACL想控制办公区访问服务器区的流量。结果发现ACL完全不生效因为办公区访问服务器区的流量是进入服务器区SVI的应该用inbound方向。7.3 坑三ACL规则顺序错误ACL是从上往下逐条匹配的匹配到第一条就停止不再往下查。所以规则的顺序非常重要。如果你把deny ip any any放在了第一条那后面的所有permit规则都不会生效。我一般的做法是先写具体的permit规则再写具体的deny规则最后写一条笼统的deny ip any any。规则编号以5或10为步长方便以后插入。7.4 坑四修改ACL后忘记重新应用在华为设备上修改ACL之后不需要重新应用ACL会自动生效。但在思科设备上如果你修改的是命名ACL也不需要重新应用。但如果你修改的是编号ACL而且这个ACL已经被应用到了接口上修改之后需要重新应用才能生效。这个差异导致我在思科设备上排查了好几次为什么改了ACL不生效的问题。后来养成了习惯改完ACL之后不管什么平台都重新应用一遍确保万无一失。7.5 坑五ACL条目太多导致性能下降ACL的匹配是线性的条目越多匹配时间越长。如果ACL有几百条规则而且流量很大设备的CPU会明显上升。我见过一台三层交换机因为ACL条目过多CPU跑到80%以上导致路由协议邻居震荡。解决方法是尽量用汇总规则减少条目数量或者把ACL拆分成多个应用在不同的接口上。如果实在需要很多条目考虑用对象组华为或者对象组思科来简化配置。坑点现象根因解决方案华为ACL末尾默认放行该拦的没拦住华为ACL末尾隐含permit手动加deny ip any any应用方向搞反ACL完全不生效inbound/outbound理解错误从设备视角判断方向规则顺序错误该通的没通deny规则放在了permit前面具体规则在前笼统规则在后修改后未重新应用改了ACL不生效思科编号ACL需要重新应用改完统一重新应用条目过多CPU升高、邻居震荡ACL线性匹配耗时汇总规则、拆分ACL、用对象组8. 进阶技巧ACL和路由策略的配合8.1 ACL在路由策略中的角色ACL不仅可以用来过滤数据流量还可以用来匹配路由条目。在路由策略Route-Policy中ACL经常被用来作为匹配条件决定哪些路由需要被修改属性或者被过滤。比如你要在OSPF里过滤掉某个网段的路由可以先用ACL匹配这个网段然后在路由策略里调用这个ACLacl number 2000 rule 5 permit source 192.168.20.0 0.0.0.255 route-policy FILTER_ROUTE deny node 10 if-match acl 2000 route-policy FILTER_ROUTE permit node 20 ospf 1 import-route direct route-policy FILTER_ROUTE8.2 ACL在NAT中的应用ACL还可以用来定义NAT的感兴趣流。只有匹配ACL的流量才会被NAT转换不匹配的流量直接转发。这个用法在出口路由器上非常常见。acl number 2000 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 permit source 192.168.30.0 0.0.0.255 interface GigabitEthernet0/0/1 nat outbound 20008.3 ACL在QoS中的应用ACL还可以用来分类流量配合QoS策略实现带宽限制或者优先级标记。比如你要限制访客区的下载带宽可以先用ACL匹配访客区的流量然后在QoS策略里调用这个ACL。这个用法在三层设备上很常见尤其是汇聚层设备。但要注意的是ACL匹配本身会消耗设备性能如果QoS策略里的ACL条目太多可能会影响设备的转发性能。9. 写在最后一些个人习惯配ACL这么多年我养成了几个习惯分享出来供参考。第一个习惯是先写需求文档再配ACL。把谁访问谁、什么协议、什么端口、什么时间列成表格然后再翻译成ACL规则。这样不容易漏掉需求也方便以后审计。第二个习惯是ACL规则编号留足空间。我一般用5、10、15这样的步长而不是1、2、3。这样以后需要在中间插入规则的时候不用重新编号。第三个习惯是配完ACL先测试再上线。在测试环境验证通过之后再应用到生产环境。如果条件不允许至少要在业务低峰期操作并且准备好回滚方案。第四个习惯是定期审计ACL。网络需求是变化的半年前配的ACL可能现在已经不需要了。定期清理无效规则既能提升设备性能也能减少安全隐患。ACL这个东西入门容易精通难。基础语法半小时就能学会但要在复杂的网络环境中用好需要大量的实践和踩坑。希望这篇内容能帮你少走一些弯路。如果你在配ACL的过程中遇到了什么奇怪的问题欢迎一起交流。