管理面被 ACL 锁死
给远程登录绑管理 ACL 时把自己所在的网段挡在外面，是最经典的自锁：所有能远程连设备的人一起被拒，只能赶到机房接 Console。这类变更的预防成本极低、恢复成本极高，做法是在规则里先放行当前管理网段与跳板机地址，并留一条临时通道，改完立即用新会话验证。
基本信息
| 适用平台 | 华为 VRP、H3C Comware（user-interface vty）、思科 IOS（line vty） |
|---|---|
| 绑定位置 | 华为与 H3C 在 VTY 用户界面视图下绑定 ACL，思科用 access-class 绑定 vty |
| 常见错误 | ACL 未放行管理网段、方向写反、只允许 SSH 而 SSH 尚未就绪 |
| 自救通道 | Console 或带外管理网口，二者至少保证一个可用 |
| 预防动作 | 变更前放行管理网段与跳板机，变更后先开新会话验证再退出 |
自锁原因与预防
| 原因 | 表现 | 预防做法 |
|---|---|---|
| 未放行管理网段 | 所有远程登录被拒 | 把管理网段与跳板机地址写进规则并放在前面 |
| ACL 方向写反 | 策略不生效或误拦 | 确认方向后再绑定，先在测试设备验证 |
| 只允许 SSH 但 SSH 未就绪 | 远程通道全部断开 | 在 Console 会话里先验证 SSH 能登录成功 |
| 规则顺序错误 | 部分人能连、部分人被拒 | 分级放行，按跳板、运维、监控逐条验证 |
| 忘记带外可达性 | 自锁后只能派人到机房 | 保留带外管理或现场值守，缩短恢复时间 |
典型使用场景
- 安全整改要求限制设备管理来源，需要绑定管理 ACL
- 设备刚上线还没配跳板机，容易把管理网段漏掉
- 割接期间变更管理策略，需要保留临时通道兜底
- 多人在不同办公网段运维，ACL 需要分级放行
- 自锁后到场用 Console 恢复，需要知道从哪里解除绑定
华为 VRP 与 H3C Comware
华为 VRP 与 H3C Comware
display current-configuration | include acl # 确认是否有管理 ACL 绑定
user-interface vty 0 4
display this # 看当前绑定与协议
acl 2000 inbound # 绑定
undo acl 2000 inbound # 自锁后解除绑定思科 IOS
思科 IOS
show running-config | include access-class # 先确认绑了什么
show line vty 0 4 # 看线路状态
line vty 0 4
no access-class 10 in # 解除入方向绑定
access-class 20 in # 重新绑定合规的 ACL
transport input ssh # 只允许 SSH 时确认 ssh 已可用修复入口都在用户线配置块：华为与 H3C 是 user-interface vty 0 4，思科是 line vty 0 4。Console 登录后先 display this / show running-config 看清实际绑定，再解除，避免连错方向把正常策略一起删掉。
变更管理 ACL 前，规则里必须显式放行当前管理跳板与办公网段；改完不要急着退出现有会话，先用新窗口验证能登录，确认无误再退出，保留的旧会话就是最后的兜底。