H3C交换机配置高危端口封禁后SSH失效排查实例
记录一次H3C交换机配置135、137、138、139、445和3389端口封禁策略后，因为QoS和ACL硬件资源不足导致SSH失效的真实故障。
这是我实际遇到的一次故障，故障设备是一台配置较低的接入交换机。本文按照 H3C S5570S 系列和 Comware V7 的命令格式整理，文中的地址和接口名称是示例，使用时要以现场配置为准。
一、故障现象
这台交换机原来一直可以通过 SSH 正常管理。后来公司为了封禁与勒索病毒有关的高危端口，要求所有交换机必须配置 ACL 和 QoS 过滤策略。
当时在每个物理端口的入方向和出方向都应用了策略，又在全局入方向和出方向应用了一次。配置完成后，原来正常的 SSH 突然无法连接。
本例使用下面的信息：
| 项目 | 示例值 |
|---|---|
| 交换机 | HQ-Access-01 |
| 管理 IPv4 地址 | 192.168.100.2 |
| 运维电脑 IPv4 地址 | 192.168.100.10 |
| SSH 端口 | 22222 |
| 高危端口 ACL | 3100 |
| QoS 策略 | anti_wana |
示例地址不能直接用于生产网络。
二、当时配置的高危端口封禁策略
这套策略封禁的端口包括：
| 端口 | 协议 | 常见用途 |
|---|---|---|
135 |
TCP、UDP | Windows RPC |
137 |
TCP、UDP | NetBIOS 名称服务 |
138 |
TCP、UDP | NetBIOS 数据报服务 |
139 |
TCP、UDP | NetBIOS 会话服务 |
445 |
TCP、UDP | Windows SMB |
3389 |
TCP、UDP | Windows 远程桌面 |
原策略的主体如下：
<HQ-Access-01> system-view
# 创建 IPv4 高级 ACL 3100。
[HQ-Access-01] acl advanced 3100
# 匹配需要封禁的 TCP 目的端口。
[HQ-Access-01-acl-ipv4-adv-3100] rule 5 deny tcp destination-port eq 445
[HQ-Access-01-acl-ipv4-adv-3100] rule 10 deny tcp destination-port eq 135
[HQ-Access-01-acl-ipv4-adv-3100] rule 15 deny tcp destination-port eq 137
[HQ-Access-01-acl-ipv4-adv-3100] rule 20 deny tcp destination-port eq 138
[HQ-Access-01-acl-ipv4-adv-3100] rule 25 deny tcp destination-port eq 139
# 匹配需要封禁的 UDP 目的端口。
[HQ-Access-01-acl-ipv4-adv-3100] rule 30 deny udp destination-port eq 445
[HQ-Access-01-acl-ipv4-adv-3100] rule 35 deny udp destination-port eq 135
[HQ-Access-01-acl-ipv4-adv-3100] rule 40 deny udp destination-port eq 137
[HQ-Access-01-acl-ipv4-adv-3100] rule 45 deny udp destination-port eq 138
[HQ-Access-01-acl-ipv4-adv-3100] rule 50 deny udp destination-port eq 139
# 后来增加的远程桌面端口规则。
[HQ-Access-01-acl-ipv4-adv-3100] rule 55 deny udp destination-port eq 3389
[HQ-Access-01-acl-ipv4-adv-3100] rule 60 deny tcp destination-port eq 3389
[HQ-Access-01-acl-ipv4-adv-3100] quit
# 创建流分类，并使用 ACL 3100 识别上述流量。
[HQ-Access-01] traffic classifier anti_wana operator and
[HQ-Access-01-classifier-anti_wana] if-match acl 3100
[HQ-Access-01-classifier-anti_wana] quit
# 创建流行为，丢弃匹配的报文。
[HQ-Access-01] traffic behavior anti_wana
[HQ-Access-01-behavior-anti_wana] filter deny
[HQ-Access-01-behavior-anti_wana] quit
# 把流分类和流行为组合成 QoS 策略。
[HQ-Access-01] qos policy anti_wana
[HQ-Access-01-qospolicy-anti_wana] classifier anti_wana behavior anti_wana
[HQ-Access-01-qospolicy-anti_wana] quit
在 QoS 策略中，ACL 用来识别流量，真正执行丢弃的是流行为中的 filter deny。
这套端口规则没有包含 SSH 使用的 22222。当时看这份 ACL，我怎么也无法把它和 SSH 故障联系起来，这也是这个问题比较隐蔽的地方。
三、当时的策略应用方式
当时在每个端口上都配置了下面两条命令：
[HQ-Access-01] interface GigabitEthernet 1/0/1
# 对进入端口的流量应用策略。
[HQ-Access-01-GigabitEthernet1/0/1] qos apply policy anti_wana inbound
# 对离开端口的流量也应用同一策略。
[HQ-Access-01-GigabitEthernet1/0/1] qos apply policy anti_wana outbound
其他物理端口也进行了相同配置。随后又在全局视图执行：
# 对所有接口的入方向应用同一策略。
[HQ-Access-01] qos apply policy anti_wana global inbound
# 对所有接口的出方向也应用同一策略。
[HQ-Access-01] qos apply policy anti_wana global outbound
全局策略本来就会覆盖所有接口，但我当时没有意识到这一点，认为接口和全局都配置会更稳妥。
不同设备的 QoS 和 ACL 硬件资源不同，对全局出方向策略和接口出方向策略的支持也可能不同。有些命令可能无法下发，资源不足时也可能只有部分策略成功下发。
四、先按常见原因排查
1. 从运维电脑检查
SSH 突然无法连接时，我先按平常的思路检查管理地址、端口和客户端：
# 确认交换机管理地址是否可以到达。
ping 192.168.100.2
# 检查实际使用的 SSH 端口。
Test-NetConnection 192.168.100.2 -Port 22222
# 使用原来的账号和端口重新连接。
ssh -p 22222 netops_hq01@192.168.100.2
运维电脑的地址、网络路径和 SSH 命令都没有变化，客户端也没有调整。以前就是用这条命令登录，现在却连不上，因此我没有发现运维电脑一侧的问题。
2. 通过 Console 检查交换机
SSH 已经不可用，只能先通过 Console 登录。进入设备后，我先确认 SSH 配置没有变化：
# 查看 SSH 服务是否开启以及监听端口。
<HQ-Access-01> display ssh server status
# 查看 SSH 服务相关配置。
<HQ-Access-01> display current-configuration | include ssh server
# 查看 VTY 远程登录线路。
<HQ-Access-01> display current-configuration | section line vty
# 查看原来的管理账号。
<HQ-Access-01> display local-user user-name netops_hq01 class manage
SSH 服务是开启的，监听端口仍然是 22222，VTY、账号和 SSH 登录 ACL 也都正常。管理 VLAN、管理地址和网关逐项核对后，同样没有发现错误。
3. 排查一度陷入僵局
常见的 SSH 故障项目检查完以后，配置看起来都是正确的。我又回头检查刚配置的高危端口 ACL，但里面只有 135、137、138、139、445、3389，并没有 22222，怎么看都不像是它直接拦住了 SSH。
查到这里，我已经不知道该从哪里继续了。再看一遍账号、VTY 和 SSH 服务，得到的还是相同结果。最后只好把故障现象、SSH 配置、高危端口 ACL 和 QoS 策略整理出来，在 H3C 官方论坛发帖求助。
论坛有热心人回复提醒我，不要只盯着 ACL 里有没有 SSH 端口，还要检查 QoS 策略到底下发了多少次，以及设备还剩多少 QoS、ACL 硬件资源。看到这条回复，我才想起自己既在每个端口配置了策略，又在全局配置了一遍，排查方向也从“SSH 配错了”转到了“硬件资源是不是用完了”。
五、根据论坛回复检查策略和硬件资源
1. 查看全局策略
# 查看全局入方向应用的 QoS 策略。
<HQ-Access-01> display qos policy global inbound
# 查看全局出方向应用的 QoS 策略。
<HQ-Access-01> display qos policy global outbound
重点确认：
anti_wana是否显示在全局入方向和出方向；- 流分类和流行为是否成功下发；
- 是否出现失败或资源不足信息；
- 丢弃计数是否持续增加。
2. 查看接口策略
# 查看所有接口上的 QoS 策略。
<HQ-Access-01> display qos policy interface
# 单独查看一个接口的入方向和出方向。
<HQ-Access-01> display qos policy interface GigabitEthernet 1/0/1 inbound
<HQ-Access-01> display qos policy interface GigabitEthernet 1/0/1 outbound
这里不能只检查 1 号端口。管理流量可能从上联口、聚合成员端口或其他接入口进入，应根据现场拓扑检查实际路径上的所有接口。
3. 查看 QoS 和 ACL 资源
# 查看设备 QoS 和 ACL 硬件资源的使用情况。
<HQ-Access-01> display qos-acl resource
本次检查确认设备的 QoS 和 ACL 硬件资源已经不足，这也是后面停止继续批量下发并撤销重复策略的依据。
不同型号的输出字段会有差异，重点看剩余资源、失败信息以及策略是否成功下发，不需要照着文章寻找完全相同的输出文字。
这里说的“硬件资源不足”不是普通的 CPU 或内存不够，而是设备用来下发 QoS 和 ACL 规则的硬件表项有限。低配接入交换机可用表项较少，同一套策略在多个接口和方向重复下发，很快就可能用完。
高配交换机的硬件表项通常更多，同样规模的策略一般不会出现这个问题。不过配置量足够大时，资源仍有可能耗尽，所以最终还是要以设备显示的实际资源为准。
结合前面的检查，故障原因已经比较清楚：
- SSH 服务、账号、VTY、管理网络和 SSH 登录 ACL 都正常；
- 高危端口 ACL 没有直接匹配 SSH 的
22222； - 同一套 QoS 策略同时应用到各接口双向和全局双向；
display qos-acl resource确认硬件资源不足；- 撤销端口上的重复策略并释放资源后，SSH 恢复。
因此，最终原因不是 SSH 配置错误，也不是 ACL 直接封禁了 SSH，而是 QoS 策略重复、大范围下发后耗尽了硬件资源。
这也解释了为什么相同策略放在高配交换机上可能一直正常，放在低配接入交换机上却出现异常：两台设备能容纳的 QoS 和 ACL 硬件表项并不相同，不能只根据命令是否执行成功判断策略是否适合当前设备。
六、逐层撤销并验证
处理这种故障时，我不会一上来删除 ACL 和整套 QoS 策略。先撤销重复的应用位置，每做一步就测试一次 SSH，这样才能知道问题出在哪一层。
1. 先撤销端口策略
<HQ-Access-01> system-view
# 下面以一个端口为例，其他已经应用策略的端口也要逐个处理。
[HQ-Access-01] interface GigabitEthernet 1/0/1
# 取消端口入方向的策略。
[HQ-Access-01-GigabitEthernet1/0/1] undo qos apply policy anti_wana inbound
# 取消端口出方向的策略。
[HQ-Access-01-GigabitEthernet1/0/1] undo qos apply policy anti_wana outbound
[HQ-Access-01-GigabitEthernet1/0/1] quit
不能只撤销 1 号端口。应通过 display qos policy interface 找出所有应用了 anti_wana 的端口，批量撤销接口级策略，然后再检查一次硬件资源并测试 SSH：
# 测试交换机实际使用的 SSH 端口。
Test-NetConnection 192.168.100.2 -Port 22222
# 使用原来的账号登录。
ssh -p 22222 netops_hq01@192.168.100.2
本次撤销各端口上的重复策略后，硬件资源得到释放，SSH 随后恢复。到这里我才确认，前面反复检查的 SSH 配置确实没有问题，真正的问题是同一套策略下发了太多次。
全局策略已经覆盖所有接口，不需要再在每个端口重复应用。
2. 再核对全局策略
SSH 恢复后，再确认全局策略是否正常下发，以及设备是否还有足够资源：
# 确认全局策略的下发和匹配情况。
<HQ-Access-01> display qos policy global inbound
<HQ-Access-01> display qos policy global outbound
# 确认端口上不再重复应用同一策略。
<HQ-Access-01> display qos policy interface
# 确认硬件资源已经释放。
<HQ-Access-01> display qos-acl resource
如果全局策略已经成功下发、封禁效果正常、SSH 也恢复，就保留全局策略，不再配置接口级策略。如果具体型号不支持全局某个方向，才根据设备能力改成接口级应用，不能把两种方式叠加使用。
七、调整后的应用方式
这套策略需要继续使用时，本例保留全局应用方式，同时删除所有端口上的重复配置：
# 全局应用后，不再到每个物理端口重复配置。
[HQ-Access-01] qos apply policy anti_wana global inbound
[HQ-Access-01] qos apply policy anti_wana global outbound
先确认以下项目：
- SSH 仍然可以正常登录；
- 办公电脑的正常业务不受影响；
- 目的端口
135、137、138、139、445、3389的测试流量被丢弃； display qos policy global显示全局策略成功下发；- 设备的 QoS 和 ACL 资源还有余量。
测试没有问题后，保持一种应用方式即可。不要同时在所有接口和全局重复下发。
八、验证方法
1. 验证 SSH
# 确认 SSH 端口可以建立 TCP 连接。
Test-NetConnection 192.168.100.2 -Port 22222
# 实际登录交换机。
ssh -p 22222 netops_hq01@192.168.100.2
登录后查看当前会话：
<HQ-Access-01> display ssh server session
2. 验证策略范围
# 确认 anti_wana 全局策略正常保留。
<HQ-Access-01> display qos policy global inbound
<HQ-Access-01> display qos policy global outbound
# 确认各物理端口不再重复应用 anti_wana。
<HQ-Access-01> display qos policy interface
# 检查 ACL 内容没有被误删。
<HQ-Access-01> display acl 3100
# 再次检查硬件资源。
<HQ-Access-01> display qos-acl resource
验证全部通过后再保存：
<HQ-Access-01> save force
九、Comware V5 配置
我当时参考的原始配置使用了 Comware V5 常见的 acl number 3100 写法。V5 创建 ACL、流分类、流行为和 QoS 策略的配置如下：
<HQ-Access-01> system-view
# Comware V5 创建高级 ACL。
[HQ-Access-01] acl number 3100
[HQ-Access-01-acl-adv-3100] rule 5 deny tcp destination-port eq 445
[HQ-Access-01-acl-adv-3100] rule 10 deny tcp destination-port eq 135
[HQ-Access-01-acl-adv-3100] rule 15 deny tcp destination-port eq 137
[HQ-Access-01-acl-adv-3100] rule 20 deny tcp destination-port eq 138
[HQ-Access-01-acl-adv-3100] rule 25 deny tcp destination-port eq 139
[HQ-Access-01-acl-adv-3100] rule 30 deny udp destination-port eq 445
[HQ-Access-01-acl-adv-3100] rule 35 deny udp destination-port eq 135
[HQ-Access-01-acl-adv-3100] rule 40 deny udp destination-port eq 137
[HQ-Access-01-acl-adv-3100] rule 45 deny udp destination-port eq 138
[HQ-Access-01-acl-adv-3100] rule 50 deny udp destination-port eq 139
[HQ-Access-01-acl-adv-3100] rule 55 deny udp destination-port eq 3389
[HQ-Access-01-acl-adv-3100] rule 60 deny tcp destination-port eq 3389
[HQ-Access-01-acl-adv-3100] quit
[HQ-Access-01] traffic classifier anti_wana operator and
[HQ-Access-01-classifier-anti_wana] if-match acl 3100
[HQ-Access-01-classifier-anti_wana] quit
[HQ-Access-01] traffic behavior anti_wana
[HQ-Access-01-behavior-anti_wana] filter deny
[HQ-Access-01-behavior-anti_wana] quit
[HQ-Access-01] qos policy anti_wana
[HQ-Access-01-qospolicy-anti_wana] classifier anti_wana behavior anti_wana
[HQ-Access-01-qospolicy-anti_wana] quit
# 只在确认需要限制的接入口入方向应用。
[HQ-Access-01] interface GigabitEthernet 1/0/1
[HQ-Access-01-GigabitEthernet1/0/1] qos apply policy anti_wana inbound
Comware V5 不同型号对全局 QoS 和出方向策略的支持差异较大。本文只保留已明确的接口入方向应用方式，不把全局双向配置作为通用做法。
十、小结
这次故障最容易产生的误解，是看到 SSH 在配置封禁策略后失效，就认为 ACL 中一定封禁了 SSH 端口。实际上，ACL 3100 只匹配 135、137、138、139、445、3389，没有匹配 SSH 使用的 22222。
真正原因是同一套 QoS 策略已经配置到每个端口的入方向和出方向，又在全局重复应用，最终造成设备的 QoS 和 ACL 硬件资源不足。通过 Console 先撤销各端口上的重复策略、释放资源后，SSH 恢复正常，全局策略继续保留。
这种情况主要出现在 QoS 和 ACL 硬件表项较少的低配交换机上。高配交换机资源更多，同样规模的策略一般不会触发，但配置后仍应检查资源，不能把“配置更高”当成绝对不会耗尽。
高危端口封禁策略使用全局方式后，就不要再逐个接口重复应用。配置完成后还要检查正常业务、SSH 和硬件资源，不能只验证被封禁的端口。
这个故障的隐蔽之处在于，SSH 的所有配置都正确，高危端口 ACL 里也没有 SSH 端口。没有论坛回复的提醒，很容易一直围绕账号、VTY 和 ACL 规则反复检查。遇到常规检查全部正常、现场已经没有新思路时，把完整现象、近期变更和检查结果整理后向官方技术社区或 H3C 技术支持求助，也是正常的排障方法。
完整配置汇总
下面汇总调整后的 Comware V7 示例。ACL 编号、接口和应用范围必须按现场规划修改。
<HQ-Access-01> system-view
# 创建高危端口 ACL。
[HQ-Access-01] acl advanced 3100
[HQ-Access-01-acl-ipv4-adv-3100] rule 5 deny tcp destination-port eq 445
[HQ-Access-01-acl-ipv4-adv-3100] rule 10 deny tcp destination-port eq 135
[HQ-Access-01-acl-ipv4-adv-3100] rule 15 deny tcp destination-port eq 137
[HQ-Access-01-acl-ipv4-adv-3100] rule 20 deny tcp destination-port eq 138
[HQ-Access-01-acl-ipv4-adv-3100] rule 25 deny tcp destination-port eq 139
[HQ-Access-01-acl-ipv4-adv-3100] rule 30 deny udp destination-port eq 445
[HQ-Access-01-acl-ipv4-adv-3100] rule 35 deny udp destination-port eq 135
[HQ-Access-01-acl-ipv4-adv-3100] rule 40 deny udp destination-port eq 137
[HQ-Access-01-acl-ipv4-adv-3100] rule 45 deny udp destination-port eq 138
[HQ-Access-01-acl-ipv4-adv-3100] rule 50 deny udp destination-port eq 139
[HQ-Access-01-acl-ipv4-adv-3100] rule 55 deny udp destination-port eq 3389
[HQ-Access-01-acl-ipv4-adv-3100] rule 60 deny tcp destination-port eq 3389
[HQ-Access-01-acl-ipv4-adv-3100] quit
# 创建流分类。
[HQ-Access-01] traffic classifier anti_wana operator and
[HQ-Access-01-classifier-anti_wana] if-match acl 3100
[HQ-Access-01-classifier-anti_wana] quit
# 创建丢弃流行为。
[HQ-Access-01] traffic behavior anti_wana
[HQ-Access-01-behavior-anti_wana] filter deny
[HQ-Access-01-behavior-anti_wana] quit
# 创建 QoS 策略。
[HQ-Access-01] qos policy anti_wana
[HQ-Access-01-qospolicy-anti_wana] classifier anti_wana behavior anti_wana
[HQ-Access-01-qospolicy-anti_wana] quit
# 全局应用策略，不再在各物理端口重复应用。
[HQ-Access-01] qos apply policy anti_wana global inbound
[HQ-Access-01] qos apply policy anti_wana global outbound
[HQ-Access-01] return
# 检查策略、ACL和硬件资源。
<HQ-Access-01> display qos policy global inbound
<HQ-Access-01> display qos policy global outbound
<HQ-Access-01> display qos policy interface
<HQ-Access-01> display acl 3100
<HQ-Access-01> display qos-acl resource
# SSH和封禁效果都验证通过后再保存。
<HQ-Access-01> save force