华为eNSP ACL实战：基于服务与网段的多维度访问控制

1. 华为eNSP ACL实战入门指南

第一次接触华为eNSP的ACL配置时，我也被那些规则搞得头晕眼花。直到有次公司内网出了安全问题，老板要求我立刻隔离市场部和研发部的网络访问，才逼着我真正搞懂了ACL的玩法。现在我就用最直白的语言，带你快速掌握这个网络管理的利器。

ACL（访问控制列表）就像小区的门禁系统，决定哪些人能进哪个单元楼。在华为设备上主要分两种：基本ACL（2000-2999）只认源IP，相当于看身份证；高级ACL（3000-3999）能识别协议、端口，就像同时检查身份证+工牌+访问目的。举个例子，192.168.1.0网段是市场部，192.168.2.0网段是研发部，SERVER1是文件服务器，我们要实现：

• 禁止两个部门互访
• 市场部只能TELNET管理服务器
• 研发部只能FTP上传代码
• 其他部门禁止访问服务器

2. 基础环境搭建

2.1 模拟环境准备

建议先用eNSP搭建这个经典实验拓扑：三台路由器模拟PC和服务器，三台交换机做核心设备。IP规划有个小技巧——我习惯用设备编号作为主机位，比如R3的G0/0口在192.168.1.0网段时就配192.168.1.3/24，这样排查故障时一眼就能定位设备。

配置路由时遇到过坑：华为设备用RIP协议时，如果直接写network 192.168.1.0会报错。后来发现要用主类网络号，比如192.168.1.0要写成192.168.0.0。建议先用display ip routing-table检查路由是否完整。

2.2 服务配置要点

在SERVER1上开TELNET和FTP服务时，这几个参数最容易出错：

[server1]local-user admin password cipher 123456 [server1]local-user admin service-type telnet ftp [server1]local-user admin ftp-directory flash:/ # 必须指定FTP根目录 [server1]user-interface vty 0 4 [server1-ui-vty0-4]authentication-mode aaa # 启用AAA认证

实测发现华为默认开启TELNET但FTP需要手动激活，忘记配ftp-directory会导致连接失败。权限等级建议设15级，否则可能出现部分命令无法执行的情况。

3. 基本ACL实战技巧

3.1 网段隔离配置

禁止192.168.1.0访问192.168.2.0网段时，必须在R2的G0/0/1接口出方向应用ACL：

[r2]acl 2000 [r2-acl-basic-2000]rule deny source 192.168.1.0 0.0.0.255 [r2-GigabitEthernet0/0/1]traffic-filter outbound acl 2000

这里有个血泪教训：基本ACL一定要靠近目标设备配置。有次我在R1的入方向配置，结果把192.168.1.0网段所有对外访问都阻断了。通配符掩码0.0.0.255表示匹配前24位，相当于/24网段。

3.2 接口方向选择

ACL应用方向决定过滤效果：

• 入方向(inbound)：数据包进入接口时检查
• 出方向(outbound)：数据包离开接口时检查

建议用这个判断方法：想象数据流方向，在数据"进门"或"出门"时过滤。测试时可以用ping和tracert结合检查，有时ACL生效但路由不可达会混淆判断。

4. 高级ACL深度配置

4.1 服务精准控制

实现PC1能TELNET但不能FTP的配置：

[r1]acl 3000 [r1-acl-adv-3000]rule deny tcp source 192.168.1.1 0 destination 192.168.3.1 0 destination-port eq 21 [r1-GigabitEthernet0/0/0]traffic-filter inbound acl 3000

高级ACL的规则顺序很重要，系统从上到下匹配。有次我把deny规则放在后面导致策略失效，后来养成习惯用rule编号（如rule 5、rule 10）预留空间。FTP服务实际使用21端口，TELNET是23端口，协议类型要选tcp。

4.2 复合条件策略

禁止192.168.2.0网段访问SERVER1所有服务：

[r2]acl 3000 [r2-acl-adv-3000]rule deny ip source 192.168.2.0 0.0.0.255 destination 192.168.3.1 0

这里用ip协议会匹配所有IP流量，比单独封堵TCP/UDP更彻底。遇到过ICMP协议漏过滤的情况，导致虽然ping不通但实际服务可访问，这时候用ip协议更保险。

5. 故障排查与优化

5.1 常见问题定位

当ACL不生效时，按这个顺序检查：

1. 用display acl all查看规则是否配置正确
2. 用display traffic-filter applied-record确认应用接口和方向
3. 用debugging ip packet查看报文匹配情况（慎用，可能刷屏）

有次策略不生效，最后发现是接口下没保存配置。现在我都用commit命令强制保存，或者display current-configuration检查完整配置。

5.2 性能优化建议

复杂网络建议：

• 将常用规则放在ACL前面
• 合并相似规则（如多个deny规则可用一条带通配符的规则替代）
• 在核心设备上使用硬件ACL（如华为的ACL资源板）

实际项目中遇到过ACL条目过多导致设备CPU升高的情况，后来改用QoS+ACL组合方案减轻负担。对于超过50条规则的场景，建议划分多个ACL并分层部署。