4. 扩展ACL配置：编号范围、协议与端口匹配、配置命令
标准ACL只能匹配源IP，说白了就是「看人下菜碟」。但实际工作中，我们经常需要「看人+看事」——比如只允许某台服务器访问Web服务，但禁止它访问SSH。这时候，扩展ACL就派上用场了。
我个人习惯把扩展ACL叫做「精细化管理工具」。它能匹配源IP、目的IP、协议类型、源端口、目的端口，甚至还能区分TCP的建立状态。嗯，这才是真正的访问控制。
4.1 扩展ACL的编号范围
扩展ACL的编号范围是固定的，不同厂商略有差异。我整理了一张表，方便你对照记忆：
| 厂商 | 扩展ACL编号范围 | 备注 |
|---|---|---|
| Cisco IOS | 100 – 199 | 经典扩展ACL |
| Cisco IOS | 2000 – 2699 | 扩展ACL（增强范围） |
| 华为 VRP | 3000 – 3999 | 基本ACL用2000-2999 |
| H3C Comware | 3000 – 3999 | 与华为一致 |
| Juniper JunOS | 无编号（命名式） | 通过名称区分类型 |
4.2 协议与端口匹配
扩展ACL的核心能力就是匹配协议和端口。你想想看，如果不指定协议，ACL默认匹配所有IP流量。但实际场景中，我们往往只关心TCP、UDP、ICMP等特定协议。
协议匹配的关键字如下：
- tcp：匹配TCP协议（6）
- udp：匹配UDP协议（17）
- icmp：匹配ICMP协议（1）
- ip：匹配所有IP协议（默认）
- 数字：直接写协议号，比如 89 代表OSPF
端口匹配时，可以用关键字（如 www、telnet、ssh），也可以用数字端口号。我个人建议用数字，因为不同厂商的关键字支持程度不一样，但端口号是通用的。
端口匹配的两种写法：
写法一（关键字）：eq www
写法二（数字）：eq 80
效果完全一样，但数字更可靠。我在跨厂商设备迁移时吃过关键字的亏——华为不支持Cisco的「www」关键字，必须写成80。
4.3 配置命令详解
扩展ACL的配置命令，说白了就是一条完整的条件语句。我们以Cisco IOS为例，看看标准格式：
access-list ACL编号 [permit|deny] 协议 源IP 源反掩码 [操作符 源端口] 目的IP 目的反掩码 [操作符 目的端口] [log]这个命令看起来长，但拆开来看就清楚了：
- ACL编号：100-199或2000-2699
- permit/deny：允许或拒绝
- 协议：tcp、udp、icmp、ip等
- 源IP + 反掩码：源地址范围
- 操作符 + 源端口：可选，如 eq、gt、lt、range
- 目的IP + 反掩码：目的地址范围
- 操作符 + 目的端口：可选，通常用于目的端口
- log：可选，记录匹配日志
注意反掩码：反掩码和子网掩码是反过来的。比如 255.255.255.0 对应反掩码 0.0.0.255。我曾经见过新手把反掩码写成子网掩码，结果ACL死活不生效。记住：0代表精确匹配，255代表忽略。
4.4 实战配置示例
光说不练假把式。我们来看几个我在项目中实际用过的配置：
示例1：只允许内网访问Web服务器
access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 80
access-list 101 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 443
access-list 101 deny ip any any这个配置只允许192.168.1.0/24网段访问10.0.0.10的80和443端口，其他流量全部拒绝。
示例2：禁止Ping但允许其他流量
access-list 102 deny icmp any any echo-request
access-list 102 permit ip any any这里只拒绝了ICMP的echo-request（ping请求），但允许其他所有流量。注意，echo-reply（ping回应）没有被拒绝，所以内网设备仍然能收到回应。
示例3：限制特定主机的SSH访问
access-list 103 permit tcp host 10.1.1.100 host 10.2.2.200 eq 22
access-list 103 deny tcp any host 10.2.2.200 eq 22
access-list 103 permit ip any any这个配置只允许10.1.1.100这台管理主机SSH到10.2.2.200，其他主机一律禁止SSH，但其他流量不受影响。
4.5 扩展ACL的生效位置
扩展ACL有个重要原则：尽量靠近源端。为什么？因为扩展ACL能匹配端口，如果放在靠近目的端的位置，不符合条件的流量已经穿越了半张网络，白白浪费带宽。
举个例子：如果只想拒绝某个源IP访问Web，把ACL放在接入层交换机上，流量在入口就被拒绝了。如果放在核心层，流量已经经过了接入层和汇聚层，占用了两段链路。
我的经验：扩展ACL放在源端路由器的入方向（inbound），这样最节省网络资源。但要注意，如果源端路由器性能较差，ACL条目太多会影响转发效率。这时候可以考虑把ACL下放到汇聚层。
4.6 扩展ACL与标准ACL的对比
我经常被问到：「什么时候用标准ACL，什么时候用扩展ACL？」其实很简单：
| 对比维度 | 标准ACL | 扩展ACL |
|---|---|---|
| 匹配范围 | 仅源IP | 源IP、目的IP、协议、端口 |
| 编号范围 | 1-99, 1300-1999 | 100-199, 2000-2699 |
| 配置复杂度 | 简单 | 中等 |
| 推荐位置 | 靠近目的端 | 靠近源端 |
| 典型场景 | 简单的网段隔离 | 精细化服务访问控制 |
说白了，标准ACL适合「一刀切」，扩展ACL适合「精准打击」。我在项目中，90%的场景都用扩展ACL，因为现在的网络需求越来越细，标准ACL根本不够用。
4.7 扩展ACL配置流程图
下面这张图是我自己总结的扩展ACL配置决策流程，帮你理清思路：
4.8 避坑指南
做了这么多年网络，我在扩展ACL上踩过的坑不少。分享几个典型的：
- 反掩码写反：这是最常见的错误。我曾经帮一个同事排查问题，他写的是
access-list 101 permit ip 192.168.1.0 255.255.255.0 any，结果ACL完全不生效。反掩码应该是0.0.0.255，不是255.255.255.0。 - 端口方向搞错：扩展ACL可以匹配源端口和目的端口。很多人把目的端口写到了源端口的位置。记住：服务器端口通常是目的端口，客户端端口通常是源端口。
- 隐式拒绝被忽略：每个ACL末尾都有一条隐式的
deny ip any any。如果你只写了permit语句，没写deny语句，其他流量也会被拒绝。这不是bug，是特性。 - 顺序问题：ACL是顺序匹配的，一旦匹配就停止。所以要把最精确的规则放在前面，最宽松的规则放在后面。我曾经见过有人把
permit ip any any放在第一条，结果后面的规则全部失效。
我的建议：每次配置完扩展ACL，先用 show access-list 查看匹配计数。如果计数一直为0，说明规则没生效，赶紧检查配置。如果计数一直在涨，说明流量被匹配到了，看看是不是你想要的。
扩展ACL是网络工程师的「手术刀」，用好了能精准控制流量，用不好就是给自己挖坑。多练、多测、多总结，慢慢就能掌握它的脾气。