H3C交换机配置高危端口封禁后SSH失效排查实例

这是“H3C交换机中小企业运维实战”专栏的第 17 篇，也是我实际遇到的一次故障。

一台接入交换机原来可以正常通过 SSH 管理。配置高危端口封禁策略后，SSH 突然失效，但 ACL 中并没有封禁 SSH 使用的端口。最后通过 Console 检查发现，真正原因是同一套 QoS 策略在各接口和全局重复下发，耗尽了设备的 QoS、ACL 硬件资源。

本文以 H3C S5570S 和 Comware V7 的命令格式整理。地址、接口和策略名称都是示例，使用时要换成现场信息。

一、故障现象

公司要求交换机封禁 135、137、138、139、445、3389 等高危端口。当时在每个物理端口的入方向和出方向都应用了策略，又在全局入方向和出方向应用了一遍。

配置完成后，原来正常的 SSH 突然无法连接：

高危端口 ACL 没有包含 22222，因此一开始很容易误以为 QoS 策略与 SSH 故障无关。

二、先检查常见的 SSH 问题

先从运维电脑检查网络和实际 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 已经无法使用，只能通过 Console 登录交换机检查：

# 查看 SSH 服务状态和监听端口。
<HQ-Access-01> display ssh server status

# 查看 SSH、VTY 和账号配置。
<HQ-Access-01> display current-configuration | include ssh server
<HQ-Access-01> display current-configuration | section line vty
<HQ-Access-01> display local-user user-name netops_hq01 class manage

本次检查确认 SSH 服务、端口、VTY、账号、登录 ACL、管理 VLAN 和网关都没有变化。

三、检查 QoS 策略的应用范围

常见项目都正常时，不要只盯着 ACL 中有没有 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 policy interface GigabitEthernet 1/0/1 inbound
<HQ-Access-01> display qos policy interface GigabitEthernet 1/0/1 outbound

本次发现同一个 anti_wana 策略既应用在各物理端口的入、出方向，又应用在全局入、出方向。

全局策略已经覆盖接口，再逐个接口重复应用，会额外占用硬件表项。设备配置越低，可用表项通常越少。

四、确认 QoS 和 ACL 硬件资源

# 查看设备 QoS 和 ACL 硬件资源使用情况。
<HQ-Access-01> display qos-acl resource

本次检查确认设备的 QoS 和 ACL 硬件资源已经不足。

这里的资源不足不是普通 CPU 或内存不够，而是交换机用于下发 QoS、ACL 规则的硬件表项有限。即使命令执行时没有明显报错，也要继续确认策略是否完整下发以及硬件资源是否还有余量。

最终判断依据是：

五、逐步撤销重复策略

处理时不要一上来删除 ACL 和整套 QoS 策略。先通过 Console 撤销接口上的重复应用，每完成一批就重新检查资源并测试 SSH。

<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，找出所有应用了该策略的接口，再逐个撤销。

撤销后重新测试：

Test-NetConnection 192.168.100.2 –Port 22222
ssh –p 22222 netops_hq01@192.168.100.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

# 确认 ACL 没有被误删。
<HQ-Access-01> display acl 3100

最后还要验证正常办公业务、高危端口封禁效果和 SSH 登录。全部正常后再保存：

<HQ-Access-01> save force

这次故障提醒我，SSH 在安全策略调整后失效，不代表 ACL 一定直接封禁了 SSH 端口。常见 SSH 配置全部正常时，还要回头检查最近的 QoS、ACL 变更、策略下发范围和硬件资源。

网站完整版还包括原高危端口 ACL、完整排查过程、Comware V5 差异、验证方法、完整配置汇总和参考资料：

H3C交换机配置高危端口封禁后SSH失效排查实例