事情得从一次加班说起。那年出口路由器上挂着三十多条老ACLAccess Control List访问控制列表每条规则还没有注释。业务部门报某个系统访问不通没人敢动那堆规则因为谁也不清楚哪条是当年临时加的、哪条已经失效。我蹲在机房里一条一条捋最后发现只是新加的一条deny规则顺序不对把后面所有permit全挡住了。从那次之后我就坚定了一件事ACL这种东西命令不过是几分钟的事真正考验人的是对匹配逻辑、通配符掩码和接口方向的理解。这篇文章不打算按教科书的路子讲我就按华为、H3C设备上的实际配置经验把基本ACL、高级ACL、IPv6 ACL配置实验、ACL配合策略路由这些高频场景一次说透再把我踩过的坑和排查思路全摆出来。适合刚进数通圈子的新人也适合已经会敲命令但经常被“明明配置了却不生效”折磨的老兵。1. 先打通概念ACL到底是干什么的1.1 一个我常用的比喻小区门禁卡理解ACL最简单的方式就是把它想象成小区门口保安手里的登记表。普通门禁卡只能核对你是不是本小区的人对应的就是基本ACL只看源地址匹配“你是谁”决定放不放行。高级一点的门禁系统会登记你的姓名、要去哪栋楼、什么时间来、是否携带电脑设备对应高级ACL它可以检查源地址、目的地址、协议类型、源端口、目的端口甚至TCP标志位。所以ACL在网络设备里的本质是一张“包过滤规则表”。当数据包从接口进来或者出去时设备把报文里的关键字段提取出来从上到下和这张表里的规则逐条比对命中哪条就执行哪条的动作也就是permit放行或者deny丢弃。它是一个非常底层的流分类工具也是后面要讲的策略路由、QoS队列、防火墙策略的基础。理解了这一点你就明白为什么ACL配置不当会影响整个业务链路。1.2 按编号分档基本、高级、二层ACL怎么选华为和H3C设备的ACL编号区间划分几乎是通用的设计这个编号段的逻辑本身就暗示了用途。基本ACL用2000到2999匹配维度最少通常只匹配源IP地址偶尔加时间范围。优点是占用设备资源少、规则简单清晰适合做网段级别的粗粒度隔离。高级ACL用3000到3999能匹配五元组也就是源IP、目的IP、协议号、源端口、目的端口还能匹配TCP标志位、DSCP优先级、分片标记等是生产环境里的主力。二层ACL用4000到4999匹配源MAC、目的MAC、VLAN ID、二层协议类型一般用在接入交换机上用来防止仿冒MAC、限制某个终端的接入权限。用户自定义ACL是5000到5999通常用于配合QoS策略做复杂流分类普通运维用得少。ACL类型编号范围主要匹配维度典型场景基本ACL2000-2999源IP地址、时间范围限制网段互访、限制远程管理IP高级ACL3000-3999源/目的IP、协议、端口、标志位服务器端口保护、业务精细化放行二层ACL4000-4999源/目的MAC、VLAN、二层协议接入层终端管控、防MAC仿冒选型时的经验是能用基本ACL解决的事不要升级到高级ACL规则越复杂排查越费劲。但涉及服务器端口管控、业务白名单直接用高级ACL别拿基本ACL硬凑。对了如果你见过Cisco设备它的标准ACL编号是1到99、扩展ACL是100到199本质功能一样但编号逻辑不同换厂商时别记混。2. 配置ACL前必须吃透的四个关键点2.1 规则匹配顺序和隐式拒绝90%的ACL故障都出在这里ACL的匹配逻辑非常简单但“简单”恰恰是问题源头。设备从上到下逐条匹配规则一旦命中就立刻执行动作不再继续往下看。这意味着规则顺序直接决定最终效果。比如你想拒绝192.168.1.0网段却在最前面写了一条permit any那所有流量都会命中permit any后直接放行后面的deny规则根本轮不到执行。另一个容易被忽略的是隐式拒绝。所有ACL末尾都有一条看不见的规则deny any。如果流量把每条规则都过了一遍仍然没有匹配项最终会被丢弃。所以有些新手写ACL时只写了deny规则忘了放行必要的流量结果全网断连。我的习惯是在动手配置前先用表格列一个“业务访问矩阵”谁访问谁、走哪个协议端口、方向是什么、是允许还是拒绝。把规则顺序按“具体放前面、宽泛放后面”的原则排好再翻译成命令行。这样在设备上敲命令只是最后一步而不是边敲边想。2.2 通配符掩码别当子网掩码用30秒学会计算这是ACL配置里翻车率最高的知识点。ACL里的掩码叫通配符掩码和路由配置里的子网掩码完全不是一回事。通配符掩码里的0表示“必须严格匹配这一位”1表示“这一位可以任意忽略”。举个例子192.168.1.0 0.0.0.255表示前三段必须匹配192.168.1最后一段任意所以匹配的是192.168.1.0到192.168.1.255整个网段。如果写192.168.1.10 0.0.0.0四个字节全部严格匹配那就是精确匹配这单个IP更简洁的写法是host 192.168.1.10。如果写any等价于0.0.0.0 255.255.255.255也就是全部匹配。计算通配符掩码有个傻瓜式方法直接用255.255.255.255减去子网掩码。比如/22的子网掩码是255.255.252.0那通配符掩码就是0.0.3.255。这比对着二进制一个个抠快得多也不容易错。2.3 规则编号步长为什么建议从5开始华为和H3C设备配置ACL时如果不写规则编号系统会自动编号默认步长是5也就是5、10、15、20这样递增。这个设计是给后续插入规则留预留空间的。比如你现在有rule 5和rule 10之后想在中间插一条就可以直接指定rule 7或者rule 6不需要重排后面的规则。如果不用步长而连续写了很多条不带编号的规则后续想插入一条新规则时只能把后面所有规则都删了重写这在生产设备上非常危险。所以我建议平时养成手动指定编号的习惯每个ACL开头留几条空编号特别是允许类规则之间要留出足够间隔。查看已有规则编号用display acl删除中间某条规则用undo rule rule-id这个操作不会影响其他规则。2.4 接口方向inbound/outbound到底怎么理解ACL最终要挂在接口上才生效命令是traffic-filter inbound acl xxx或traffic-filter outbound acl xxx。判断方向时站在设备内部去看流量从外部进入这个接口叫inbound流量从这个接口发出去叫outbound。最容易混淆的场景是保护服务器。服务器连着接入交换机的端口客户端流量是从外部进入这个端口再到服务器所以在该接口上应该配置inbound方向。如果错误地配置成outboundACL根本匹配不到这些流量。还有一个细节ACL过滤是单向的允许客户端访问服务器的同时服务器返回客户端的流量不会受这条规则影响。如果业务上需要限制服务器主动外连必须在出方向单独配置另一条规则。判断方向时不要把“流入业务”和“入接口方向”混在一起一定要在纸上画出设备和流量的相对关系。3. 实操案例华为/H3C设备上的ACL配置全过程3.1 案例一基本ACL限制指定网段访问管理接口先来一个最常用的场景。公司要求只有网管段的10.10.1.0/24地址能SSH登录交换机其他地址一律禁止。这个需求用基本ACL就能满足因为在SSH登录场景里只关心来源IP。acl number 2001 rule 5 permit source 10.10.1.0 0.0.0.255配置完ACL之后把它应用到VTY虚拟终端线上。H3C设备命令user-interface vty 0 4 acl 2001 inbound authentication-mode aaa华为设备的配置思路一样VTY视图下同样执行acl 2001 inbound。这里的inbound指的是远程登录进入系统方向很好理解。需要特别提醒的是ACL末尾隐式拒绝所有如果允许列表里漏掉了某个网管地址操作到一半就可能把自己锁在设备外面。所以第一次部署时先把所有允许的管理IP全部写进规则里再三确认没问题再应用。配置完成后不要关当前SSH窗口另开一个窗口从不同地址测试登录是否被拒绝。3.2 案例二高级ACL精确放行Web和SSH流量服务器10.0.0.10上跑着Web服务办公网192.168.1.0/24的客户端需要访问80和443端口同时运维人员要从办公网SSH登录这台服务器的22端口其他来源和端口一律拒绝。这是典型的高级ACL五元组匹配场景。acl number 3000 rule 5 permit tcp source 192.168.1.0 0.0.0.255 destination 10.0.0.10 0.0.0.0 destination-port eq 80 rule 10 permit tcp source 192.168.1.0 0.0.0.255 destination 10.0.0.10 0.0.0.0 destination-port eq 443 rule 15 permit tcp source 192.168.1.0 0.0.0.255 destination 10.0.0.10 0.0.0.0 destination-port eq 22 rule 20 deny ip在连接服务器的接口视图下应用interface GigabitEthernet0/0/1 traffic-filter inbound acl 3000解释一下这里的逻辑。destination 10.0.0.10 0.0.0.0就是精确匹配目的IP 10.0.0.10destination-port eq 80表示目的端口等于80。最后一条deny ip其实可以省略因为隐式拒绝会兜底但我习惯加上理由是可以附带日志功能。需要加日志时写成rule 20 deny ip logging这样丢包还能在设备上留下审计记录。不过要注意生产环境大量访问被拒绝时日志放大效应会消耗CPU建议只在短时排障期开启。3.3 案例三华三设备IPv6 ACL配置实验IPv6环境下的ACL配置和IPv4有几点不同。首先是进入ACL视图的命令变成acl ipv6其次是在规则里地址后面跟的是前缀长度而不是通配符掩码。比如要允许2001:db8:1::/64网段访问2001:db8:2::10这台IPv6服务器的80端口配置如下。acl ipv6 number 3000 rule 5 permit tcp source 2001:db8:1:: 64 destination 2001:db8:2::10 128 destination-port eq 80H3C和华为新版VRP系统的命令格式基本一致。这里的64表示源地址的前缀长度等价于IPv4通配符掩码0.0.0.255的作用128表示精确匹配单个IPv6地址。很多人在IPv6 ACL上栽跟头就是把IPv4的写法套过来想在地址后面写一串通配符掩码结果语法报错。IPv6 ACL的规则参数就是前缀长度这是和IPv4最大的区别。接口下的应用命令也要带上ipv6关键字interface GigabitEthernet1/0/1 traffic-filter inbound ipv6 acl 3000实验时我的操作流程是先在设备上配置好IPv6地址和路由确认两端能ping通再下发ACL规则。这样做的好处是ACL生效前网络是通的一旦ACL应用后ping不通就能立刻确认是ACL拦截。如果反过来先把ACL配上再调路由出现问题时就分不清是路由问题还是ACL问题排查效率低很多。3.4 案例四ACL匹配配合策略路由把特定流量引到指定下一跳ACL本身只做匹配和动作动作只有permit和deny。但ACL还可以作为其他功能的“识别工具”最常见的就是配合策略路由实现分流。比如分公司192.168.2.0/24访问总部业务网段172.16.10.0/24时希望强制走专线下一跳10.0.0.2其他流量走默认路由。acl number 3002 rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 172.16.10.0 0.0.0.255然后配置策略路由调用这个ACLpolicy-based-route PBR_A permit node 10 if-match acl 3002 apply next-hop 10.0.0.2最后在流量的入接口上应用策略路由interface GigabitEthernet0/0/0 ip policy-based-route PBR_A理解一下这个过程ACL负责“认出”哪些流量需要特殊处理策略路由负责“执行”把流量扔到指定下一跳。两者是分离的。如果ACL没有命中策略路由就不生效如果ACL命中了但下一跳不可达行为取决于设备版本有些会放弃策略路由退回按普通路由表转发有些则直接丢弃。所以上线后务必抓包验证不能只盯着配置本身。4. 常见问题与排查技巧实录4.1 现象ACL配了流量还是“正常”进出这是被问得最多的一个问题“规则明明写上去了怎么访问还是通的”遇到这种情况先别怀疑设备坏了按顺序排查。第一步确认ACL到底挂到哪个接口、哪个方向了在设备上执行display traffic-filter applied-record把当前接口下的ACL应用情况全部列出来看。第二步要弄清楚业务流量的进出方向画出流量路径对照接口方向判断inbound和outbound有没有选反。第三步看规则本身。display acl 3000会显示出每条规则的匹配计数这个信息极有价值。如果命中计数一直为零说明规则本身没匹配到流量重点检查通配符掩码和端口号是否写错。如果计数很大但业务还是通再往顺序和放行规则上想。第四步临时把规则里的deny改成permit做对照测试验证ACL是否是唯一变量这个方法虽然简单粗暴但非常有效。4.2 通配符掩码翻车现场源地址怎么变成单个IP了之前说过一个真实的坑有同事想把192.168.1.0/24这个网段加入白名单配置命令写成了rule 5 permit source 192.168.1.0 255.255.255.0。这条命令不会报错设备正常接受但通配符掩码255.255.255.0的含义是匹配“192.168.1.0”这个单一IP地址的最后一个字节必须为0前面三个字节反而无所谓。所以实际匹配范围根本不是192.168.1.0/24而基本是只有192.168.1.0这一个地址几乎没有任何真实流量会命中。这种错误最坑的地方在于它不报错不细心根本发现不了。所以配置完ACL后必须用display acl复查一遍看规则的匹配结果是否和预期一致。我的习惯是直接在草稿纸上先算一遍通配符掩码凡是要匹配一个网段就写成诸如0.0.0.255、0.0.3.255这种以255结尾的形式凡是精确匹配就写0.0.0.0或者用host关键字。只要通配符掩码里出现了255在中间或开头就停一下想清楚再说。4.3 用display命令让规则“开口说话”调试ACL离不开几个命令我列一个现场常用速查表。目的H3C/华为命令说明查看ACL规则与命中次数display acl 3000最常用优先看匹配计数查看接口ACL应用情况display traffic-filter applied-record查方向和接口挂载清空ACL统计计数reset acl counter 3000调整后重新统计验证查看所有ACL规则display acl all变更前检查编号冲突查看策略路由display ip policy-based-route策略路由场景下配合使用有个经验分享一下调整ACL后先执行reset acl counter把计数清零再发起测试流量过几秒重新display acl看目标规则的计数是否增长。如果增长说明ACL参与了处理如果不增长先别纠结配置重点检查流量是不是根本就没走到这个接口上来。这种“让数据说话”的排查方式比对着配置发呆有效率得多。4.4 变更演练如何在生产环境安全上线ACLACL变更虽然日常但出问题就是全网断连级别的故障。我给自己定了一套流程分享给同行参考。第一变更前把当前配置完整导出至少导出接口配置和ACL配置关键业务服务商的网段端口清单也整理好避免上线时才发现漏放行。第二先在测试设备上或者用一台空闲接口演练一遍把命令敲熟确认语法在当前设备版本下完全兼容。第三预演回退方案。接口下去掉ACL就是一行undo traffic-filter inbound但对一个复杂的ACL做修改时回退脚本最好提前准备好。第四点也是最容易被忽视的设备远程管理通道千万不要被自己的变更波及。如果ACL是用在VTY下的登录限制那配置前必须确保console口可用或者有带外管理通道。否则一旦ACL写错当前SSH连接被断你就只能打车去机房了。这个教训我不是一次听到是真有人被锁在设备外面过。最后上线时间选在业务低峰变更后保留观察窗口至少观察十分钟再离场。我个人操作ACL时养成的习惯不算多复杂但很管用。每一条规则后面都加上description描述写清楚这条规则是谁、在什么时候、为了什么业务加的同时用一张Excel表格维护“业务网段、端口、规则编号、负责人”的映射关系。定期把设备上的ACL导出来对一遍把命中计数低到可疑的规则单独标出来找业务确认后再清理。设备上的ACL规则不是越全越好规则越多后续维护成本越高出错概率也越大。最后再分享一个保命技巧做任何可能影响管理通道的ACL变更之前确保console线已经接好或者带外管理开着。这个习惯是从一次远程配置失误之后养成的那次如果没留后路我可能就要半夜赶去机房刷机了。
