H3C交换机如何配置ACL？ACL配置命令详解

H3C交换机ACL配置，关键在于“先规划、后下发、再验证”

ACL（访问控制列表）是H3C交换机实现网络安全控制、流量过滤和策略路由的基础工具，正确的配置流程应遵循“接口方向明确、规则顺序严谨、匹配逻辑清晰”三原则，任何跳过规划直接写规则的ACL，都会在后期排障时付出数倍时间成本，本文从实际运维视角，给出H3C交换机ACL的完整配置逻辑、典型场景命令及常见陷阱,并附上酷番云混合云环境下的实战经验。

ACL在H3C交换机中的角色与分类

H3C交换机ACL按编号和类型分为基本ACL（2000-2999）、高级ACL（3000-3999）、二层ACL（4000-4999）等。

• 基本ACL：仅匹配源IP地址,最常用于简单的来源限制。
• 高级ACL：可匹配源/目的IP、协议类型、TCP/UDP端口、ICMP类型等,适合精细化控制。
• 二层ACL：基于源/目的MAC、VLAN、802.1p优先级进行过滤,常用于接入层安全。

核心认知：ACL本身不产生动作，它只是“条件清单”，真正生效的是在接口上调用时绑定的“permit”或“deny”行为,配置ACL前必须明确业务流向和管控目标。

配置ACL的标准流程与命令详解

规划阶段：明确管控对象和方向

先回答三个问题：

• 要过滤的是入方向（Inbound）流量还是出方向（Outbound）流量？
• 规则是自上而下匹配，一旦命中即停止,所以最精确的规则必须放在最前面。
• 是否隐含默认拒绝？H3C默认最后一条是 permit ip any any（部分版本）,但明确写出拒绝规则更安全。

创建ACL并编写规则

以“禁止内网某网段访问外网，但允许访问公司Web服务器”为例：

[H3C] acl number 3001
[H3C-acl-adv-3001] rule 5 permit tcp source 192.168.1.0 0.0.0.255 destination 1.2.3.4 0.0.0.0 destination-port eq 80
[H3C-acl-adv-3001] rule 10 deny ip source 192.168.1.0 0.0.0.255 any

注意：规则编号（rule 5、rule 10）不代表匹配顺序，匹配顺序按编号由小到大，留出间隔编号（5、10、15）方便后续插入规则。

在接口上应用ACL

[H3C] interface GigabitEthernet1/0/1
[H3C-GigabitEthernet1/0/1] packet-filter 3001 inbound

这里重点提示：同一接口同一方向只能应用一个ACL，如果有多类需求（如防ARP欺骗和限制IP），需合并到一个ACL中，或者使用MQC（模块化QoS策略）实现更复杂的多条件叠加。

验证与排障

[H3C] display acl 3001
[H3C] display packet-filter interface GigabitEthernet1/0/1

查看命中计数（Matched 字段）能快速判断规则是否生效，若计数为0，立即检查方向是否正确、源目地址掩码是否反掩码。

高级实用技巧：时间段ACL和MQC联动

基于时间段的ACL

办公场景下,限制非工作时间禁止访问生产网段：

[H3C] time-range worktime 8:00 to 18:00 working-day
[H3C] acl number 3002
[H3C-acl-adv-3002] rule 5 deny ip source 10.1.1.0 0.0.0.255 destination 172.16.0.0 0.0.255.255 time-range worktime

与MQC配合实现重标记

当ACL仅用于“识别流量”，后续动作是限速、重标记QoS优先级或重定向时，建议直接使用流量行为绑定ACL，而非在接口上单纯packet-filter。

[H3C] traffic classifier c1 operator and
[H3C-classifier-c1] if-match acl 3003
[H3C] traffic behavior b1
[H3C-behavior-b1] car cir 1000
[H3C] qos policy p1
[H3C-qospolicy-p1] classifier c1 behavior b1
[H3C-GigabitEthernet1/0/2] qos apply policy p1 inbound

这比直接丢包更灵活，能实现“限速但不断网”的业务体验。

酷番云经验案例：混合云场景下的ACL部署

酷番云在协助某电商客户迁移至混合云架构时，遇到一个典型问题：本地H3C交换机与云上安全组无法直接联动，导致办公网访问云上数据库时,源IP被云安全组误封。

我们给出的方案是：在客户核心交换机上配置高级ACL+SNAT联动,规则分三步：

1. 先识别“来自办公区且目标是云数据库VIP”的流量,放行；
2. 再将这类流量重定向到出口防火墙进行源地址转换；
3. 最后在ACL的尾部写入“拒绝其他一切跨网段访问数据库”的规则。

将ACL的命中日志实时发送到酷番云日志平台，实现 “规则可观测、变更可审计、误杀可回溯”，该方案使客户零代码改造，仅靠H3C交换机原有能力就解决了云上安全组无法感知内网真实IP的问题,且故障定位时间从小时级缩短至分钟级。

关键教训：ACL不只是“安全开关”，更是“流量路由策略”的组成部分，在混合云场景下，规划ACL时应把交换机、防火墙、云安全组视为一个统一策略面,而不是各自独立配置。

常见配置陷阱与解决方案

• 反掩码错误：H3C ACL使用通配符掩码（0和255），168.1.0 0.0.0.255 中0表示严格匹配，误写为 255.255.0 会导致规则永不生效。
• 规则顺序不当：先写了宽泛的deny，后写精确的permit，结果精确permit永远不会被匹配。必须先精确后宽泛。
• 接口方向理解错误：Inbound是流量进入交换机接口的方向，Outbound是流出方向，路由器场景下通常Inbound更常用,而交换机接入层更常用Inbound限制终端。



• 忘记考虑控制平面流量：ACL只过滤数据平面的转发流量，对CPU发起的协议报文（如OSPF、BGP）默认不生效，需要单独用 control-plane 下的ACL保护。

相关问答模块

问题1：为什么我配置了ACL拒绝某IP访问服务器，但服务器上仍然能看到该IP的连接请求？

答：请先检查ACL应用的接口和方向，若服务器连接在交换机的G1/0/2口，而ACL应用在G1/0/1的inbound方向，那么只过滤了从G1/0/1进入的流量，如果攻击IP是从G1/0/3进入的，则不会被过滤，如果ACL中规则编号较大（如rule 100）而存在默认规则提前匹配（如rule 5 permit ip any any），同样会导致拒绝规则不生效，建议通过 display acl 查看命中计数,并确认ACL编号顺序。

问题2：H3C交换机上的ACL能否直接防护DDoS攻击？

答：不能，ACL是静态的包过滤工具，适合做访问控制和简单限速，但它无法识别分布式流量特征，也无法自动调整策略，针对DDoS，需要配合防火墙的DDoS防护模块或专业清洗设备，但在边界交换机上，可以用ACL临时封禁攻击源IP、限流UDP/TCP SYN包，作为应急缓解手段，例如设置 rule deny udp destination-port eq 53 可在短时间内缓解DNS放大攻击,长期方案应部署流量清洗系统。

结语与互动

H3C交换机ACL配置本身不复杂，复杂的是对业务逻辑的深度理解，建议每次配置前先在Visio或草稿纸上画出流量路径图，标出接口方向、源目的地址和端口，再落命令，欢迎在评论区分享你在实际运维中遇到的ACL“诡异”问题，或描述你的网络拓扑，我们会在后续文章中结合案例给出针对性配置模板，你的实战经验,也许就是别人正在寻找的答案。