📚 课程目录第4章扩展ACL配置

4. 扩展ACL配置：语法、实例与高级特性

标准ACL只能管源IP，说实话，在真实网络里根本不够用。你想想看，光限制源地址，那目的端口、协议类型、会话状态这些怎么控制？所以就有了扩展ACL。这一章我带你把它吃透。

4.1 扩展ACL的语法

扩展ACL的语法比标准ACL复杂一些，但逻辑更清晰。基本格式是这样的：

access-list access-list-number [permit | deny] protocol source source-wildcard destination destination-wildcard [operator operand] [established]

我来拆解一下关键字段：

access-list-number：扩展ACL的范围是100-199，后来扩展到2000-2699。我个人习惯用100-199，好记。
protocol：可以是IP、TCP、UDP、ICMP、GRE等。这是扩展ACL的核心——能区分协议。
source/destination：源和目标IP地址，后面都要跟通配符掩码。
operator operand：操作符和端口号，比如 eq 80、gt 1024、range 1000 2000。只有TCP和UDP协议才能用端口。
established：仅用于TCP，匹配已建立的连接。这个后面细说。

我的习惯：写扩展ACL时，我总会在协议字段上先写IP，再细化。比如先放行所有IP流量，再用更具体的条目拒绝特定TCP端口。这样调试起来不会把自己搞晕。

4.2 扩展ACL的配置实例

光说语法太干，直接上实例。假设这样一个场景：公司内网有3个部门，我只允许市场部（192.168.10.0/24）访问财务服务器（10.1.1.100）的HTTPS端口，其他部门一律禁止。

配置如下：

!
interface GigabitEthernet0/0
 ip access-group 110 in
!
access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 10.1.1.100 eq 443
access-list 110 deny ip any any
!

注意几点：

我用 host 代替了 0.0.0.0 通配符，更简洁。
最后一条 deny ip any any 是隐式的，但显式写出来更安全，也方便排错。
ACL应用在接口的 in 方向，因为流量是从市场部进入路由器的。

再来看一个更复杂的例子：允许内网用户访问外网的DNS和HTTP，但禁止访问外网的Telnet。

access-list 120 permit udp 192.168.0.0 0.0.255.255 any eq 53
access-list 120 permit tcp 192.168.0.0 0.0.255.255 any eq 80
access-list 120 permit tcp 192.168.0.0 0.0.255.255 any eq 443
access-list 120 deny tcp 192.168.0.0 0.0.255.255 any eq 23
access-list 120 deny ip any any

我曾经踩过的坑：有一次我把ACL的顺序写反了，把 deny tcp any any eq 23 放在了允许规则前面。结果所有TCP流量都被匹配到了deny，整个网络都断了。记住，ACL是顺序匹配的，一旦匹配就停止检查。所以要把最具体的规则放在前面。

4.3 扩展ACL的高级特性

扩展ACL不只是简单的允许/拒绝，它还有一些高级玩法。我挑几个常用的说说。

4.3.1 基于时间的ACL

有些策略只需要在特定时间段生效。比如，只允许在工作时间（9:00-18:00）访问某些服务器。这需要结合 time-range 来用。

!
time-range WORKING-HOURS
 periodic weekdays 9:00 to 18:00
!
access-list 130 permit tcp 192.168.1.0 0.0.0.255 host 10.1.1.200 eq 80 time-range WORKING-HOURS
access-list 130 deny ip any any
!
interface GigabitEthernet0/1
 ip access-group 130 in
!

这里的关键是 time-range 定义了时间段，ACL条目引用它。下班后这条规则自动失效，隐式deny就会生效。

4.3.2 反射ACL

反射ACL用于状态化过滤。说白了，它允许内部发起的会话的返回流量通过，但阻止外部主动发起的连接。这在没有状态化防火墙的老设备上很有用。

配置分两步：

定义反射ACL条目：reflect 关键字
在入方向应用：evaluate 关键字

!
ip access-list extended OUTBOUND
 permit tcp 192.168.0.0 0.0.255.255 any reflect TCP-TRAFFIC
!
ip access-list extended INBOUND
 evaluate TCP-TRAFFIC
 deny ip any any
!
interface GigabitEthernet0/0
 ip access-group OUTBOUND out
 ip access-group INBOUND in
!

当内部主机发起TCP连接时，OUTBOUND规则会动态创建一个临时条目，允许对应的返回流量进入。外部主动发起的连接因为没有匹配的反射条目，会被deny掉。

  核心要点：反射ACL只对TCP有效（UDP也可以但需要额外配置），而且临时条目有超时时间。我在一个项目中用反射ACL替代了老旧的防火墙，撑了两年才升级。

4.3.3 动态ACL（Lock-and-Key）

动态ACL允许用户通过认证后临时获得访问权限。配置起来稍微复杂，但很灵活。

!
username admin password 0 cisco
!
interface GigabitEthernet0/0
 ip access-group 140 in
!
access-list 140 permit tcp any host 10.1.1.1 eq 23
access-list 140 dynamic MY-DYNAMIC-ACL timeout 5 permit ip 192.168.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!
line vty 0 4
 login local
 autocommand access-enable host timeout 10
!

用户先Telnet到路由器（10.1.1.1），通过认证后，autocommand 自动执行 access-enable，创建一个临时ACL条目，允许该用户的源IP访问目标网段。5分钟后自动超时删除。

我的建议：动态ACL适合临时授权场景，比如远程工程师需要紧急访问内网服务器。但别滥用，因为每个用户都需要Telnet认证，管理起来挺麻烦的。

4.4 扩展ACL知识体系图

下面这张图帮你梳理扩展ACL的核心脉络：

4.5 避坑指南与经验总结

最后，我把自己这些年踩过的坑和总结的经验列出来，你直接拿去用：

常见问题	原因	解决方案
ACL不生效	接口方向搞反了	检查流量方向，用 `show ip access-list` 确认匹配次数
所有流量都被拒绝	顺序错误，deny放在了permit前面	调整ACL条目顺序，最具体的规则放最前面
反射ACL不工作	没有配置 `evaluate` 或超时时间太短	确保入方向引用了反射条目，适当调整超时
动态ACL无法认证	VTY线路没有配置 `autocommand`	在line vty下添加 `autocommand access-enable`

我曾经犯过的错：有一次在生产环境上配置反射ACL，忘了在入方向加 evaluate 语句。结果内部发起的TCP连接，返回流量全被deny了。整个部门断网半小时，被领导叫去喝茶。从那以后，我每次配置完ACL都会用 show access-list 检查匹配计数，确保每条规则都在正确工作。

扩展ACL的灵活性远高于标准ACL，但复杂度也上来了。我的建议是：先画拓扑，再写规则，最后测试。别急着往设备上敲，想清楚再动手。