1. 一个让业务中断半小时的故障逼我重新梳理ACL先说一件我印象挺深的事。有次帮客户做网络改造一台新上线的核心交换机要替换老的设备业务割接窗口定在凌晨两点。结果切换完还不到十分钟监控告警就响了办公区访问服务器的流量全部超时。当时我第一反应是路由没起来结果两边的网关和互联地址都能通ping服务器也通但业务端口就是连不上。排查到凌晨三点多最后发现是迁移配置时新设备上的访问控制列表——也就是我们常说的ACL——少了一条放通规则把服务器的8080端口在入方向给deny掉了。那次之后我就养成了一个习惯只要涉及ACL不管多急先把“这列表到底在过滤谁、过滤什么方向、匹配顺序是什么”这三件事在纸上写清楚再动手。ACLAccess Control List访问控制列表在绝大多数网络工程师的工作里是既基础又容易出幺蛾子的东西。说它基础是因为概念非常简单——一张列表里面若干条规则被匹配的流量要么放行、要么拒绝。说它容易出幺蛾子是因为它和接口、方向、规则顺序、隐含规则这些隐含逻辑纠缠在一起任何一环理解偏差就可能在半夜给你送一份大礼。这篇内容我想结合实际运维里踩过的坑把ACL从原理、分类、配置到排错完整捋一遍。不光是给你念一遍命令更想告诉你为什么每个参数要这么配以及遇到“看着配对了就是不生效”的情况时该从哪个方向查。对正在学ccnp、hcip这类认证的或者刚接手生产网络还没有太多ACL实战经验的同行应该能省不少弯路。2. 从规则编号到方向绑定ACL配置里的几个核心决策点2.1 先分清基本ACL和高级ACL的分工设备上的ACL按功能大致分三类基本ACL、高级ACL还有针对数据链路层的二层ACL。市面最常见的还是前两个。基本ACL的范围编号一般是2000到2999它只看一个东西源地址。比如你只想限制某个网段不能访问某个区域一条规则就能搞定逻辑最简单。但它有个硬伤——分不清目的地址和端口。同一个网段的用户访问OA系统和访问视频服务器的请求它都一视同仁。高级ACL的编号范围是3000到3999它可以同时基于源IP、目的IP、协议类型、源端口、目的端口、还有TCP标志位等来做精确匹配。说直白点它能区分“来自10.1.1.0/24的流量访问服务器443端口”和“来自同一网段访问其他端口”。生产环境里大多数精细管控都需要高级ACL因为控制粒度越细误伤面越小。还有一种常见划分方式是思科风格的命名ACL和编号ACL华为、H3C设备也支持命名方式本质都一样。核心在于你把策略组织成具备可读性的形式方便后续维护。2.2 入方向还是出方向想清楚再绑接口我见过最频繁的配置错误就是方向搞反。ACL绑到接口上时会涉及两个方向概念入方向inbound流量从外部进入接口的时候匹配出方向outbound流量从本设备向外发送的时候匹配。很多人以为“我限制不许访问服务器这算是出方向还是入方向”完全取决于你从哪个接口角度去看。比如你在服务器侧连接的交换机接口上流量从服务器往外发的时候如果要在出口做过滤那就要绑定在出方向。我习惯的使用原则是越靠近源端控制越好但也不绝对。举个例子如果我在核心交换机上限制某个业务访段访问服务器而服务器接口就在同一台交换机上那我在服务器接入口的入方向绑ACL最生效因为流量一进这个口就被过滤如果流量是经由这台交换机转发到别处的可能就要在源接口入方向或者目的接口入方向做得结合你设备转发路径去定。2.3 规则顺序、隐含拒绝与步长设计ACL里每条规则都有编号设备默认步长一般为5即规则编号间隔5方便你以后在中间插入新的规则。这一点我觉得不少人忽略了——很多人习惯让规则编号挨着写1、2、3、4结果某天想加一条优先级比第2条高但比第3条低的规则发现编号空间不够要么把后面的规则全部重新编号要么只能删了重建。为什么规则顺序这么重要因为ACL匹配是自上而下逐条进行的。一条流量进入之后从编号最小的规则开始比对一旦匹配就立即执行permit或deny后面的规则不再看了。这个机制决定了一个非常经典的问题如果前面有个deny把某类流量拦住了后面的permit即使写得再正确也不会被查到。所以在配置ACL时一定要把最精确的放通规则放在前面把相对宽松的限制放在后面顺序反了就会出现“范围大的先permit了后面的range根本拦不住”的效果。还有个概念必须深刻记住ACL默认最后有一条隐含的deny any。也就是说如果你的列表里只写了三条permit其他所有流量全部会被丢弃。很多人的ACL“灵异事件”其实就是隐式deny在起作用。比如你只想放通80端口结果配置完之后整个网段连ping都不通了因为ICMP流量没有被匹配到正好被最后那条隐形的deny给拦下。3. 动手配置在华三设备上从IPv4 ACL做到IPv6 ACL3.1 IPv4 ACL完整配置实测假设现在有个需求办公网192.168.10.0/24的终端可以访问服务器192.168.20.100的HTTP服务TCP 80端口其余来自办公网对这台服务器的访问全部拒绝但服务器可以主动向外发起连接其他网段不受影响。在H3C设备上我会这样写# 创建高级ACL 3005 acl advanced 3005 # 规则5放通源10.1.1.0/24访问服务器192.168.20.100的80端口 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.100 0 destination-port eq 80 # 规则10拒绝同一个源网段访问服务器其他端口 rule 10 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.100 0 quit # 在服务器侧的接口上入方向绑定 interface GigabitEthernet1/0/1 traffic-filter inbound acl 3005 quit注意这里有个细节企业级设备配置端口匹配时用的是通配符掩码不是子网掩码。192.168.10.0 0.0.0.255的意思是匹配前24位固定、后8位任意它和子网掩码255.255.255.0表达的地址范围一样但书写逻辑是反过来的。很多刚入门的朋友在这里就会卡住第一次写ACL容易不小心写成255.255.255.0那匹配出来的范围就完全错了。放通HTTP访问、deny同网段其他所有流量这一条很多初学者会问“既然最后有隐式deny那我只要写一条rule 5 permit就够了还用写rule 10吗”从效果上看确实可以不写因为那些流量反正会被隐式deny掉。但显式写出来的好处是排错时你能立刻看出来意图而且如果后续有人往ACL后面加规则有两条规则的存在能把逻辑表达得更清晰。接下来看流量走到哪里。如果流量是办公网直接发往服务器交换机只是二层转发那么ACL绑在接入服务器的接口入方向就可以生效。但生产环境如果服务器前面还有防火墙通常更建议在防火墙上做区域策略而不是ACL硬切避免ACL太复杂导致后期运维灾难。3.2 IPv6 ACL实验要点IPv4的ACL很多教材讲得透但IPv6 ACL往往一笔带过。我看热词里有“华三 ipv6 acl配置实验”确实见过不少人配置IPv6 ACL时踩坑最大的坑就是通配符掩码完全不一样。华三的IPv6 ACL基本语法是这样# 创建IPv6基本ACL编号范围2000到2999但需要指定ipv6 acl ipv6 basic 2001 rule 5 permit source 2001:db8:10::/64 quit # 创建IPv6高级ACL 3005 acl ipv6 advanced 3005 rule 5 permit tcp source 2001:db8:10::/64 destination 2001:db8:20::100 destination-port eq 80 quit # 接口绑定 interface GigabitEthernet1/0/1 traffic-filter inbound ipv6 acl 3005 quit这里最大的区别是IPv6地址后面直接跟前缀长度不再使用通配符掩码。在IPv4里你写 0.0.0.255 这样的东西在IPv6里完全不存在这个写法。如果你习惯性地把IPv4的配置思路照搬到IPv6大概率会报错。另一个IPv6特有的大坑是协议匹配。IPv6环境下ping用的是ICMPv6它不只是像IPv4那样用于测试连通性还负责邻居发现NDP等关键功能。如果你的IPv6 ACL把ICMPv6全部deny掉那设备之间连基本的邻居关系都建立不起来路由起不来、地址解析也会失败整个IPv6网络直接瘫掉。所以在配置IPv6 ACL时对ICMPv6的管控要格外谨慎一般建议先放通需要的NDP相关报文再限制其他类型的ICMPv6而不是一刀切。3.3 配置完怎么验收很多人配置完ACL看命令敲进去了就算完事我建议一定补上验证环节。最直接的方式是在设备上输入display acl 3005查看规则是否生效再结合display traffic-filter applied-record查看绑定关系。如果生产环境有流量统计能力还可以在ACL规则里打开统计计数跑一段时间后看计数器有没有增长。计数器增长说明这条规则确实被流量命中了完全没增长多半是ACL绑错了方向或者流量根本没走到这个接口。这一步对排查“为什么配置了还是能通/不能通”特别实用。4. 当ACL出现在Linux文件系统上从另一个维度理解“访问控制列表”很多时候提到ACL网络工程师脑子里全是路由器、交换机上的流量策略。但如果你去搜索“ACL权限”或“oracle19安装出现acl怎么办”你会发现另一片天地Linux文件系统里的ACL权限。这两个概念名字相同本质完全不同别搞混。4.1 网络ACL与文件系统ACL两个世界的两套规则网络ACL管的是那些从接口穿过的数据包而归操作系统管的是“某个用户/进程能不能访问这个文件”。Linux基础权限只有owner、group、others三组rwx能应对的场景有限。比如你希望特定用户能读/var/log/app.log但又不希望这个用户属于文件所在的组传统权限模型就只能绕路。这时候POSIX ACL出现它允许你给文件挂上额外的用户权限条目、组权限条目或者默认权限条目。用setfacl添加权限之后文件权限位的显示会变成一个加号比如-rw-rw----。这个加号的意思就是“这文件还有额外的ACL条目在看守”。用getfacl就能看到完整列表。4.2 Oracle 19c安装时的ACL问题到底发生了什么再来看“oracle19安装出现acl怎么办”。很多人在Linux服务器上装Oracle数据库跑了预检查之后弹出一堆错误其中就包括与ACL相关的提示。Oracle的预检查脚本会检测/u01/app/oracle等安装目录的权限配置如果你把目录用setfacl设置了额外ACLOracle可能会认为权限设置不符合它的安全模型。反过来有些安装步骤又会要求你的目录必须允许oracle用户有足够权限而默认权限不够需要你用ACL去补。遇到这类报错我的排查思路一般分三步先看报错原文确认是安装程序对ACL的校验拒绝还是目录权限不足导致无法写入。如果是权限不足找对一个原则能用chown和chmod解决的优先用传统权限不要动不动就加ACL。Oracle比较挑额外ACL容易让它误判。如果确实是ACL导致校验失败执行setfacl -b /path/to/dir清掉所有ACL条目然后用chown/chmod重新设置标准权限。例如我一般会把Oracle目录规划成mkdir -p /u01/app/oracle chown -R oracle:oinstall /u01 chmod -R 775 /u01这种做法的干净程度比东加一条ACL、西加一条ACL要少很多后患。这台机器上还曾经见过因为运维人员图省事给整个/u01挂了一条默认ACL结果新建子目录时全部继承权限列表越堆越长Oracle安装校验直接提示“permission denied on file systems”。清了ACL重设标准权限后预检查一次性通过。4.3 getfacl和setfacl常用操作速查既然提到文件系统ACL顺手列几个日常高频操作给不常接触Linux权限管理的朋友当作速查# 查看文件完整ACL信息 getfacl /path/to/file # 给指定用户添加读写权限 setfacl -m u:zhangsan:rw /path/to/file # 给指定组添加读权限 setfacl -m g:devteam:r /path/to/file # 移除文件上所有ACL条目恢复传统权限模式 setfacl -b /path/to/file # 设置默认ACL使新建子文件自动继承 setfacl -m d:u:zhangsan:rwx /path/to/dir一个重要的细节设置默认ACL是对目录递归生效的但只作用于之后新建的目录和文件已经存在的现有文件不会自动获得权限。如果你希望递归调整所有现有文件一定记得加-R参数比如setfacl -R -m u:zhangsan:rw /path/to/dir这个坑我见过太多次有人以为设了默认ACL就等于全部搞定了结果旧文件还是打不开。5. ACL失效时的排错链从配置到流量验证一个都不能少5.1 从配置层面查起先确认三件事如果发现ACL没有达到预期效果我建议从三个最基本的问题开始排查第一ACL是否真的在目标接口上应用了很多时候配置ACL规则时一切正常但忘了在接口上调用traffic-filter或者调用了之后因为接口配置顺序问题被后一条配置覆盖。用display traffic-filter applied-record就能看到接口和ACL的对应关系这是个好习惯。第二方向和ACL的编号是否匹配IPv4的ACL不会自动作用在IPv6流量上反过来也一样。如果你同时跑着两套协议栈一定要分别确认绑定了正确的方向。第三规则顺序对不对前面说过的顺序问题值得在排错时再验证一遍。建议用display acl看到的具体规则列表按照匹配顺序从第一条往后一字节一字节地对流量特征。5.2 从数据层面验证用抓包和计数定位如果配置层面全部没问题那就要去看真实流量了。最有效率的方式是利用ACL规则本身的计数功能。H3C设备上你可以在规则配置模式下加一条rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.100 0 destination-port eq 80 counting配置完成后再用display acl 3005观察计数器。如果规则命中次数为零说明流量没有经过这个检查点或者被更靠前的规则拦截了。如果命中次数正常但业务还是不通那问题多半不在ACL本身而是后续路由、防火墙策略或者服务器本机防火墙处理掉了。生产环境中还有个容易忽略的细节一些设备上的流量统计存在接口板和主控板之间的统计延迟配置了counting之后不是实时刷新的要隔几秒甚至几十秒再刷一次display才能看到计数明显增加别一下就急着下结论。5.3 经验总结ACL排错的几条“土办法”说几条我在实际项目中总结的土办法算不上多高级但每次都能帮我稳住局面。先把业务解耦。ACL排错时别一上来就怀疑设备。先用源地址、目的地址、端口构造一个最小化复现流量。比如telnet到设备上用ping、tracert、telnet客户端等工具分步测试确定流量是否真的到达了该接口。注意telnet本身用的23端口如果你的ACL并没有放通这个端口那用telnet去验证ACL反而是给自己找麻烦。建议借助交换机上的本地ping、debug ip packet这类工具辅助定位或者干脆在旁边接一台PC直接打流量。再看时间范围。有的ACL规则会带time-range工作日生效、下班自动失效。如果你排了半小时没找到问题突然想到“今天好像是周六”那基本上就是它了。时间范围配置尽量写成简单清晰的周期模式少用绝对时间段因为绝对时间在设备跨年断电重启之后经常出现时间漂移规则变成永久失效或者永久生效。最后别忽略日志。比较新的设备上可以把ACL命中日志送到日志服务器命中即告警。平时不开排错时临时开一下能直观看到哪条规则在哪一秒拦了哪个IP的哪个端口。不过日志量可能非常大开的时候建议只针对需要排查的规则并且控制输出速率不然设备CPU先承受不住。6. 写在最后ACL从来不是配完就结束的回到文章开头那个凌晨的故障。配置迁移时少放通一条规则本质上不是命令不会写而是我对ACL整条链路的设计缺少一次系统性检查。后来我给自己定了个规矩所有ACL配置都按“需求描述—规则规划—编号预留—方向确认—验证方法”五步走先写文档再敲命令文档里把隐式拒绝的后果、规则顺序的影响、IPv6场景的额外注意点都标注出来。这个方法帮我避免过很多后续的意外。顺便再分享一个实际运维中的小经验尽可能把你的ACL整理成有业务语义的命名比如“只允许办公区访问商城前端”而不是出一堆只看得懂编号的3001、3002、3003。等三个月后你再看这些配置命名清楚的那一部分几乎不需要回忆就能维护编号型的只能靠一遍遍翻注释和开旧工单猜测。ACL本身是网络运维里最基础的部件但这个“基础”用得好不好直接决定了你在网络出问题时是淡定查配置还是手忙脚乱地打了一晚上电话。