Cisco Packet Tracer里的标准ACL（访问控制列表）配置，是每个学网络的人绕不过去的坎。很多人刚开始接触ACL时，被一堆参数和规则搞得云里雾里，其实这东西远没有想象中复杂。简单来说，ACL就是路由器或交换机上的一张“流量白名单/黑名单”，我们通过配置规则来告诉设备：哪些数据包能过来，哪些不能过来。而标准ACL（Standard ACL）作为ACL家族里最基础的一员，它的特点就一句话——只认源地址，不管目标是谁。

这篇文章我打算用Cisco Packet Tracer（思科官方出的免费模拟器）完整演示一遍标准ACL的配置思路，从拓扑设计、通配符掩码计算到实际敲命令，最后再到验证排错，全流程走一遍。不管你是准备考CCNA，还是学校里的网络课正在讲这里，又或者工作中突然要碰思科设备却心里没底，这篇文章都能给你一套可以直接照着抄作业的实操方案。

先说清楚一个前提：我们讨论的是标准ACL（编号范围1-99或1300-1999），它只能基于源IP地址做允许或拒绝。它的优点是配置简单、CPU开销小，缺点是粒度太粗，无法精确到具体端口或目标地址。所以在真实生产环境中，标准ACL通常用在“阻止来自某个网段的流量”这种粗粒度场景，或者配合扩展ACL做策略配套。需要精确匹配目标IP和端口的地方，还得靠扩展ACL。这个定位先明确好，后面配置时你才能选对工具。

1. 实验准备与拓扑设计思路

1.1 为什么用Packet Tracer来学ACL

动手练网络配置，思科模拟器是首选，而Packet Tracer又是这里面最友好的一款。它不需要你有一台真实的路由器或者交换机，安装包也只有几百兆，打开就能拖设备、连线、敲命令，完美复刻思科IOS的命令行操作方式。虽然它和真实的GNS3（模拟完整IOS镜像）相比功能简化了一些，但ACL这种基础配置，它的模拟精度已经足够还原真实设备的行为逻辑了。

我的建议是：初学阶段用Packet Tracer打基础，把命令记熟、把处理流程理解透，等你对配置逻辑滚瓜烂熟之后，再上GNS3做复杂拓扑也不迟。Packet Tracer 9.0之后的版本就已经内置了ACL配置支持，下载安装后不需要额外做汉化或插件配置，直接用就行。

1.2 本次实验的拓扑模型

我先画出一个清晰的实验拓扑：三台路由器串成一条线，分别命名为R1、R2、R3；然后R1下面接一台PC（代表内部员工网段10.1.1.0/24），R3下面接一台PC（代表外部服务器或核心资源网段30.1.1.0/24）。R2作为中间转发节点，让它“顺路”承载ACL的测试任务。

• PC1：IP 10.1.1.10/24，网关指向R1的G0/0接口（10.1.1.1）
• PC2：IP 30.1.1.10/24，网关指向R3的G0/0接口（30.1.1.1）
• R1与R2之间：使用10.1.2.0/30网段，R1側为10.1.2.1，R2侧为10.1.2.2
• R2与R3之间：使用10.1.3.0/30网段，R2側为10.1.3.1，R3侧为10.1.3.2

为什么选这种“三串一”的结构而不是两台路由器直连？原因很实际：真实的网络环境里，ACL往往部署在中间设备上做管控，既要考虑入方向也要考虑出方向，并且要验证跨多跳的转发行为。如果只是两台路由器直连，你很难真切感受到ACL放错位置带来的转发问题。

1.3 各设备接口IP配置参考

每个设备接口的具体IP分配如下表，按照这个表配置，能确保全网路由可达，后续配置ACL时不会被三层连通性问题干扰。

这里有个经验要分享：实验环境里，链路网段用/30子网是非常好的习惯。一个/30只包含4个IP，其中2个可用，正好够一条点到点链路两端使用，既节约地址又方便排查问题。你一眼就能看出10.1.2.0/30和10.1.3.0/30是两条不同的链路，不会搞混。

1.4 路由配置：让全网先“通”起来

配置ACL之前，必须先保证没有ACL的情况下全网能正常通信，否则后面你很难判断是路由问题还是ACL拦截问题。这里建议在每台路由器上配置OSPF或者静态路由，对于这个小型拓扑，静态路由反而更直接：

• R1上配置：ip route 10.1.3.0 255.255.255.252 10.1.2.2（抵达R2-R3链路网段）
• R1上配置：ip route 30.1.1.0 255.255.255.0 10.1.2.2（抵达PC2所在网段）
• R2上配置：ip route 10.1.1.0 255.255.255.0 10.1.2.1（抵达PC1所在网段）
• R2上配置：ip route 30.1.1.0 255.255.255.0 10.1.3.2（抵达PC2所在网段）
• R3上配置：ip route 10.1.1.0 255.255.255.0 10.1.3.1（抵达PC1所在网段）
• R3上配置：ip route 10.1.2.0 255.255.255.252 10.1.3.1（抵达R1-R2链路网段）

配置完成后，分别在PC1上ping PC2（30.1.1.10），能通就说明基础网络OK。都通了你再开始ACL的配置，这样ACL一放上去，效果立刻就能看到对比。

2. 标准ACL的核心原理与通配符掩码

2.1 标准ACL的判定逻辑

标准ACL的规则很简单：路由器收到一个数据包后，把包里的“源IP地址”提取出来，从上到下逐一跟ACL规则比对。第一条规则匹配了，就按这条规则的动作执行（permit或deny），不再继续往下看。如果所有规则都没匹配上，那么最后会被“隐含拒绝”（implicit deny any）给拦掉。

很多新手只记住了“ACL从上到下匹配”，却忽略了一个关键点——每个接口、每个方向只能应用一个ACL。如果你有两个想法需要同时落地，比如“拒绝10.1.1.0网段”和“拒绝192.168.1.0网段”，你必须把两条规则写在一个ACL编号里，而不是建两个ACL然后用两次，后者会覆盖前者。这个特性和婚姻有点像：一个方向上，一个选项就够了，多一个就会出问题。

2.2 通配符掩码（Wildcard Mask）的理解与计算

标准ACL在写规则时必须携带通配符掩码（wildcard mask），这是很多人第一次接触时最容易卡住的点。它的作用是指明：IP地址中哪些位需要精确匹配，哪些位可以忽略。

通配符掩码的规则用八个字就能概括：0要精确，1可忽略。也就是说，通配符掩码中二进制为0的位，对应IP地址的这位必须完全一致；二进制为1的位，这位随便是什么都行。

举个例子，我们要匹配“10.1.1.0/24整个网段”，也就是源IP地址的前24位必须是10.1.1，后8位随意。那么通配符掩码就是0.0.0.255。将其写成二进制非常直观：前24位为0，表示前24位要精确匹配；后8位为1，表示后8位不关心。

在Packet Tracer中你不需要自己转二进制，但有一条公式能帮你快速算出大多数情况下的通配符：

通配符掩码 = 255.255.255.255 - 子网掩码

比如子网掩码是255.255.255.0，相减得到0.0.0.255；子网掩码是255.255.255.252（/30），相减得到0.0.0.3；子网掩码是255.255.255.128（/25），相减得到0.0.0.127，都验证无误。

这里有个特殊但常见的通配符：通配符掩码为0.0.0.0时，表示匹配一台主机。比如“10.1.1.10 0.0.0.0”就代表精确匹配IP为10.1.1.10的主机，也可以用关键字host简化，写作host 10.1.1.10。这个后面配置时会用到。

2.3 为什么标准ACL要放在靠近目标端

这一点我觉得值得多说两句。扩展ACL要放在离源端近的地方，这样才能在流量刚进入网络时就拦截掉，节省链路带宽；但标准ACL恰恰相反，它只认源地址，如果放在离源端太近的位置，很可能把所有来自该网段的流量一竿子打死，导致其他合法服务也被误伤。

更严谨的说法是：标准ACL尽量部署在“离目标最近”的那台路由器上。这样做的原因是，标准ACL缺乏目标信息，只有让数据包经过尽可能多的转发路径后，你才更有把握只影响那些真正需要到达特定目的地的流量。你看，IT里的很多设计乍一听反直觉，拆开揉碎讲又非常合理。

3. 在Packet Tracer中配置标准ACL的完整操作

3.1 配置前检查：确认全网互通

打开Packet Tracer后按照前面分配的IP配置好所有接口和路由。在PC1的命令行窗口输入：

ping 30.1.1.10

如果返回的丢包率是0%，说明全网三层连通性没有问题。注意，在Packet Tracer里有时候第一次ping会因为ARP解析而超时，这是正常的，多ping几次再看结果。

确认连通后还要在R2上查看一下路由表：

Router> enable Router# show ip route

确保路由表里存在10.1.1.0/24和30.1.1.0/24的路由条目。只有路由表完整，ACL的拦截行为才不会被路由问题干扰。

3.2 需求 1：拒绝10.1.1.0网段访问30.1.1.0网段

我们先做一个最简单的需求：PC1所在的10.1.1.0/24网段禁止访问PC2所在的30.1.1.0/24网段。注意这里只要求“源网段10.1.1.0/24”过来的流量被禁止，其他网段不受影响。

按照前面说的套路，标准ACL要放在靠近目标端的地方。这个流量经过了R1、R2、R3三台设备，最终目标在R3下方，所以我们应该把ACL应用在R3的G0/1接口上，方向是in（从PC2侧进来）。等一下，这里是不是用错了方向？别急，我先解释完整。

如果你把ACL应用在R3的G0/1接口上且方向为in，那么它过滤的是从PC2侧进入R3的流量，也就是PC2发起、要回给PC1的响应流量。由于标准ACL只匹配源地址，这条反向流量源地址是30.1.1.10，跟规则“拒绝10.1.1.0网段”不匹配而被放行——最终效果是PC1能ping通PC2，但PC2也能正常回包，实际没有拦截效果。

所以正确的做法是：把ACL应用到流量进入网络的“最靠近目标端的入方向接口”。在这条链路里，从PC1来的流量到达R3的方式是进入R3的G0/0接口，因此要在R3的G0/0接口上，配置方向为in的ACL，过滤来自10.1.1.0网段的数据包。

来，我们把这个逻辑逐字拆解：数据包从PC1出发，到达R3时是从R3的G0/0接口进来的，然后路由器检查这个入方向的ACL，发现源地址10.1.1.1匹配拒绝规则，直接丢弃，数据包根本到不了R3的G0/1接口。这就是“入方向接口”的含义。

那为什么不是R2？因为R2离目标端（PC2）相对较远，只有到R3才是“离目标最近”。配置如下：

Router> enable Router# configure terminal Router(config)# access-list 1 deny 10.1.1.0 0.0.0.255 Router(config)# access-list 1 permit any Router(config)# interface g0/0 Router(config-if)# ip access-group 1 in

这里有一个特别容易忽略的点：永远记得在ACL末尾加上一条permit any。因为ACL有隐含拒绝（implicit deny any），如果你只写了deny语句，那么ACL末尾会默认拒绝所有其他流量，等于把整个网络给断掉了。加一条permit any是常规操作，不是可选项。

配置完后回到PC1再ping PC2，预期结果是Request timed out（请求超时）。与此同时，你可以在PC2上反ping PC1，观察现象：如果ACL只应用在R3的G0/0入方向，从PC2发起的ping包源地址是30.1.1.10，不受规则限制，能到达R1；但回包到R3时被ACL拦了。所以要严格验证时，请以“从PC1发起ping到PC2”作为测试手段。

3.3 需求 2：拒绝指定主机访问外部网络

有时候不需要封掉整个网段，只需要针对某一个人或者某一台机器做限制。比如只想让PC1（10.1.1.10）无法访问外部网络，其他PC不受影响，这时可以用host关键字或通配符0.0.0.0精确定位：

Router(config)# access-list 10 deny host 10.1.1.10 Router(config)# access-list 10 permit any Router(config)# interface g0/0 Router(config-if)# ip access-group 10 in

验证方式依然是去PC1上ping PC2，应该不通。如果你想验证“其他主机不受影响”，可以再添加一台PC3并设置IP为10.1.1.11，网关指向10.1.1.1，再用PC3去ping PC2，你会发现它是通的，因为ACL规则只匹配10.1.1.10这一个源地址。

这个需求在实际工作里非常常见。比如公司办公网里有人中了病毒在疯狂扫描外网，你可以先用标准ACL把他的IP拉黑，快速止损，再慢慢排查原因。虽然粒度比较粗，但胜在配置速度快。

3.4 需求 3：使用命名标准ACL提升可读性

编号ACL用起来虽然方便，但认真想想，你真的记得住1号ACL是干嘛的、2号ACL又管什么吗？在实际工程项目中，建议养成使用命名ACL（named ACL）的习惯，给策略起一个有意义的名字，比如BLOCK_HR或ALLOW_SALES。

配置命名标准ACL的命令稍微有一点不同：

Router(config)# ip access-list standard BLOCK_PC1 Router(config-std-nacl)# deny host 10.1.1.10 Router(config-std-nacl)# permit any Router(config-std-nacl)# exit Router(config)# interface g0/0 Router(config-if)# ip access-group BLOCK_PC1 in

看见没有，核心区别在于从access-list变成了ip access-list standard，然后进入了类似子配置模式的环境。在这种模式下，你输入一条deny或permit就自动成为ACL的一条规则，不需要再重复access-list 10前缀。当ACL规则条数变多、策略越来越复杂时，这种配置方式看起来舒服得多。

我个人强烈推荐：从你开始学ACL的第一天起，就把命名ACL当作默认选择。即使你的需求再简单，也尽量练习这种写法，因为它更接近真实设备里的错综复杂的配置场景，也能让你跟别人协作时更快理解彼此的意图。

3.5 如何将ACL从接口上移除

移除接口上的ACL有两种常见方式，分别是移除接口绑定和删除ACL本身，注意区别：

• 移除接口绑定：no ip access-group 1 in，生效后路由器仍然保留编号1的ACL规则，只是不再应用于该接口
• 删除ACL本身：no access-list 1，如果ACL已经绑定在接口上，删除时记得先把绑定关系解除，否则会报错或残留配置

这里说句经验之谈：模拟器里的配置没有“保存即生效”的错觉，你敲完no命令后，配置立即生效。如果后续实验步骤要反复调整ACL，建议先保留ACL规则，只通过no ip access-group临时解除绑定，调试稳定后再重新绑定，避免反复敲规则。

3.6 标准ACL的放置位置实践

在真实的生产环境里，“标准ACL放靠近目标端”是一个原则，但具体放在哪台设备还要结合现有网络架构来判断。比如你在一个多区域网络里，标准ACL可能放在汇聚层而不是核心层或者接入层。但Packet Tracer实验中，我们只用三台路由器串联，所以这个原则可以直接落实为“放在离PC2最近的那台路由器入接口上”。

万一你反着来，把标准ACL放在R1的入接口上会怎样？我们来推演一下：如果R1 G0/0接口in方向绑定deny 10.1.1.0 0.0.0.255，那么从PC1进入R1的所有源地址为10.1.1.x的数据包全部被丢弃，R1根本不会把它们转发给R2。这个效果跟放在R3其实是一样的，但仔细想，如果PC1网段还有其他合法流量需要去其他目的地，比如PC1访问R2上的某台服务器（假设有的话），这个流量也会因为ACL匹配而误伤。

这正好解释了为什么标准ACL不能放源端：它也“看不见”具体目标，所以只有放在目标附近，才能只在最后关头对“想要拒绝的流量”做处决，避免伤及无辜。

4. 验证ACL效果与排错全记录

4.1 用ping和show命令验证

配置完ACL后，不要急着收工，得认认真真验证一遍。我习惯的验证顺序是：

第一步，在PC1上ping PC2。如果不通，说明ACL生效了。这里有个细节，在Packet Tracer中ping超时有时是因为ICMP回包被丢弃但路由器没有回显，所以你看到超时不要慌，可以用show ip access-lists看看匹配计数器的变化。

第二步，看匹配计数。在R3上执行：

Router# show ip access-lists Standard IP access list BLOCK_PC1 10 deny host 10.1.1.10 (4 matches) 20 permit any (12 matches)

这个输出非常直观：deny这条规则后面的(4 matches)表示已经有4个来自10.1.1.10的数据包被拦下来了。匹配次数在增加，说明ACL正在正常工作。如果匹配次数一直都是0，那大概率是ACL放错了接口或者方向有问题。

第三步，用show run检查接口下的配置：

Router# show running-config interface GigabitEthernet0/0 ip access-group BLOCK_PC1 in

确认ACL确实绑定在目标接口的正确方向上。

4.2 常见问题：ACL配置了但没生效

ACL没生效是新手（甚至老手）最容易踩的坑。我总结了一下，常见原因基本就这几个：

其中最让人头疼的是“通配符掩码写错”。比如你想匹配10.1.1.0/24网段，却又把掩码写成0.0.255.255，那样实际匹配的是“前16位精确为10.1”的所有地址，会把10.1.x.x整个大段流量给拦了。这种问题光看show命令不容易发现，建议先把需求写下来，再手动算一遍通配符再敲进设备。

4.3 实战排查：从PC1无法访问PC2开始

我们模拟一个极具代表性的排错场景。上午刚把ACL配置到R3上，下午有人报障说PC1无法访问PC2。请快速定位问题。

排查思路是这样：先在R2上执行show ip access-lists看计数器，发现ACL规则匹配次数是0，说明流量根本没到R3就被丢弃或转发出错，于是重点怀疑路由表或ACL放错了设备。接着show ip route检查R2上是否有10.1.1.0/24路由，发现缺少这条路由，补上后PC1再到PC2仍然不通。

这时再到R3上做检查，发现接口G0/0确实绑定了ip access-group 10 in，但编号10的ACL只写了deny host 10.1.1.10，没有写permit any，导致其他来自10.1.1.11或PC1网关10.1.1.1的数据包全部被隐含拒绝挡在外面。把permit any补上后再测试，通断恢复正常。这个案例几乎涵盖了日常ACL排错的所有要点：位置、方向、规则完整性、路由可达性。

4.4 实战技巧：调试ACL前备份配置

别嫌我啰嗦，这个习惯越早养成越好。在Packet Tracer中虽然不像真实设备那样容易出事故，但人总是会反复试错。每次改ACL之前，先执行show running-config把当前配置备份到记事本里，等试到失败时，直接把备份粘回去就能恢复原状，比一点点revert命令快得多。

多说一个有用的辅助技巧：在ACL调试期间，可以把规则动作改成permit或deny来回切换，观察匹配计数器的增减来推断ACL是否命中。这个思路在真实设备上同样适用，而且匹配计数器本身不会撒谎。

5. 标准ACL配置的几个坑与心得分享

5.1 记得在末尾加permit any

这一点我已经提到过好几次了，但因为它实在太重要，我用一段话再强调一下。ACL的处理逻辑是自上而下逐一匹配，如果数据包不匹配任何规则，则会被末尾隐含的deny all拦下。所以你的ACL如果只写了deny规则，其他所有流量都会被默认拒绝。这个“默认拒绝”在安全设计里是好事，但在你只想拦一小部分流量时，它会变成事故现场。

无论什么时候，只要你希望“只拒绝特定流量、其他放行”，就一定要在最后一条写上permit any。在命名ACL里，这条规则直接写permit any即可。

5.2 注意标准ACL 只能匹配源地址的边界

再给一次忠告：标准ACL的匹配维度只有源IP。如果你接到需求“允许10.1.1.0/24访问服务器A的Web端口，但不能访问服务器B”，那这个需求用标准ACL是完不成的，你必须使用扩展ACL才能同时匹配目标IP和目的端口。用标准ACL硬做的话，要么误伤太多，要么根本无效。

要判断某个需求到底该用标准还是扩展ACL，你只需要问自己一句话：要过滤的条件里，除了源地址之外，还涉及目标地址或端口吗？如果涉及，果断换扩展ACL。标准ACL从来不是万能的，把工具用对场景，才算真正懂网络。

5.3 接口方向和ACL匹配顺序的关系

很多人在“方向”上纠结很久。我提供一个简单的心法：站在路由器视角看数据包的流动方向。数据包进入路由器时，从某个接口“进”来；离开路由器时，从某个接口“出”去。ACL应用在哪个接口上、哪个方向，就决定了它会检查什么时机的数据包。

入方向ACL在路由查找前生效：数据包进到路由器接口，先检查ACL，如果被deny，直接丢弃，不再做路由查找；如果permit，再走下一步。出方向ACL在路由查找后生效：数据包先查路由表确定要往哪个接口转发，再检查该接口的出方向ACL。这个先后顺序对排错非常重要，比如入方向deny会导致匹配计数器不增长（数据包在更早就被丢了），而出方向deny则会让路由表正常工作但最终丢弃。

在Packet Tracer里验证这一顺序也很简单：你在R3的G0/0接口上绑一个入方向标准ACL，把PC1的ping拦下，然后再去R3上show ip route，你会发现路由表没有任何异常。这说明ACL过滤发生在路由表处理之前，被deny的包根本不会参与路由决策。

5.4 命名ACL的编辑小技巧

使用命名ACL后，如果你要往已有规则中插入一条新规则，方式是通过sequence号（序列号）来控制。比如：

Router(config)# ip access-list standard BLOCK_PC1 Router(config-std-nacl)# 15 deny host 10.1.1.20

这样第15号规则就被插入到10号和20号之间。在Packet Tracer 9.0及以上版本，插入规则的功能表现还算不错，不过在更早的版本中，如果不指定序号，新规则会被追加到末尾，这点要注意。如果你发现新写的规则怎么都不生效，多半就是因为被追加到了列表末尾，连隐含拒绝都没挡住前面的规则。

5.5 好好利用ping和扩展ping来验证

在命令行环境下，ping命令有时不足以模拟真实复杂的流量特征。如果你在路由器上发起扩展ping（ping后按回车进入交互模式），可以手动设置源地址、目标地址、重复次数等参数，这样可以模拟来自特定源IP的流量，方便测试ACL是否拦截正确。

比如在R1上执行扩展ping，源地址填10.1.1.1，目标地址填30.1.1.10，然后观察是否被R3拦截。这种精确控制源地址的验证方法，在标准ACL场景里尤其好用，因为它不需要额外配置PC的IP地址，直接用路由器来模拟即可。

6. 从模拟器到真实设备：标准ACL的工程化扩展

6.1 真实设备上的差异点

很多人在Packet Tracer里配得飞起，一到真实思科路由器上就有点发怵，其实核心命令没有任何区别。不过真实设备需要注意几点：IOS版本不同，可能默认开启或关闭某些ACL相关的特性；有些新版本IOS支持写ACL时使用对象组（object-group）来批量匹配，但Packet Tracer暂时不支持。基础的access-list、ip access-group这两种命令在真实设备上用法完全一致，你在这篇文章里练会的这些命令，直接拿到真实设备上也能马上上手。

6.2 用show access-lists和debug ip packet配合排查

如果实在排查不出问题，可以打开调试功能看看真实命中的细节。在R3上执行：

Router# debug ip packet

这个命令会打印路由器收到和转发的每个数据包细节，包括接口、源地址、目标地址以及被ACL丢弃的原因。注意，在生产环境上开启debug要非常小心，因为它会消耗大量CPU资源，可能影响业务。但在Packet Tracer里随便折腾，不会出大问题。用完记得关掉：

Router# undebug all

用debug能看到很多show命令看不出来的信息，比如数据包是不是在入方向就被丢了、ACL匹配顺序是否符合预期。如果说show命令是看“静态结果”，那么debug就是看“动态过程”，两个配合起来，几乎没有解不了的ACL问题。

6.3 往扩展ACL迁移的路线

标准ACL只是入门，等你把它吃透了，扩展ACL就是顺理成章的下一个学习点。学完标准ACL之后，你可以先尝试把一个需求改写成扩展ACL版本，比如不只限制源地址10.1.1.0/24，还限制目标端口只能是80端口或443端口，再配置到R3上，你立刻就能体会到扩展ACL和标准ACL的粒度差异。

迁移的关键是理解扩展ACL的语法结构：access-list 100 permit tcp 10.1.1.0 0.0.0.255 host 30.1.1.10 eq 80。多了一个协议字段（tcp）、目标地址、目标端口，规则表达力立刻提升一个档次。在动手做扩展ACL之前，把标准ACL的通配符和方向逻辑打扎实，你会发现扩展ACL学起来特别快。

写在最后的实操体会

标准ACL这个东西，刚学的时候觉得简单，写着写着就发现不少细节上的门道。我在模拟器里帮别人做实验时，看到最多的错误就是ACL方向搞反、通配符算错、忘了写permit any。这三个坑在Packet Tracer里酿成的后果都是“原本通的一下子不通了”，好在都是学习环境，正好让你把排错练熟。真正到了实际网络环境，这几个习惯才是决定你下班时间的因素。我自己有个小习惯，每次配ACL前都会先写一行注释，把需求中用一句话写清楚：谁禁止访问谁，方向是什么，放在哪台设备哪个接口。需求明确后再动手，配置效率高一半。这篇内容里讲的每个配置，你都值得亲手在Packet Tracer里敲一遍，只有真的敲错一次、再排查一次，ACL的处理逻辑才会真正长在脑子里。