到今天为止，我的网络学习日志已经写到第26篇了。前面几篇一直在折腾路由协议、接口调试和基础排障，这篇终于轮到 ACL。ACL 全称 Access Control List，翻译过来就是访问控制列表，网工圈子里基本都直接叫“ACL”。它不是某个厂商的私有功能，而是几乎所有网络设备都支持的通用机制，主要用来做流量过滤、访问限制、远程管理白名单，甚至还能配合策略路由、QoS 使用。这篇文章我会从原理讲到配置，再讲配置过程中最容易踩的坑，最后聊一下这个思路在 Linux、Redis、对象存储里的变体，把这些内容串起来之后，你会发现 ACL 远比你想象的更通用。
我在刚接触网络设备时，觉得 ACL 背完编号范围就完事了：标准 ACL 是 2000 到 2999，高级 ACL 是 3000 到 3999，二层 ACL 是 4000 到 4999。但真正到了设备上一配，发现问题一个接一个：通配符掩码写反、规则顺序不对、接口方向选错、隐式拒绝导致断网，这些我都踩过。这篇文章不是念概念，而是把原理、配置、排障经验一起写清楚，适合刚入行的网工、准备认证考试的同学，还有那些做了几年运维但没系统性摸过 ACL 的人。
1. ACL到底是什么，解决什么问题
1.1 用小区门禁来理解ACL
ACL 的本质是一张带顺序的名单。你可以把它想象成小区门口保安手里的门禁表，上面写着：几号楼几单元的业主可以进，外卖车辆某个时间段不能进，访客需要登记后才能进。网络设备收到报文后，也会按照这张“名单”逐条核对。名单上写了 permit，就放行；写了 deny，就丢弃；如果报文条件哪一条都不匹配，那最终结果就是默认拒绝。
这个“默认拒绝”非常关键。很多人配置 ACL 时以为只影响自己写的那几条规则，实际上只要把这个 ACL 绑到接口上，而规则里又没有最后兜底的 permit，那所有没被明确允许的流量都会被丢弃。用门禁来类比就是：保安手里的名单只写了几个放行的名字，那么名单之外的所有人都进不了门。理解这一点，你后面配置的时候就不会犯“一绑ACL就断网”的错。
1.2 ACL在网络设备中处于什么位置
ACL 不是一个独立协议，它本身不参与路由计算，也不像 OSPF、BGP 那样有邻居关系。它只是一张规则表，被接口、VLAN、VTY、QoS 分类等模块调用。设备收到报文后，如果发现接口上绑定了 ACL，就会进入匹配流程。匹配通过则继续转发或交给后续处理，匹配失败则直接丢弃。
这里有个容易忽略的细节：ACL 通常只过滤“穿越设备”的流量，也就是从一个接口进、再从另一个接口出的流量。对于设备自身发起的流量，比如路由器自己 ping 出去的探测报文，或者自己主动发起的 SSH 连接，你在普通接口上绑 ACL 不一定管得住。要限制远程管理，得把 ACL 绑到 VTY 用户界面，或者用控制平面策略去做。这个细节在实际项目中很常见，我在后面配置部分也会讲。
1.3 常见ACL分类和编号范围
不同厂商的 ACL 分类基本一致，只是在编号范围和关键字上有细微差异。以华三（H3C）设备为例，常见的 ACL 类型如下表。
| ACL类型 | 编号范围 | 匹配依据 | 典型场景 |
|---|---|---|---|
| 标准 ACL | 2000-2999 | 源 IP 地址 | 控制“哪个网段能进来” |
| 高级 ACL | 3000-3999 | 源/目的 IP、协议、端口、TCP 标志、ICMP 类型 | 业务精细化访问控制 |
| 二层 ACL | 4000-4999 | 源/目的 MAC、VLAN、802.1p 优先级 | 局域网内部过滤 |
| IPv6 ACL | 2000-2999 等 | IPv6 地址和高级匹配项 | 下一代网络环境 |
标准 ACL 的特点是简单粗暴，只看源 IP。比如你想拒绝某个内网网段访问公司服务器，那标准 ACL 就够了。但如果你希望“只拒绝某个网段访问服务器的 Web 服务，但允许它访问 SSH 服务”，标准 ACL 就没法做到，必须用高级 ACL 去同时匹配目的 IP 和端口。二层 ACL 在交换机上用得比较多，比如按终端 MAC 地址做准入控制，防止有人乱改 IP 接入内网。IPv6 ACL 的匹配能力和 IPv4 的高级 ACL 类似，只是地址格式和命令写法不同。
2. ACL的工作原理：报文的匹配过程
2.1 从匹配到执行：ACL的工作流程
ACL 的匹配流程可以概括为“顺序匹配，命中即停”。设备从第一条规则开始，拿当前报文特征和规则条件做比对，只要有一条规则匹配，就立刻执行这条规则对应的动作，也就是 permit 或者 deny，后面所有规则都不再看。
为什么要这样设计？一方面是为了性能，硬件转发的流水线希望匹配过程尽量短，不能每条报文都翻完整张 ACL 表；另一方面是让规则结果可预期。工程师只要按照“先特殊、后一般”的顺序编排规则，就能精确控制哪些流量先命中。整个过程很像站在一排安检通道前，第一个通道放行所有带登机牌的人，第二个通道拒绝携带液体的人，只要被第一个通道拦下，就不会再走到第二个通道。
如果整个规则表从头到尾都没有匹配项，设备会执行一个看不见的“隐式拒绝”。换句话说，ACL 的默认动作是 deny all。这也是为什么很多人在配置完 ACL 之后发现网络不通，十有八九是没有加一条兜底 permit。
2.2 通配符掩码：最容易被用错的一个点
ACL 在做地址匹配时，使用的是通配符掩码，也有人叫反掩码。它和子网掩码长得像，但含义正好相反。子网掩码里的“1”表示网络位，必须匹配；“0”表示主机位，可以不同。通配符掩码正好反过来，“0”表示这一位必须精确匹配，“1”表示这一位不需要关心。
以最常见的网段为例：配置规则“source 192.168.1.0 0.0.0.255”，意思是前三个数字 192、168、1 必须完全一致，最后一个数字可以是 0 到 255 之间的任意值。这正好等价于匹配 192.168.1.0/24 这个网段。计算通配符掩码有一个很简单的办法：把子网掩码的每一段都用 255 去减一下。比如 255.255.255.0 对应的通配符掩码是 0.0.0.255，255.255.255.240 对应的通配符掩码是 0.0.0.15。
| 目标范围 | 子网掩码 | 通配符掩码 |
|---|---|---|
| 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 |
| 192.168.1.0/28 | 255.255.255.240 | 0.0.0.15 |
| 单个主机 192.168.1.10 | 255.255.255.255 | 0.0.0.0 |
| 所有地址 | 0.0.0.0 | 255.255.255.255 |
我见过很多人在配置时报错或匹配不到预期地址，就是因为把子网掩码直接当成了通配符掩码。比如你想匹配 192.168.1.0/24，结果写了“source 192.168.1.0 255.255.255.0”。设备不会报语法错误，但它会按通配符的规则去解释：前 24 位被置为“1”，完全不关心，最后 8 位被置为“0”，必须等于 0。最后得到的匹配范围其实是“任意 IP 地址且最后一位是 0”，跟你想要的 192.168.1.x 差了十万八千里。
2.3 规则顺序和默认动作
ACL 里的每一条规则都带一个规则编号，设备默认按编号从小到大依次匹配。华三设备上，如果你不手动指定编号，系统会自动分配，通常起始编号是 0，步长是 5，也就是先产生 0、5、10、15 这样的编号。如果你希望某条规则排到更前面，可以手动指定一个更小的编号，比如 rule 1、rule 2，这些规则会自动插入到合适的位置。
规则顺序对最终效果影响极大。同一个 ACL 里，如果前面先写了一条“deny ip”把所有流量全部拒绝，那么后面写的任何“permit tcp”规则都不会生效，因为报文在第一条就被丢掉了。正确的编排习惯一般是：先放行最需要的、最具体的流量，再拒绝不想要的流量，最后再加一条宽松的兜底规则。这有点像写防火墙策略，先精确放行，再拒绝例外，最后做默认策略。
2.4 标准ACL和高级ACL的匹配能力
标准 ACL 的匹配能力非常有限，它只关心源 IP 地址，所以只能做粗粒度的控制。使用场景一般是“这个网段能不能访问某个区域”这种简单需求。但它的优点也很明显，规则少、性能开销小、容易理解，适合在核心链路入口处先做一层粗过滤。
高级 ACL 的匹配项丰富得多：源 IP、目的 IP、协议类型（TCP、UDP、ICMP、IP 等）、源端口、目的端口、TCP 标志位、ICMP 类型。这意味着你可以写出类似“拒绝 192.168.20.0/24 访问服务器 192.168.100.10 的 TCP 80 端口，但允许它 ping 通服务器”这样的精确规则。这也是生产环境中用得最多的 ACL 类型。规则越精细，对转发性能的要求通常也越高，但现代设备基本都能扛得住，关键是规则数量不要膨胀到失控。
3. 基础配置实操：H3C MSR路由器上的ACL实验
3.1 一个具体的需求场景
纸上谈兵没意思，我直接拿一个实际场景来讲。假设我手里有一台 H3C MSR20-20 路由器，GigabitEthernet0/0 接口连接内部办公网，GigabitEthernet0/1 接口连接服务器区。内部办公网有两个网段：研发网段 192.168.10.0/24 和测试网段 192.168.20.0/24。服务器区有一台 Web 服务器，地址是 192.168.100.10。
现在需求是：
- 研发网段可以正常访问 Web 服务器的 80 端口。
- 测试网段不能访问 Web 服务器的 80 端口。
- 测试网段可以 ping 通 Web 服务器。
- 其他流量按照正常路由转发，不做额外限制。
这个需求用标准 ACL 无法实现，因为必须要匹配目的地址和目的端口，所以得用高级 ACL，编号选 3000。
3.2 标准ACL配置：最简单的过滤
虽然上面的需求要用高级 ACL，但标准 ACL 依然是入门必学的配置。它适合做粗粒度过滤。比如我只想拒绝 192.168.20.0/24 访问任何服务器，那可以用标准 ACL 2000。
system-view acl basic 2000 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny source 192.168.20.0 0.0.0.255 rule 15 permit quit这里有个细节要注意：我最后加了一条rule 15 permit，没有任何源地址限制，等价于“放行其他所有流量”。如果不加这一条，ACL 的默认行为会把所有未匹配的流量全部丢掉，到时候不仅上面两个网段受影响，其他所有业务都会断。很多人第一次配标准 ACL 时只写了 deny，结果整个网络瘫痪，就是这个原因。
配置完成后，可以用display acl 2000查看规则。如果规则命中计数在增长，说明流量确实被匹配到了；如果计数不增长，就要思考是不是报文压根没走到这个 ACL，或者方向选错了。
3.3 高级ACL配置：精确到端口
回到刚才的需求，我需要在系统视图下创建一个高级 ACL，编号 3000。
system-view acl advanced 3000 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.100.10 0 destination-port eq 80 rule 10 deny tcp source 192.168.20.0 0.0.0.255 destination 192.168.100.10 0 destination-port eq 80 rule 15 permit icmp source 192.168.20.0 0.0.0.255 destination 192.168.100.10 0 rule 20 permit ip quit逐条解释一下。rule 5表示：允许源地址是 192.168.10.0/24 的 TCP 报文访问 192.168.100.10 的 80 端口。这里destination 192.168.100.10 0表示目的地址精确匹配单台主机，destination-port eq 80表示目的端口等于 80。rule 10的作用正好相反，把测试网段访问 Web 服务的流量拒绝掉。rule 15是允许测试网段 ping Web 服务器，因为 ping 用的协议是 ICMP，为什么能 ping 通服务器而不受影响。最后我写了rule 20 permit ip，把其他所有 IPv4 流量都放行，避免隐式拒绝把自己网断掉。
这条高级 ACL 已经能覆盖需求里的前三点。如果你希望更严格，可以把最后一条去掉，这样除研发网段访问 Web 服务、测试网段 ping 服务器之外，所有流量都会被拒绝。但在没有充分把握之前，建议先保留兜底 permit，观察业务正常后再收紧。
3.4 把ACL绑定到接口：inbound和outbound选择
ACL 创建好之后不会自动起作用，必须绑定到接口上。以华三设备的现代版本为例，绑定命令是traffic-filter。我选择的绑定位置是内网入口的 GigabitEthernet0/0，方向是 inbound。
interface GigabitEthernet0/0 traffic-filter inbound acl 3000 quit这样配置的含义是：所有从 GigabitEthernet0/0 进入路由器的报文，都要先经过 ACL 3000 的匹配。如果源地址是 192.168.20.0/24，目的端口是 80，就直接被丢弃。之所以选择 inbound，是因为在靠近发起方的入接口做过滤更高效，报文刚进来就被处理掉，不会白白占用到服务器侧接口的带宽。
如果你用的是老版本的 MSR 设备，接口下可能不是traffic-filter，而是firewall packet-filter之类的命令。可以在接口视图下打一个问号看支持哪些命令，不同平台差异确实存在。配置完成后，用display traffic-filter applied record可以确认 ACL 是否成功下发。
关于方向的判断，可以这样记：站在你绑定的这个接口上，看数据包的流动方向。数据包从外部进入接口，对应 inbound；数据包从设备内部发出接口，对应 outbound。如果方向选错了，就会出现“为什么我绑了 ACL 一点反应都没有”或者“为什么服务器无法主动访问外网”这种让人摸不着头脑的问题。
3.5 管理接口场景和IPv6场景的ACL配置
除了普通数据口，ACL 还可以绑定到 VTY 用户界面，用来限制谁可以远程登录设备。这个在实际运维中非常实用。比如我只允许 192.168.10.0/24 这个管理网段通过 Telnet 或 SSH 登录路由器，其他地址统统拒绝，可以这样配：
acl basic 2001 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny quit user-interface vty 0 4 acl 2001 inbound quit这里的user-interface vty 0 4表示虚拟终端线路，SSH、Telnet 登录都会落到这些线路上面。绑定 ACL 后，只有源地址匹配的请求才能建立远程会话。这个操作比直接在接口上 ACL 更精准，因为它控制的是“管理面”，而不是数据转发面。
IPv6 环境下，ACL 的结构和 IPv4 类似，但命令关键字不同。华三设备上要使用acl ipv6 basic或者acl ipv6 advanced来创建 IPv6 ACL。配置示例：
acl ipv6 basic 2000 rule 5 permit source 2001:db8:1::/64 rule 10 deny quit interface GigabitEthernet0/0 traffic-filter inbound ipv6 acl 2000 quit注意接口下绑定 IPv6 ACL 时要多写一个 ipv6 关键字，否则设备会把acl 2000当成 IPv4 ACL 去匹配 IPv4 报文，IPv6 流量就不会被过滤。这个坑我在学习 IPv6 安全实验时踩过，排查了半天才发现是绑定命令里少了 ipv6 关键字。
4. ACL配置中的常见问题与排查
4.1 通配符掩码错误：为什么规则总匹配不上
热词里有一条特别典型，叫“acl 有通配符 无法匹配掩码”。很多新手在配 ACL 时，会把高级路由里的子网掩码习惯直接带过来。比如想匹配 192.168.1.0/24，在路由协议里写192.168.1.0 255.255.255.0没问题，但 ACL 里这样写就会出问题。
前面已经说过，ACL 里255.255.255.0会被当成通配符掩码来解析，它的含义是“前 24 位不关心，最后 8 位必须等于 0”，于是这条规则实际上匹配的是任意地址最后一位为 0 的报文，而不是 192.168.1.x。设备不会报错，但流量就是匹配不上，或者匹配到了完全出乎意料的流量。
排查方法其实很简单，用display acl all查看规则内容，看看“source”后面的反掩码是不是你预期的0.0.0.255。如果显示的是255.255.255.0，就说明写反了。我记得自己在一次割接中就是因为这个低级错误，导致测试网段一直能访问服务器，最后把 ACL 规则调出来一看，source 掩码写成了子网掩码，改过来之后一切正常。
4.2 规则顺序问题：先deny后permit的坑
ACL 在执行时是顺序匹配、命中即停。如果你写了一条大范围的 deny，放在所有 permit 前面，那么后续 permit 永远没有机会执行。举个极端例子：
acl advanced 3000 rule 5 deny ip rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.100.10 0 destination-port eq 80这条规则会导致所有 IP 报文在rule 5直接被丢弃，rule 10形同虚设。从逻辑上看，rule 10是想放行研发网段访问 Web 服务器，但因为它排在 deny 后面，根本不会被执行到。
解决办法有两个：一是调整顺序，把具体放行规则放到前面；二是临时插入一条编号在中间的规则，比如rule 8，让它排在rule 5和rule 10之间。调整之后一定要用display acl 3000确认规则的实际顺序，不要只看命令行输入顺序。规则上如果带有计数器，还可以通过匹配计数的增长判断流量到底命中了哪一条。
4.3 方向搞反：inbound和outbound的区分
ACL 绑到接口上时，方向选错是非常常见的故障来源。很多人看到内网要访问服务器，就顺手把 ACL 绑到服务器接口上，结果方向选成了 inbound。这个方向处理的是“从服务器进入路由器的流量”，也就是服务器主动发往外部的流量，和你本来想控制的“内网到服务器”方向正好相反。
正确的做法是先认清数据流向。内网 PC 访问服务器，数据包从 PC 出发，经过路由器连接内网的接口进入路由器，再从连接服务器的接口出去。你可以把 ACL 绑在内网接口的 inbound 方向，也可以绑在服务器接口的 outbound 方向。两个方向的效果在某些场景下可能不完全一样，因为 outbound 方向的过滤发生在路由查询之后，如果你还想做策略路由等操作，要提前考虑规则的生效顺序。
我在实验环境里通常会绑在靠近源端的入方向，这样过滤效率更高，也不会影响服务器侧接口上可能存在的其他策略。排查方向问题时，用display traffic-filter applied record查看绑定情况，再结合display acl的计数就能定位。
4.4 隐式拒绝：一配ACL就断网
这个话题值得单独拿出来说。ACL 默认有一条看不见的规则，那就是“所有未匹配流量全部拒绝”。很多人只写了 deny 规则，没有写兜底 permit，结果一绑接口，整个网络马上断掉。
我自己的习惯是：配置 ACL 之前，先画一张表，把要放行的流量、要拒绝的流量都列出来，最后确认需不需要放行其他流量。如果不需要放行其他流量，那也要意识到“默认拒绝”就是你想要的效果；如果需要放行，那就必须显式加一条 permit 规则。远程管理设备时尤其要小心，如果管理地址不在 permit 规则里，ACL 一旦绑上接口，你可能瞬间失去设备访问权限。这时候只能靠 console 口重新登录，或者等待设备上的管理保护机制生效。
4.5 命令速查表：排错时拿来就用
下面这张表是我在实际排障中会用到的高频命令，你可以保存下来做参考。
| 命令 | 作用 | 使用建议 |
|---|---|---|
| display acl all | 查看所有 ACL 规则和命中计数 | 先看规则顺序，再看计数增长 |
| display acl 3000 | 查看指定 ACL | 确认通配符掩码、端口是否写对 |
| display traffic-filter applied record | 查看 ACL 在接口上的下发情况 | 解决“绑了没生效”问题 |
| display packet-filter | 查看接口包过滤状态 | 老版本设备上用得多 |
| reset acl counter 3000 | 清空 ACL 计数 | 重新验证前先清零，避免被旧数据误导 |
| display ip interface brief | 查看接口 IP 和状态 | 确认你要绑的接口名字是否写错 |
排障的顺序一般是：先确认 ACL 是否创建成功，再确认 ACL 是否绑定到了正确的接口和方向，最后用命中计数验证。只要这三步查完，90% 的问题都能定位出来。
5. ACL思想在网络之外的延伸
5.1 Linux中的文件ACL：setfacl与getfacl
ACL 的思想不止存在于网络设备。Linux 文件系统里也有一套访问控制列表，用来弥补传统 ugo 权限的不足。大家都知道 Linux 文件权限分属主、属组和其他用户三类，但如果想给某个特定用户单独授权，又不希望把他加进某个组里，传统权限就很麻烦。这时候就要用文件 ACL。
比如我有个目录/data，属主是 root，属组是 root，其他用户没有任何权限。现在要让用户 zhangsan 能读写这个目录，可以这样操作：
setfacl -m u:zhangsan:rw /data getfacl /data执行完之后，ls -l /data的结果最后会出现一个+号，表示这个目录上存在 ACL 条目。getfacl可以看到具体权限明细。这套机制和网络 ACL 的“在通用权限之外再单独加一条规则”思路几乎一模一样，理解了网络 ACL，再学 Linux ACL 会非常快。
5.2 Redis里的ACL：账号与命令权限控制
Redis 从 6.0 开始引入 ACL 功能，到了 Redis 7 已经非常成熟。它允许你创建多个账号，给每个账号分配不同的密码、可执行的命令和可访问的 key 前缀。比如我创建一个应用账号，只允许读写app:*前缀的 key，只能执行 get、set、ttl 这类命令，可以这样写：
ACL SETUSER appuser on >appPass123 ~app:* +get +set +ttl如果是在 Docker 里部署 Redis 7，可以通过挂载 redis.conf 和独立的 aclfile 来管理账号，避免每次容器重启后配置丢失。简单做法是在 redis.conf 里设置aclfile /etc/redis/users.acl，然后把账号规则写入 users.acl，再通过 volume 挂载进去。这套做法的价值在于：即使同一个 Redis 实例被多个业务共用，也能把数据可见性和命令权限隔离开来。
5.3 对象存储OSS的ACL报错处理
对象存储里的 ACL 概念也一样。资源有私有、公共读、公共读写等几种权限级别。有时候上传文件会报错，提示AccessDenied: Put Object ACL is not allowed。这个报错并不是说上传这个动作本身被拒绝，而是指你试图修改 Object 的 ACL，但当前 Bucket 的权限策略或账号权限不允许这样做。
遇到这个报错时，先不要急着改代码。第一步打开 Bucket 的权限设置，看看是不是关闭了 Object 级别的 ACL 修改；第二步检查使用的子账号或临时凭证是否被授予了PutObjectAcl权限，比如 OSS 的oss:PutObjectAcl。如果业务上根本不需要修改文件 ACL，那就在上传请求里去掉了 ACL 相关参数，问题一般就解决了。
ACL 这个东西，如果只把它当成命令来背，很容易越学越乱。我自己在实际项目里养成的一个习惯是：不管在哪种设备或系统上操作，动手前都会把“谁、对什么资源、做什么动作、允许还是拒绝”先列成表格，再转换成对应的规则。网络设备上的 ACL、Linux 里的 setfacl、Redis 里的 ACL 账号，本质上都是同一套思路。把这层底层逻辑想通了，换到任何平台都只是换一种命令行写法而已。这篇日志写到这，我也该去把实验环境里的规则再清理一遍了。
