Cisco ACL 配置实战：基于IP与端口的3层访问控制策略-拓冰建站

Cisco ACL 配置实战：基于IP与端口的3层访问控制策略

在企业网络架构中，不同部门间的服务访问控制是网络安全的核心需求之一。想象这样一个场景：总装分厂的工程师需要查阅零件分厂的工艺文档，但两个分厂间的文件传输服务必须严格隔离。这种精细化的访问控制，正是访问控制列表（ACL）技术的用武之地。

1. ACL技术原理与设计逻辑

访问控制列表本质上是一组按顺序排列的规则集合，路由器会逐条匹配这些规则来决定数据包的放行或拒绝。当数据包到达配置了ACL的接口时，路由器会从列表顶部开始检查，一旦匹配某条规则就立即执行相应动作（允许或拒绝），后续规则不再评估。

标准ACL与扩展ACL的核心区别：

标准ACL：仅基于源IP地址进行过滤（编号范围1-99）
扩展ACL：可基于源/目标IP、协议类型、端口号等多维度过滤（编号范围100-199）

在本文的企业网络案例中，我们需要实现：

允许跨分厂访问WWW服务（TCP 80端口）
禁止跨分厂访问FTP服务（TCP 21端口）

这要求使用扩展ACL，因为它需要同时控制协议类型和端口号。以下是典型的企业网络拓扑示意图：

[零件分厂] ---- [分厂路由器] ---- [核心网络] ---- [总厂路由器] ---- [总装分厂] │ │ │ │ └─ WWW/FTP └─ ACL规则 └─ DNS/WWW └─ WWW/FTP

2. 配置命令详解与接口方向选择

2.1 基础ACL规则配置

在分厂路由器上配置扩展ACL时，需要特别注意规则顺序。ACL采用"首次匹配"原则，因此应将具体规则放在前面，通用规则放在后面。以下是针对零件分厂的配置示例：

! 进入全局配置模式 Router> enable Router# configure terminal ! 创建扩展ACL（编号110） Router(config)# access-list 110 remark Allow cross-plant WWW access Router(config)# access-list 110 permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 80 Router(config)# access-list 110 remark Block cross-plant FTP access Router(config)# access-list 110 deny tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 21 Router(config)# access-list 110 permit ip any any ! 允许其他所有流量

关键参数解析：

permit/deny：允许或拒绝动作
tcp：协议类型（UDP/ICMP等也可用）
192.168.2.0 0.0.0.255：源网络地址及通配符掩码
eq 80：目标端口等于80（WWW服务）

2.2 接口应用方向决策

ACL的应用方向（in/out）直接影响控制效果。判断标准是：站在路由器角度，观察数据流的进出方向。

在本案例中，应该在分厂路由器的**出方向（out）**应用ACL：

控制从分厂路由器发往其他网络的流量
避免影响分厂内部通信

配置命令示例：

Router(config)# interface FastEthernet0/1 ! 连接核心网络的接口 Router(config-if)# ip access-group 110 out

注意：ACL不能直接过滤路由器自身产生的流量（如ping、telnet等），这类控制需要使用专门的Control-Plane ACL。

3. 企业网络中的ACL最佳实践

3.1 多维度访问控制策略

现代企业网络通常需要组合多种ACL类型实现立体防护：

ACL类型	控制维度	典型应用场景
标准ACL	源IP地址	基本网络隔离
扩展ACL	五元组（IP、端口、协议）	服务级访问控制
时间ACL	时间段+五元组	上班时间限制

时间ACL配置示例：

! 定义工作时间段（工作日9:00-18:00） Router(config)# time-range WORK-HOURS Router(config-time-range)# periodic weekdays 9:00 to 18:00 ! 将时间段应用于ACL Router(config)# access-list 120 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80 time-range WORK-HOURS

3.2 配置验证与排错

完成ACL配置后，必须进行系统化测试：

基础连通性测试：

Router# ping 192.168.2.100 source 192.168.1.1

ACL规则命中检查：

Router# show access-list 110 Extended IP access list 110 10 permit tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www (25 matches) 20 deny tcp 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq ftp (3 matches) 30 permit ip any any (102 matches)

端口级访问测试：

! 测试WWW访问（应成功） Router# telnet 192.168.2.100 80 ! 测试FTP访问（应失败） Router# telnet 192.168.2.100 21

常见故障排除流程：

检查ACL是否应用到正确接口和方向
验证规则顺序是否符合"从具体到通用"原则
确认通配符掩码是否正确
检查是否有其他ACL产生冲突

4. 高级ACL应用场景

4.1 结合NAT的ACL配置

当网络中存在地址转换时，ACL需要特别注意匹配转换前后的地址。典型配置示例：

! 内部到外部的ACL（匹配原始地址） access-list 101 permit tcp 10.1.1.0 0.0.0.255 any eq 80 ! NAT配置 ip nat inside source list 101 interface FastEthernet0/1 overload

4.2 IPv6环境下的ACL

IPv6 ACL使用命名方式而非编号，且语法有所不同：

ipv6 access-list PLANT-ACL permit tcp 2001:db8:1::/64 2001:db8:2::/64 eq www deny tcp 2001:db8:1::/64 2001:db8:2::/64 eq ftp permit ipv6 any any

4.3 基于角色的访问控制

现代IOS支持将ACL与用户角色绑定，实现更精细的权限管理：

! 定义角色 role name NETWORK-ADMIN access-list 110 permit tcp any any eq 22 ! 将角色分配给用户 username admin privilege 15 role NETWORK-ADMIN

在实际项目中，我曾遇到一个典型案例：某制造企业要求研发部门可以访问生产系统的Web界面（端口8080），但不能访问其数据库端口（3306）。通过精心设计的扩展ACL，我们实现了这一需求，同时避免了影响其他部门的正常访问。关键配置如下：

access-list 150 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 8080 access-list 150 deny tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 3306 access-list 150 permit ip any any

这种基于服务的访问控制策略，比传统的全有或全无的网络隔离更加灵活实用。