昨天还能正常 SSH 连接今天失败️ 分步排查与修复1. 先恢复网卡与网络在虚拟机内执行以下命令重新启用网卡并获取 IP# 启用 ens33 网卡 sudo ip link set ens33 up # 向 DHCP 服务器申请 IP恢复昨天的网络配置 sudo dhclient ens33 # 验证 IP 是否恢复 ip addr show ens33✅ 正常情况下执行后会看到192.168.190.130或同网段 IP 重新出现。2. 检查 SSH 服务状态IP 恢复后仍连不上大概率是 SSH 服务未启动# 查看 SSH 服务状态 systemctl status sshd # 如果服务停止手动启动 sudo systemctl start sshd # 设置开机自启避免下次重启又失效 sudo systemctl enable sshd3. 检查防火墙是否拦截CentOS/RHEL 系默认防火墙可能拦截 22 端口33# 查看当前防火墙规则 sudo firewall-cmd --list-all # 永久放行 SSH 服务 sudo firewall-cmd --permanent --add-servicessh sudo firewall-cmd --reload问题根源防火墙区域不匹配从输出可以看到网络接口ens33被分配到了docker区域但你当前操作的是默认的public区域。public区域虽然放行ssh服务但实际生效的docker区域并未放行 22 端口这就是 SSH 连接被拦截的直接原因。✅ 修复方案1. 查看当前活跃区域firewall-cmd --get-active-zones确认ens33确实在docker区域。2. 在docker区域放行 SSH 服务# 永久放行 SSH 到 docker 区域 sudo firewall-cmd --permanent --zonedocker --add-servicessh # 重新加载防火墙规则 sudo firewall-cmd --reload3. 验证配置是否生效# 查看 docker 区域的规则 sudo firewall-cmd --zonedocker --list-all输出中应包含services: ssh表示 22 端口已在docker区域放行。问题解释Docker 自动改写防火墙规则ens33被分配到docker防火墙区域不是手动操作导致的而是Docker 服务启动时的自动行为背后是 Docker 为了保障容器网络安全和隔离性的设计逻辑1. Docker 改写防火墙区域的底层逻辑Docker 安装后会做两件核心操作创建专属防火墙区域自动在firewalld中创建docker区域优先级高于默认的public区域绑定物理网卡到 docker 区域Docker 启动时会检测系统的物理网卡如ens33并自动将其划入docker区域。这么做的目的是隔离容器网络和宿主机物理网络避免容器网络请求直接穿透到宿主机统一管理容器相关的端口放行 / 拦截规则不影响宿主机默认的public区域规则。2. 为什么 “昨天能用今天不行”结合我自身的场景初始状态Docker 未启动 / 虚拟机未重启时ens33可能还在public区域SSH 规则生效触发点虚拟机重启后Docker 随系统自动启动 → 检测到ens33网卡 → 自动将其划入docker区域结果ens33脱离public区域你之前在public区域放行的 SSH 规则失效而docker区域默认拦截 22 端口 → SSH 连接失败。4. 避免后续出现问题方案 1在 docker 区域永久放行 SSH推荐# 永久放行 SSH 到 docker 区域重启后仍生效 firewall-cmd --permanent --zonedocker --add-servicessh firewall-cmd --reload方案 2将 ens33 固定到 public 区域适合不用 Docker 容器网络的场景# 强制将 ens33 绑定到 public 区域 firewall-cmd --permanent --zonepublic --add-interfaceens33 # 禁止 Docker 自动修改区域可选 firewall-cmd --permanent --zonepublic --change-interfaceens33 firewall-cmd --reload总结ens33被划入docker区域是Docker 启动时的自动行为目的是隔离容器和宿主机网络连接失败的核心是网卡所属区域变了但 SSH 放行规则还停留在原区域规则失效解决关键是要么在docker区域放行 SSH要么把网卡固定回public区域。