1. 先从一道实际需求说起ACL到底解决了什么问题我在帮一家企业做网络改造时遇到过一个很典型的场景财务部的人反馈ERP系统偶尔卡顿研发部的人抱怨访问外网总是超时而老板的诉求只有一句话——公司网络能不能别三天两头出问题。排查了一圈问题并不出在带宽不足而是出在网络上存在大量不该有的流量。有人在办公室里私接了一个小路由器整个办公室的终端全部通过这个路由器上网DHCP地址冲突一片有人用迅雷下载大文件把出口带宽占得死死的还有几个测试环境的主机对外开放了远程端口日志里能看到大量来自外部的扫描记录。这种时候ACL访问控制列表Access Control List就是最直接、最有效的处理手段之一。我所说的ACL是网络设备上一种基于包匹配规则的流量控制机制它可以告诉路由器或交换机哪些数据包可以放行哪些必须丢弃哪些流量需要特殊处理。这篇文章想和你聊的就是ACL的概述、组成、分类和应用我会结合我在实际项目里用到的配置方法、踩过的坑、以及一些和ACL相关但文档里很少讲透的细节尽量用大白话把这套机制讲清楚。无论你是刚接触网络的小白还是已经会配设备但没系统梳理过ACL的运维这篇文章都值得你花10分钟看完。很多初学者容易陷入一个误区觉得ACL就是“过滤IP的”其实远远不止。ACL能匹配的东西包括源IP、目的IP、协议类型、源端口、目的端口、分片信息、时间范围等等。它是很多高级网络功能的基础比如策略路由、QoS流量标记、NAT地址转换的匹配条件都依赖ACL。2. ACL的本质与组成一张规则表自上而下逐条匹配要理解ACL先得明白它的核心工作原理设备收到一个数据包后按照ACL中规则的顺序从上往下逐条匹配。如果数据包命中了某条规则就立即执行这条规则定义的动作允许或拒绝后续的规则不再检查。如果整个ACL从头到尾都没有匹配到末尾还有一个隐含的拒绝规则兜底。这里有一个关键点必须强调ACL规则是顺序敏感的。同样两条规则排列顺序不同最终效果可能完全相反。我见过不止一次工程师把拒绝规则写在了允许规则后面结果流量全被放行了ACL形同虚设。2.1 ACL的表项结构一条规则里到底有什么一条ACL规则里包含的信息量其实不少核心字段包括规则编号rule-id用来标识规则在ACL中的位置一般可以自定义也可以让系统自动分配。动作action允许permit或拒绝deny注意有些设备上叫“permit/deny”有些叫“allow/deny”本质一样。匹配条件协议类型、源IP、目的IP、源端口、目的端口、分片标记、MAC地址、VLAN编号等。时间范围需要配合时间段模板使用可以用在“上班时间禁止访问视频网站”这类场景。从数据包的角度看ACL检查的是一个“五元组”即源IP、目的IP、协议号、源端口、目的端口。除此之外扩展ACL还能检查TCP标志位比如SYN、ACK、ICMP消息类型等更细的字段。2.2 通配符掩码Wildcard Mask到底怎么算为什么容易踩坑很多人第一次接触ACL是被通配符掩码搞懵的。它和子网掩码长得很像但逻辑完全是两码事。子网掩码是连续的1和连续的0比如255.255.255.0通配符掩码则可以做到不连续比如0.0.0.254它用来表示“哪些位需要精确匹配哪些位可以忽略”。通配符掩码中0表示对应位必须精确匹配1表示对应位可以任意变化。举个例子如果要匹配192.168.1.0这个网段的所有主机子网掩码是255.255.255.0通配符掩码就是0.0.0.255。前面三个0代表前三组数字必须完全一致最后一个255代表最后一组从0到255都可以。太多人在这个地方踩坑了。我见过有人直接在ACL里写acl basic 2000 rule permit source 192.168.1.0 0.0.0.255这没问题。但还有人想把“192.168.1.0到192.168.1.127”这个范围匹配出来脑子一热写成了0.0.0.128这其实是错的。0.0.0.128在通配符掩码里表示“最后一组地址的最后一位必须为0”能匹配到的只有偶数IP奇数IP全部漏掉了。这就是搜索热词里那个“acl 有通配符 无法匹配掩码”的典型来源。正确理解通配符掩码的方法是把它转成二进制再逐位思考。0.0.0.128的二进制是00000000.00000000.00000000.10000000意味着最后八位里最高位必须为0其余七位随意于是能匹配的就是0和127之间的偶数段而不是你想象的那个网段。所以我个人的建议是碰到复杂的通配符掩码先在纸上把二进制展开确认匹配范围符合预期再敲到设备上。千万不要想当然地用十进制去心算。2.3 隐含拒绝Implicit Deny这条规则的真实含义所有ACL在最后都隐含了一条“拒绝所有”的规则这条规则你看不到但它的存在意味着如果数据包没有匹配到任何一条显式的permit规则它最终会被丢弃。这一点在配置ACL时特别关键。很多人配置ACL的时候只写了允许规则忘了考虑其他流量结果应用上去之后该通的流量不通了不该通的流量还在跑。比如你只想让192.168.1.0/24网段的机器访问服务器只写了rule permit source 192.168.1.0 0.0.0.255那么除了这个网段之外的所有源IP的流量都会被隐含拒绝规则挡住。实际操作中我有两个习惯一是配置ACL时先想清楚“我最终要允许哪些流量”再把它转化为permit规则确保这些规则全部覆盖二是利用display这条命令查看ACL规则时心里时刻记着有一条看不见的deny all在末尾。3. ACL的分类标准、扩展、二层、用户自定义ACL的分类方式在不同的厂商设备上略有差异但总体上可以按匹配能力的强弱和用途划成几类。3.1 标准ACLStandard ACL只能匹配源IP标准ACL的匹配条件比较单一基本上只看源IP地址。它的编号范围在华为设备上是2000到2999在思科设备上则是1到99。标准ACL的优点是配置简单、占用设备资源少缺点是太粗粒度。它无法区分目的IP也无法区分端口和协议所以应用场景受限通常是配合NAT、路由策略等使用而不是直接挂在接口上做精细过滤。比如“允许192.168.1.0/24网段的流量走特定线路”这种场景标准ACL就够用了。3.2 扩展ACLExtended ACL五元组全能选手扩展ACL可以匹配源IP、目的IP、协议类型、源端口、目的端口是日常使用最频繁的一类ACL。在华为设备上编号范围是3000到3999思科是100到199。用扩展ACL可以做非常精确的流量控制。举个例子你想禁止内网所有机器访问某个外网服务器的SSH端口TCP 22可以这么写acl number 3001 rule deny tcp source 192.168.0.0 0.0.255.255 destination 203.0.113.10 0 destination-port eq 22 rule permit ip注意最后那条rule permit ip它是必须的否则隐含拒绝会把所有流量都干掉。很多新手第一次配扩展ACL时都会漏掉这条。还有一个容易被忽略的操作扩展ACL在匹配TCP/UDP端口时还可以结合操作符比如eq等于、neq不等于、gt大于、lt小于、range范围。比如只想放行DNS查询流量可以写rule permit udp destination 8.8.8.8 0 destination-port eq 53这条规则只匹配发往8.8.8.8的UDP 53端口数据包其他DNS请求一概不管。3.3 二层ACLL2 ACL在三层之下做文章交换机的端口安全、VLAN隔离、MAC地址过滤都会用到二层ACL。它的匹配对象是MAC地址、VLAN编号、二层协议类型等而不是IP信息。我处理过一次网络环路问题排查了很久发现罪魁祸首是某一台办公电脑装了一款P2P软件不断发送二层广播帧把交换机CPU打满了。后来在交换机接入端口上配置了二层ACL把这个终端的特殊协议报文给拒了问题才彻底解决。二层ACL在配置时需要注意一点它只对二层转发流量生效如果报文走的是三层接口比如VLANIF接口那就要用三层ACL来过滤了。3.4 基于时间的ACL让规则分时生效有些需求是分时间段的比如“上班时间不允许访问购物网站午休和下班后可以”。这种情况就可以用基于时间的ACL。配置思路分两步先定义时间段再在ACL规则里引用这个时间段。华为设备上时间段模板的创建方式大致如下time-range worktime 08:00 to 18:00 working-day然后在ACL规则里引用acl number 3002 rule deny tcp destination-port eq 443 time-range worktime这样在周一至周五的8点到18点匹配443端口的TCP流量会被拒绝其余时间这条规则不生效。需要提醒的是设备的时间和NTP同步非常重要。如果设备时间不准基于时间的ACL就会在错误的时间点生效排查起来相当费劲。我建议在部署这类ACL之前先把设备的时区和NTP校准好。3.5 各类ACL的选型建议不是越高级越好选哪种ACL核心看两点管控粒度到什么程度设备硬件支持什么。只按源IP控制标准ACL就够了别杀鸡用牛刀。需要控制到端口和服务用扩展ACL配置上稍微复杂但能力全面。在交换机端口上做MAC/VLAN控制二层ACL特别是接入层安全场景。分时段控制基于时间的ACL先建时间范围再引规则。很多厂商规定一个接口在一个方向只能应用一个ACL所以要控制多个目标时需要把所有规则集中到一个ACL里或者合理规划ACL编号范围避免写不下的尴尬。4. 从配置到排障ACL在真实网络中的部署与问题排查这一节我把几种常见设备的配置方式、ACL的挂载位置、以及我在现场积累的排查经验一起讲。4.1 华为H3C设备上ACL的配置思路与实战命令华三H3C设备的ACL概念和华为类似但命令行细节上有差异。最常见的应用场景是把ACL绑定到接口或VLAN接口的入方向或出方向。比如在H3C交换机上要把一条ACL应用到某个端口基本命令如下acl basic 2000 rule permit source 192.168.10.0 0.0.0.255 # interface GigabitEthernet1/0/1 packet-filter 2000 inbound这里我把ACL 2000应用到了G1/0/1端口的入方向实现的效果是只允许192.168.10.0/24的流量从这个口进来其他源地址的报文全部被丢弃。如果你希望通过“出方向过滤”那就把inbound改成outbound。很多人在MSR系列路由器上问“怎么把ACL绑定到端口上”其实思路和交换机一致。不过路由器上一般是通过接口视图下引用包过滤策略完成acl number 3001 rule deny tcp source 192.168.1.0 0.0.0.255 destination any destination-port eq telnet rule permit ip # interface GigabitEthernet0/0 packet-filter 3001 inbound这样就把针对Telnet访问的控制策略应用到了公网侧入方向能有效拦截来自外部的Telnet探测。4.2 中兴交换机上ACL配置的异同点中兴交换机的配置方式和华为、H3C思路相近但在命令行上需要适应。有搜到“r10 5252交换机acl配置”这样的热词以中兴R10系列交换机为例ACL也分为基本ACL和扩展ACL配置大致是acl number 2001 rule 5 permit source 192.168.20.0 0.0.0.255 # interface gi0/1/1 packet-filter 2001 inbound中兴设备的细节和华为不完全一致建议以官方命令行手册为准。我这里要提醒的是不要让“命令不一样”阻挡你理解ACL本身因为底层的数据包处理逻辑是统一的你把华为的设备吃透了换到中兴、锐捷、思科真正需要适应的只是命令写法。4.3 ACL部署位置的讲究入方向优先还是出方向优先ACL能应用在两个方向入方向inbound和出方向outbound。入方向ACL在数据包进入接口时立即检查命中后直接丢弃。优点是可以尽早拦截非法流量省去后续路由处理的开销。出方向ACL在数据包经过路由决策、快要从接口发出去之前检查。出方向ACL只对在本设备转发的流量生效对本设备自身产生的流量不生效。选哪个方向没有绝对的标准但有一条原则很重要尽量在离攻击源或非法流量最近的地方做过滤这样能减少无效流量在网络内部的传播。比如防止外部扫描内网ACL应该挂在连接外部网络的接口的入方向防止内网用户访问某些外部服务ACL可以挂在核心交换机到出口路由器的链路上方向根据数据流向决定。还有一点需要特别说明接口的inbound方向ACL不会过滤设备自身发往该接口方向的流量outbound方向同样不会过滤本机主动发出的流量。这就引出另一个概念——本地流量过滤control-plane filtering需要单独配置。4.4 常见问题排查为什么ACL配了却没效果我把这几年被问到最多的ACL问题整理成一张表看到症状就可以对着查症状可能原因排查方法ACL配置后流量全部不通没有显式允许规则隐含拒绝生效display acl查看规则补上permit ipACL只有部分生效通配符掩码算错匹配范围不对把通配符转二进制核对规则顺序不对拒绝规则被前面允许规则覆盖设备和ACL是顺序匹配调整rule-id把更具体的规则放前面接口上应用了ACL但没效果ACL应用方向搞反检查inbound/outbound方向本机发出的流量不受ACL控制接口ACL不影响本机出方向流量需配置本地策略或控制平面过滤分时ACL不生效设备时间不对/NTP未同步核对系统时间配置NTP还有一个容易被带偏的问题ACL规则顺序。在实际调试时如果你看到规则列表里的permit规则在deny规则前面而且permit规则范围覆盖了本来打算拒绝的流量那效果肯定不符合预期。调整顺序的办法是把rule-id改成递增策略先写的规则编号更小匹配优先级更高。4.5 从网络ACL到Redis ACL不同领域里的同一种思路最近两年很多做后端开发的同事也在讨论Redis的ACL配置。Redis从6.0版本开始支持ACL作用是通过定义用户名、密码和命令权限限制客户端能执行的命令和访问的键。这和网络ACL的逻辑惊人地相似都是“先定义允许规则再按规则放行未匹配的默认拒绝”。有人问为什么Redis也要ACL理由很简单生产环境的Redis不能裸奔否则外部用户一旦连接上就能执行FLUSHALL或CONFIG这类危险命令。通过在配置文件中定义ACL规则可以精确限制某个应用只能读写某些key前缀只能运行GET/SET这类命令。比如定义user worker on read write ~cache:* strongpassword这个worker用户只能操作cache:前缀的键只拥有读和写权限无法执行管理类命令。你在看这套规则的时候应该能感知到和网络ACL是同一种思路细粒度授权默认拒绝最小权限。Redis 7加强了ACL的精细度支持按key前缀、按命令分类、按pub/sub频道做更细的控制。容器部署时还可以通过Docker的配置文件挂载方式把ACL规则注入容器。如果你用的是Docker跑Redis可以直接在命令行里加--aclfile参数指定ACL规则文件这样配置和镜像分离升级镜像时不会把权限规则冲掉。这个跨领域的类比我想表达的核心是ACL是一套通用的授权思想不只存在于网络设备上。学会网络ACL的思维方式对你理解其他系统的权限设计会有很大帮助。5. ACL应用场景盘点从防火墙到端口隔离再到精细化运营5.1 接口流量过滤最经典的“门卫”用法在路由器、交换机的接口上应用ACL对进出的流量做允许或拒绝这是ACL最基础的用法。举例来说某公司有一台服务器同时提供Web服务和SSH管理出于安全考虑他们希望只有办公网段的IP能访问SSH而Web服务对所有人开放。这个需求用扩展ACL一条规则就能解决acl number 3003 rule permit tcp source 192.168.0.0 0.0.255.255 destination-port eq 22 rule deny tcp destination-port eq 22 rule permit ip这段配置的意思是允许办公网段访问SSH的22端口其他来源访问22端口全部拒绝除此之外的流量全部放行。应用位置是服务器所在服务器的出口/入口方向具体看流量走向。这里的细节在于第三条rule permit ip。如果没有这条规则你不仅挡住了外部的SSH访问连Web服务的80/443端口也被隐含拒绝全部拦掉了。5.2 基于交换机端口的ACL隔离从接入层卡住风险搜到的热词里有“基于交换机端口的acl隔离”这也是实际项目中很常见的需求。比如公司里不同部门属于同一个VLAN但希望部门之间默认不通只在需要时可通。在二层交换机上最简单的端口隔离方式就是用端口隔离port-isolate但ACL可以做到更细可以只禁止某类流量跨部门允许其他流量互通。比如市场部和研发部在同一个三层网段但市场部不能访问研发部的数据库端口。配置思路是在连接市场部终端的交换机端口上应用ACL拒绝目的端口为数据库端口的流量然后放行其余。acl number 3004 rule deny tcp destination 10.10.20.0 0.0.0.255 destination-port eq 5432 rule permit ip然后在市场部接入端口上应用interface GigabitEthernet1/0/10 packet-filter 3004 inbound这样只有去往研发部数据库的访问被阻断其他跨部门流量仍然正常。这种方案比整段IP隔离更精细也更贴近真实业务需求。5.3 配合NAT、策略路由和QoSACL是很多高级功能的“匹配引擎”ACL不只是独立的安全工具它更多时候是作为“匹配条件”被其他功能引用。比如NAT地址转换里可以用ACL来定义哪些内网IP地址可以转换出口哪些不允许。很多“上不了网”的排障最后定位到就是NAT引用的ACL规则漏掉了某个网段。策略路由PBR里ACL用来匹配需要走特定链路的流量。比如让视频会议流量走专线其他流量走普通宽带先匹配的就是ACL。QoS里ACL可以帮助识别需要高优先级的流量比如VoIP电话的语音包然后给它们打上优先级标记。所以ACL虽然看起来简单却是这些高级功能正常工作的基础。你在排查网络“为什么某段流量没按策略走”的时候第一步往往不是查策略本身而是查被策略引用的ACL是否匹配正确。5.4 安全防护上的延伸用法防扫描、防伪造地址最后再分享一个ACL在安全上的延伸用法。出口路由器上可以配置ACL来阻止伪造内网源地址的报文也就是防源地址欺骗。这类报文在入方向接口上将被丢弃因为内网不应该出现来自外部的、源地址却是内网段的报文。配置示例acl number 3005 rule deny ip source 192.168.0.0 0.0.255.255 rule permit ip把这条ACL应用在连接外部网络的接口入方向可以阻止外部用户伪装成内网地址进入内部网络。这是最基础的入口防护手段之一成本低、规则简单却非常实用。还有针对ICMP的防护。有些内网用户喜欢用ping探测外网主机或者外部攻击者用大量ping探测存活主机。你可以通过ACL限制ICMP报文的数量或来源acl number 3006 rule deny icmp source any destination any fragment这里需要提醒的是ACL的分片匹配在真实网络中极易踩坑。有些数据包被分片后只有第一个分片携带四层端口信息后续分片只有IP头。如果你的ACL规则匹配的是TCP/UDP端口后续分片往往匹配不上可能被放行也可能被拒绝——具体行为要看厂商实现。我踩过的坑是某次给出口路由器配了DPT为443的阻断规则https下载大文件时发现后段数据还是能过。排查下来就是分片问题。后来我加了一条针对分片报文的处理规则才彻底解决。写在最后的几点实操体会ACL看起来是一个很“基础”的知识点但我在实际项目里发现真正能把ACL配置得又安全又不出问题的人其实不多。通用的问题无非这么几类通配符掩码算错、隐含拒绝没考虑、规则顺序混乱、应用方向搞反、分片考虑不周。这些都是可以通过经验积累避免的。我个人在实际操作中的习惯是任何ACL上设备之前先在文档或记事本里把需求翻译成规则列表标明“permit哪些、deny哪些、顺序怎么排、最后需不需要兜底permit”确认无误后再落配置。这个习惯帮我省了很多来回调试的时间。如果这篇文章能给你一个启发我希望是ACL不只是一串命令行而是一套流量治理的思路。学会它的本质换任何厂商设备、任何系统框架你都能快速上手。后续你在项目里遇到“怎么过滤这个流量”“怎么控制那个访问”的问题时不妨先想想ACL这套规则表的逻辑答案往往就会清晰很多。