第四课：扩展ACL实战——精细化控制的艺术
各位好，欢迎来到第四课。今天咱们聊聊扩展ACL。
标准ACL只能管源IP，说实话，在真实网络里有点不够用。你想想看，一个公司网络，既要允许员工上网，又要禁止他们访问某些服务器端口，标准ACL根本搞不定。这时候，扩展ACL就派上用场了。
4.1 扩展ACL到底能干啥？
扩展ACL和标准ACL最大的区别，就是它能基于更多条件做过滤。具体来说，它可以检查：
- 源IP地址 —— 谁发的包
- 目的IP地址 —— 发给谁
- 源端口 —— 从哪个端口来的
- 目的端口 —— 要去哪个端口
- 协议类型 —— TCP、UDP、ICMP等等
说白了，标准ACL只能管到「谁」，扩展ACL能管到「谁、找谁、干什么」。我在项目中遇到过很多次，客户说「我要禁止研发部访问财务服务器，但允许他们访问其他服务器」，这种需求用标准ACL根本没法做，扩展ACL一条规则就搞定。
4.2 扩展ACL的配置命令
扩展ACL的配置命令，和标准ACL有点不一样。咱们先看个基本格式：
access-list 编号 permit|deny 协议 源IP 通配符 目的IP 通配符 [eq 端口号]这里有几个关键点：
- 编号范围：扩展ACL的编号是100-199，以及2000-2699（新版设备）。我个人习惯用100-199，好记。
- 协议字段：可以写tcp、udp、icmp、ip（代表所有协议）等。
- 端口号：只有协议是tcp或udp时，才能用eq指定端口。
举个例子，我要禁止192.168.1.0/24网段访问10.0.0.100的Web服务（80端口）：
access-list 100 deny tcp 192.168.1.0 0.0.0.255 10.0.0.100 0.0.0.0 eq 80
access-list 100 permit ip any any嗯，这里要注意：扩展ACL默认也是拒绝所有，所以最后一定要加一条permit any any，否则所有流量都会被拦掉。我曾经见过一个同事，配完ACL忘了加permit，结果整个部门断网半小时……
4.3 基于源目IP的过滤
这是最基础的应用。比如，我只允许192.168.1.10这台管理主机访问核心交换机：
access-list 100 permit ip host 192.168.1.10 10.0.0.1 0.0.0.0
access-list 100 deny ip any any这里用了host关键字，其实就是通配符0.0.0.0的简写。你想想看，如果不用host，就得写成192.168.1.10 0.0.0.0，多麻烦。
我在项目中遇到过一种情况：客户要求只允许特定几个IP访问DMZ区的服务器，其他IP全部拒绝。这种需求用扩展ACL做，就是写几条permit，最后一条deny any any。简单粗暴，但有效。
4.4 基于端口的精细化控制
这才是扩展ACL的真正强项。咱们来看几个实战场景：
场景一：只允许内网用户访问外网的Web服务
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq 80
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq 443
access-list 100 deny ip any any这样配置后，内网用户只能上网页，不能打游戏、不能下载BT。很多企业就是这么干的。
场景二：禁止访问特定服务器的SSH
access-list 100 deny tcp any host 10.0.0.100 eq 22
access-list 100 permit ip any any这个配置的意思是：所有人都不能SSH到10.0.0.100，但其他访问不受影响。注意，这里host 10.0.0.100就是10.0.0.100 0.0.0.0的简写。
tcp eq 80，而不是ip eq 80。因为端口是传输层的概念，网络层根本不认识端口号。我见过有人写ip eq 80，结果ACL根本不生效，查了半天才发现协议写错了。
4.5 基于协议的过滤
有时候，我们需要针对特定协议做过滤。比如，禁止ICMP（ping）流量：
access-list 100 deny icmp any any
access-list 100 permit ip any any这个配置会禁止所有ping请求。但要注意，ICMP协议有很多类型，比如echo（ping请求）、echo-reply（ping响应）、destination-unreachable（目标不可达）等。如果你只想禁止ping请求，可以这样写：
access-list 100 deny icmp any any echo
access-list 100 permit ip any any这样配置后，别人ping不通你，但网络诊断消息（比如TTL超时）还是能正常传递。我在项目中遇到过一种情况：客户说「为什么我ping不通服务器，但业务是正常的？」其实就是ACL只拦了echo请求，没拦其他ICMP类型。
4.6 扩展ACL的精细化控制实战
好了，咱们来个综合案例。假设有这样的需求：
- 研发部（192.168.1.0/24）可以访问财务服务器（10.0.0.10）的数据库端口（3306）
- 研发部不能访问财务服务器的Web管理界面（8080端口）
- 运维部（192.168.2.0/24）可以访问所有服务器
- 其他部门只能访问外网Web服务
配置如下：
! 允许研发部访问财务数据库
access-list 100 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 3306
! 禁止研发部访问财务Web管理
access-list 100 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.10 eq 8080
! 允许运维部访问所有
access-list 100 permit ip 192.168.2.0 0.0.0.255 any
! 允许其他部门访问外网Web
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq 80
access-list 100 permit tcp 192.168.0.0 0.0.255.255 any eq 443
! 拒绝其他所有流量
access-list 100 deny ip any any注意规则的顺序！ACL是从上到下匹配的，一旦匹配就停止。所以，更具体的规则要放在前面。比如，研发部访问财务服务器的规则，要先写允许数据库的，再写拒绝Web管理的。如果顺序反了，拒绝规则先匹配，数据库访问也会被拦掉。
4.7 扩展ACL的部署位置
扩展ACL应该部署在哪里？这是个好问题。
一般来说，扩展ACL要尽量靠近源端。为什么呢？因为扩展ACL能检查端口和协议，如果放在靠近目的端，那些被拒绝的流量已经穿越了整个网络，浪费了带宽。你想想看，如果研发部的非法请求已经跑到了财务服务器门口才被拦掉，中间经过的交换机、路由器都白忙活了。
所以，我的建议是：
- 控制内网访问的ACL，部署在核心交换机或汇聚交换机上
- 控制外网访问的ACL，部署在边界路由器或防火墙上
- 控制服务器访问的ACL，部署在服务器接入交换机上
当然，具体位置还要看网络拓扑。我在项目中遇到过一种情况：客户把所有ACL都堆在核心交换机上，结果核心交换机CPU负载飙到80%。后来我们把ACL分散到各接入交换机，问题就解决了。
4.8 验证和排错
配置完ACL，怎么验证它生效了？
最常用的命令是：
show access-list 100
show ip interface 接口名show access-list 100会显示每条规则的匹配次数。如果某个规则的匹配次数一直在增加，说明有流量被这条规则匹配到了。
show ip interface会显示接口上是否应用了ACL，以及ACL的方向（in/out）。
如果ACL不生效，我一般按这个顺序排查：
- 检查ACL是否应用到了正确的接口
- 检查ACL的方向是否正确（in还是out）
- 检查规则顺序是否合理
- 检查通配符是否写对了
- 检查协议和端口是否匹配
嗯，最后一条最容易出错。比如，有人想过滤HTTPS，却写了eq 443但协议写成了udp。HTTPS明明是TCP啊！这种低级错误，我见过不止一次。
好了，这节课就到这里。下节课咱们聊聊命名ACL，那玩意儿比编号ACL更灵活，也更易读。到时候见！