访问控制列表ACL详解：作用、分类、通配符与配置实战

做网络运维或者后端开发的同学，大概率都见过“ACL”这个词。ACL 的全称是 Access Control List，中文一般叫访问控制列表。它看起来只是设备上的一段规则集合，但在整个网络安全体系中，它的位置非常基础又非常关键。无论是企业路由器隔离内网部门，还是防火墙限制外部访问，亦或是交换机控制 VLAN 之间的流量，ACL 都是最常用、最直接的手段之一。

这篇文章不打算只给一句“ACL 是用于权限控制的列表”这种空洞定义，而是围绕“访问控制列表 ACL，它的主要作用是什么”这个问题，把 ACL 的分类、匹配逻辑、通配符计算、配置实战、常见误区以及和其它领域 ACL 概念的边界完整梳理一遍。内容既照顾零基础读者，也包含能直接用于工作排错的经验总结。

1. 访问控制列表到底是什么，它解决什么问题

1.1 从一个最简单的场景说起

假设公司有两条网络：一条是办公网，网段是 192.168.10.0/24，员工电脑都在这里；另一条是核心数据区，网段是 192.168.20.0/24，里面放着财务系统和生产数据库。

按理说，办公网员工访问数据区里的业务系统是正常工作需要。但很快你会发现，如果不加限制，办公网里的所有终端都可以直接 SSH 登录数据区的服务器，甚至有人可能会误操作把生产数据下载到个人电脑上。这时候，你需要在网络上设置规则：只允许指定部门、指定端口访问数据区，其它流量一律拒绝。

这类需求如果只靠服务器自身权限做，管理成本很高，而且网络层很多扫描性、试探性流量根本到不了服务器就被放行了。更合理的做法是在网络转发路径上直接做一次过滤，符合规则的流量放行，不符合规则的流量丢弃。ACL 就是承载这些规则的核心载体。

1.2 ACL 的专业定义与本质

ACL 是一组有序规则的集合，每条规则包含匹配条件和执行动作。设备收到数据包后，会按照 ACL 中的规则顺序逐个匹配数据包的特征，一旦命中某条规则，就执行该规则对应的动作，比如 permit（允许）或 deny（拒绝）。

从本质上看，ACL 做的事情是包过滤和流量分类。它的匹配条件可以基于源 IP 地址、目的 IP 地址、源端口、目的端口、协议类型、时间段等。设备根据匹配结果决定：

• 是否允许数据包通过某个接口；
• 是否需要对该流量做地址转换；
• 是否为该流量分配 QoS 优先级；
• 是否允许用户通过 Telnet、SNMP 等协议管理设备本身。

所以 ACL 在真实项目中通常不是孤立存在的，它经常配合 NAT、路由策略、QoS、防火墙策略一起使用。这也是初学者经常困惑的地方：配置完 ACL 之后发现流量没有变化，原因是 ACL 可能只是定义了规则，还没有被调用到某些功能模块上。

1.3 ACL 的主要作用有哪些

访问控制列表的主要作用可以归纳为五个方面。

第一，网络安全防护。通过放行合法流量、拒绝非法流量，降低网络被扫描和攻击的风险。比如只允许运维网段 SSH 登录业务设备，可以在很大程度上减少暴力破解的来源。

第二，流量精细管控。可以对不同部门、不同用户组、不同应用协议的流量做差异化控制。比如市场部可以访问互联网，但只能访问特定站点端口；研发部可以访问代码服务器，但禁止访问财务系统。

第三，为 NAT、路由策略提供匹配依据。ACL 可以用来定义“哪些流量需要做 NAT”“哪些路由可以发布给邻居”以及“哪些路由可以被引入到路由协议中”。

第四，限制设备管理权限。通过在 VTY（虚拟终端线）上应用 ACL，可以限制哪些 IP 地址允许 Telnet、SSH 登录网络设备，避免管理面暴露给所有网段。

第五，实现基于时间的访问控制。高级 ACL 可以绑定时间段，比如工作日 9 点到 18 点允许访问，非工作时间自动拒绝，适合对业务系统做时间窗口管控。

2. 环境准备与前置概念

2.1 实验环境怎么搭

ACL 配置本身依赖网络设备或网络模拟软件。如果你手头有真实路由器、防火墙或者交换机，可以直接在上面做实验。如果没有真机，强烈建议用模拟器练习，因为它们成本低、可以随便折腾、配置错了能一键恢复。

常见的网络模拟环境有华为 eNSP（企业网络模拟平台）、H3C HCL（H3C 云实验室）、Cisco Packet Tracer 和 GNS3。其中 eNSP 适合练习华为 VRP 命令，Packet Tracer 适合思科初学者，GNS3 适合跑更接近真实 IOS 的场景。不同厂商的 ACL 命令有差异，但核心思想相同。

本文中配置示例以华为 VRP 风格为主，同时会解释思科风格的差异点。版本不需要刻意追求最新，2019 年之后的主流 VRP 版本命令表现基本一致，但具体特性需要以你实际设备为准。

2.2 必须理解的基础网络概念

在写 ACL 之前，有几个概念如果不弄懂，配置几乎必然出错。

源地址和目的地址。数据包从哪来、要去哪。ACL 做匹配时，如果是标准 ACL，一般只看源地址；如果是扩展 ACL，可以同时看源地址、目的地址和端口。

入方向和出方向。数据包进入接口的方向叫入方向，离开接口的方向叫出方向。ACL 应用在接口上时，必须明确是过滤进来的流量还是过滤出去的流量。很多人把方向搞反，明明想拦截外部访问内网服务器，却把 ACL 应用在了出方向。

通配符掩码。ACL 中表示地址范围不是用普通子网掩码，而是用反向掩码，也叫通配符掩码。0.0.0.255 表示匹配前 24 位，最后 8 位任意，也就是匹配一个 C 类网段。

默认行为。ACL 末尾有一条看不见的“隐含拒绝”规则，意思是如果数据包没有匹配到任何一条显式规则，最终结果就是被拒绝。所以配置 ACL 时，必须显式放行需要放行的流量，否则可能导致断网。

2.3 通配符掩码不要再死记硬背

通配符掩码的每一位和 IP 地址的每一位对应：

• 0 表示这一位必须精确匹配；
• 1 表示这一位不关心，可以任意。

所以 0.0.0.255 意味着前三组数字必须一致，最后一组随意，等价于匹配 192.168.10.x 这样的网段。0.0.255.255 表示匹配前两组数字，后两组随意，适合汇总大段地址。

如果需要匹配单个 IP，就写 0.0.0.0，同时也可以使用关键字 host。如果需要匹配所有地址，就写 255.255.255.255，也可以使用关键字 any。

很多人会把“反掩码”和子网掩码弄混。子网掩码是从左边连续 1 开始，反掩码则不要求连续，它的“1”和“0”只是表示每一位是否需要匹配。对于常规网段来说，反掩码等于 255.255.255.255 减去子网掩码。比如 255.255.255.0 子网对应的反掩码就是 0.0.0.255。

3. ACL 的分类与核心匹配逻辑

3.1 标准 ACL 与扩展 ACL

ACL 最常见的第一层分类是标准 ACL 和扩展 ACL。

标准 ACL 只基于源 IP 地址做匹配。它的优点是简单，缺点是控制粒度太粗。比如“拒绝 192.168.10.0/24 过来的所有流量”，这就是标准 ACL 的典型表达。它不关心目的地址，也不关心端口，所以通常建议应用在靠近目的地址的接口上，避免误伤其它路径上的流量。

扩展 ACL 可以组合源 IP、目的 IP、协议类型、源端口、目的端口等条件。比如“允许 192.168.10.0/24 网段的终端通过 TCP 访问 192.168.20.10 的 8080 端口”，这种需求只能通过扩展 ACL 实现。扩展 ACL 的匹配粒度更细，但对规则顺序也更敏感，配置错误容易导致部分应用不可用。

很多新人在看了标准 ACL 之后会觉得“这玩意儿好简单”，但到了扩展 ACL 就开始一头雾水。原因是扩展 ACL 的参数组合太多，不知道先写哪个、后写哪个。其实只要遵循一个习惯：先协议，再源地址，再目的地址，最后端口，就不容易乱。

3.2 命名 ACL 与编号 ACL

不同厂商支持用编号或者名字标识一条 ACL。

思科中，标准 ACL 编号范围常见为 1-99 或 1300-1999，扩展 ACL 编号范围为 100-199 或 2000-2699。华为 VRP 中，ACL 编号范围更宽，常见的是 2000-2999 表示基本 ACL，3000-3999 表示高级 ACL，4000-4999 表示二层 ACL，5000-5999 表示用户自定义 ACL。

命名 ACL 比编号 ACL 更直观。你可以给 ACL 取一个有意义的名字，比如 OFFICE_TO_DATA、DENY_TELNET，而不是记一串编号。实际项目中，尽量使用命名 ACL，因为它让配置的可读性和可维护性提高很多。

3.3 ACL 的匹配顺序和隐含拒绝

ACL 规则是按顺序逐条匹配的，这是 ACL 最容易踩坑的地方。

设备收到数据包后，从第一条规则开始比对，只要有一条规则命中，就立即执行该规则对应的动作，后续规则不再检查。因此规则顺序决定最终结果。比如你先写了一条拒绝所有流量到某个网段，再写了一条允许某个主机访问该网段，那这台主机的请求仍然被拒绝，因为它在第一条就被拦住了。

所以写 ACL 有一个铁律：特例在前，通用在后。先放行少数明确需要放行的流量，再拒绝或限制其余流量。如果列表末尾没有显式规则，设备默认执行拒绝。这意味着 ACL 是白名单模型还是黑名单模型，完全取决于你怎么组织规则。

3.4 入方向与出方向如何判断

“入”和“出”是 ACL 应用时绕不开的难题。判断方向有一个简单标准：以接口为观察点，看数据包是进入接口还是离开接口。

如果服务器部署在设备的某个接口下面，外部流量需要通过这个接口才能到达服务器，那么过滤外部访问服务器的流量，应该应用在接口的入方向。如果本地网络中的终端通过某个接口访问外部网络，希望限制终端能访问的外部目的地址，那通常应用在接口的出方向。

实际操作中，建议画一张简单拓扑图，把接口、服务器、终端、外部网络的位置标清楚，再判断方向。方向判断错误最常见的现象是：配置了 ACL 后，想拦截的流量照样通，或者没想拦截的流量反而断了。

4. 完整实战：在企业园区网中用 ACL 控制部门互访

4.1 案例背景与需求

假设企业有一台核心交换机，VLAN 10 是办公区 192.168.10.0/24，VLAN 20 是服务器区 192.168.20.0/24。现在提三个安全需求：

第一，办公区只允许访问服务器区 192.168.20.10 上的 HTTP 服务，目标是 80 端口和 8080 端口。

第二，服务器之间互访不受办公区 ACL 影响，保持默认互通。

第三，外部网段 192.168.30.0/24 不允许 Telnet 登录核心交换机，运维网段 192.168.100.0/24 例外。

这个案例覆盖了扩展 ACL 控制业务流量和应用 ACL 限制设备管理两个典型场景。

4.2 创建项目拓扑与地址规划

为了清晰起见，先列出实验规划：

设备角色：核心交换机，接口 GE0/0/1 接办公区，GE0/0/2 接服务器区。

办公区网段：192.168.10.0/24，网关为 192.168.10.1。

服务器区网段：192.168.20.0/24，网关为 192.168.20.1，Web 服务器地址为 192.168.20.10。

外部管理网段：192.168.100.0/24 和 192.168.30.0/24，用于测试远程管理限制。

这里不需要真实搭建三层网络也可以理解配置逻辑。如果你使用 eNSP，只需要创建一台交换机、两台 PC、一台服务器，划好 VLAN 并给 VLANIF 配置 IP 即可。命令如下：

system-view vlan batch 10 20 interface g0/0/1 port link-type access port default vlan 10 interface g0/0/2 port link-type access port default vlan 20 interface vlanif 10 ip address 192.168.10.1 255.255.255.0 interface vlanif 20 ip address 192.168.20.1 255.255.255.0

这段配置不是 ACL 本身，但没它业务没法通。它的作用是创建 VLAN 20，并给三层网关配置 IP。没有网关地址，ACL 后面的排错也无从谈起。

4.3 编写办公区到服务器区的访问控制规则

接下来创建高级 ACL，要求匹配从办公区到 Web 服务器的 HTTP 流量。在华为 VRP 中，高级 ACL 编号范围是 3000-3999。

acl name OFFICE_TO_SERVER rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 80 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 8080 rule 15 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255

这段规则需要解释：

rule 5 和 rule 10 是放行规则，分别允许 TCP 访问 192.168.20.10 的 80 和 8080 端口。destination 192.168.20.10 0 表示目的地址精确匹配为 192.168.20.10，后面的 0 就是通配符掩码。

rule 15 是拒绝规则，拒绝办公区访问整个服务器区网段。因为 ACL 默认隐含拒绝，这条规则也可以不写，但显式写出来更易读，也方便运维理解设计意图。

注意，规则顺序必须保持特例在前、通用在后。如果把 deny ip 写到前面，那么 permit 规则永远不会被执行，办公区访问 80 端口也会被拒绝。

4.4 将 ACL 应用到接口上

ACL 建好之后，必须应用到具体接口才生效。在这里，办公区访问服务器区，数据包从办公区进入交换机，再从服务器区接口出去。为了保证过滤的是从办公区进入交换机的流量，可以考虑应用在办公区接口的入方向。

interface g0/0/1 traffic-filter inbound acl name OFFICE_TO_SERVER

这段命令把名为 OFFICE_TO_SERVER 的 ACL 绑定到接口 g0/0/1 的入方向。流量进入交换机时，ACL 先做匹配，不符合规则的数据包直接丢弃。

你也可以把 ACL 应用在服务器区接口的出方向，效果可能类似，但出方向会多消耗一次转发后的判断，而且在某些场景下入方向更符合安全直觉。实际项目中选择哪个接口和方向，需要结合具体拓扑和业务路径一起分析。

4.5 限制远程登录设备管理端口

设备自身的管理也要做限制。通过 VTY 页面限制访问来源是比较常见的做法。华为交换机默认支持多条 VTY 线路，通常配置在 user-interface vty 0 4 下。

acl name MANAGE_TELNET rule 5 permit tcp source 192.168.100.0 0.0.0.255 destination-port eq 23 rule 10 deny tcp source 192.168.30.0 0.0.0.255 destination-port eq 23 user-interface vty 0 4 acl name MANAGE_TELNET inbound

配置后在 192.168.100.0/24 网段的终端可以 Telnet 登录设备，192.168.30.0/24 网段的终端会被拒绝，其它未匹配到的来源同样会被隐含拒绝。

如果你的设备开启了 SSH，不建议只限制 23 端口，最好同时限制 22 端口，并关闭不必要的 Telnet 服务。这是生产环境中很少被注意但又很重要的安全管理细节。

4.6 运行验证与常见排错命令

配置完成后，不能只看配置就算完成。还需要验证流量是否按预期走。

在思科设备上可以用 show access-lists 查看 ACL 命中计数，在华为设备上可以用 display acl all 查看规则，用 display traffic-filter applied-record 查看应用记录。

display acl all display traffic-filter applied-record

如果需要测试特定流量，可以用 ping 测试 ICMP 通断，用 telnet 命令从不同网段测试远程登录是否被拦截。如果 ACL 生效，被拒绝的源地址会超时或立即失败；被允许的源地址可以正常访问。

如果发现放行流量还是不通，重点排查顺序和方向。先用 display acl all 检查规则顺序，再确认应用接口和方向是否正确。很多情况下，问题不是 ACL 写错了，而是应用错接口了。

5. ACL 不只是网络设备的概念

5.1 Linux 文件系统中的 ACL

ACL 这个术语对后端开发来说也不陌生。Linux 文件系统权限默认只有 owner、group、others 三种角色，用 chmod 很难精细化授权。文件 ACL 机制允许为指定用户或用户组单独设置权限。

Linux 上查看测试文件的 ACL 权限可以使用 getfacl：

getfacl /data/project

给指定用户添加读写执行权限可以使用 setfacl：

setfacl -m u:zhangsan:rwx /data/project

这个命令的含义是为 zhangsan 用户设置对 /data/project 的 rwx 权限，不影响其它用户原有权限。这里同样体现 ACL 的核心思想：在默认权限模型之外，增加一条针对特定主体的规则，优先于默认权限判断。

5.2 数据库和中间件中的 ACL 思想

MySQL 中的用户权限体系也有 ACL 的影子。MySQL 的系统表 mysql.user、mysql.db、mysql.tables_priv 保存了不同层级的权限记录，MySQL 在连接校验时依次匹配用户、库、表、列，这和网络 ACL 的逐条匹配思想是一致的。

PostgreSQL、Redis、Kafka 等中间件也都提供基于 ACL 或类似授权模型的接入控制能力。区别在于，网络 ACL 匹配的是 IP 和端口，数据库 ACL 匹配的是用户、对象和操作类型。

理解了这些领域之后，你会发现 ACL 不是一个单纯的网络术语，而是一种通用的授权决策思想：主体是否允许对客体执行某种操作，通过一组有序规则来判断。

5.3 防止概念混淆

有些资料把 ACL 与防火墙策略、安全组、IAM 策略混在一起说。它们确实有相似之处，但重点不同。

防火墙策略通常是有状态的安全控制，支持应用层识别、会话状态检查和入侵防御联动；网络 ACL 更多是无状态包过滤，匹配能力集中在网络层和传输层。云平台安全组也类似 ACL，但很多云安全组都是隐式放行加显式拒绝的逻辑，这和传统设备的隐式拒绝是有区别的。

实际使用时要搞清楚设备的模型。比如华为、思科网络设备的 ACL 末尾是隐含拒绝，如果不显式放行就会断网；而云安全组默认规则是放行，只需添加拒绝规则。默认行为不一样，配置策略的思路就得跟着调整。

6. 常见问题与排查思路

6.1 配置完 ACL 后网络直接断开

这是最常见的故障。原因一般是忘记放行管理流量，或者 ACL 被应用到远程管理接口的入方向，把 SSH 管理流量也过滤掉了。

排查步骤：

• 先确认管理终端 IP 是否在 ACL 放行规则中。
• 再确认 ACL 应用接口是哪个，方向是哪个。
• 如果远程已经断连，考虑通过 console 口登录设备，撤销 ACL 或添加放行规则。
• 生产环境变更前，一定要备份配置，并确保 console 口可用。

6.2 ACL 规则顺序导致放行规则不生效

前面已经提到，ACL 是顺序匹配，一个包命中了前面的拒绝规则，就不会再检查后面的放行规则。遇到“明明有 permit 规则但仍然丢包”的现场，最优先检查规则顺序，而不是怀疑设备特性。

display acl 3000

查看规则列表，确认 permit 规则是否在 deny 规则前面。如果顺序不对，可以用 rule 命令的编号重新调整，或者删除整条 ACL 重新配置。调整 ACL 规则编号是否支持，取决于具体厂商和版本，生产环境建议先在测试设备上验证。

6.3 方向写反导致过滤无效

现象是 ACL 已经应用到接口，但流量没被过滤。判断方向时，最简单的方法是站在接口的角度看流量流动。如果无法确定，可以在实验环境里故意配置一条拒绝所有流量的 ACL，然后观察哪些方向断了，从而快速验证方向理解是否正确。

6.4 通配符掩码写错导致匹配范围不准

把 0.0.0.255 写成 255.255.255.0，是新手常犯的写法错误。这里多说一句，不同厂商对通配符掩码的检查严格程度不同。华为 VRP 在大多数场景下能识别反掩码，但你不能用普通子网掩码去代替。建议配置前先想清楚要匹配的网段，再计算反掩码。

常用的匹配总结如下：

6.5 ACL 配置了但 NAT 不生效

ACL 除了过滤流量，还经常被 NAT 调用。如果你用 ACL 定义了需要转换的源地址，但 NAT 不生效，请检查 ACL 中是否把 NAT 应答流量或者目的地址匹配条件写得太严格。NAT 匹配通常只关心源地址，扩展 ACL 中带有目的地址限制时，可能导致转换命不中。

排查思路是分离变量：先用 display acl 看计数是否增长，再确认 NAT 调用的是哪个 ACL，最后简化 ACL 规则测试。

7. 最佳实践与工程建议

7.1 先设计白名单思路，再写规则

网络安全中，白名单模型的整体风险通常低于黑名单模型。默认拒绝，只放行明确需要的流量，虽然配置量更大，但安全边界更清晰。尤其是面对服务器区和核心数据区时，建议优先使用白名单方式。

7.2 管理面和控制面单独隔离

设备自身的管理协议，如 SSH、SNMP、NTP，建议通过独立 ACL 控制来源地址。不要把所有控制逻辑混在一张大 ACL 里，否则后期排查时很难定位问题。运维网段单独做管理 ACL，是生产环境中非常实用的一条经验。

7.3 日志与监控要跟上

ACL 虽然能过滤流量，但它不是防火墙，对应用层攻击的检测能力有限。生产网络建议把 ACL 命中计数纳入监控，可记录日志，方便判断是否有异常扫描流量。专用防火墙和 IDS/IPS 通常更适合做深层次安全检测。

7.4 变更管理比配置本身更重要

ACL 一旦影响线上流量，风险等级通常不低。变更前，先备份当前配置；变更时，在测试环境完整验证；变更后，记录版本和回退步骤。不要因为一条 ACL 规则看起来简单，就直接在生产设备上敲命令，尤其是涉及拒绝关键业务端口的时候。

7.5 定期审计和清理

随着时间推移，网络里的 ACL 会越来越多，很多规则可能早已失去意义。建议每半年或一年做一次 ACL 审计：检查不存在的主机、重复规则、被隐含拒绝覆盖的规则，清理无用配置项，并同步更新网络拓扑文档。

8. 总结

本次围绕“访问控制列表 ACL，它的主要作用是什么”做了完整拆解。从 ACL 的概念、作用、分类，到通配符掩码、顺序匹配、方向判断，再到华为 VRP 环境下的实战配置，覆盖了学习 ACL 最关键的几个难点。同时也说明了 ACL 思想在 Linux 文件权限、数据库授权中的延展应用，避免读者只看网络设备场景而误解 ACL 只是路由器命令。

在实际项目里，遇到流量不通或安全策略不生效时，不妨先按这个顺序排查：ACL 是否被正确调用？规则顺序是否正确？方向是否搞反？通配符掩码是否算错？只要这四个点都确认无误，大部分 ACL 问题都能定位。

如果你正准备系统学习网络技术，建议在模拟器里把标准 ACL、扩展 ACL、接口应用、VTY 管理限制这几个场景各做一遍，再尝试把 ACL 与 NAT、策略路由结合起来练习。ACL 是一个必须靠动手试错才能熟练掌握的知识点，只有真正输过命令、看过命中计数、调过错，才能体会它的边界在哪里。希望这篇文章能帮你少踩几个坑。