必须用rich-rule配置firewalld白名单，先移除--add-service=ssh全局规则，再逐条添加跳板机IP、127.0.0.1及内网管理IP的accept规则，最后reload生效。
直接在目标服务器上配置防火墙，只放行跳板机的 IP 访问 SSH 端口（默认 22），是守住内网入口最基础也最关键的一步。这不是“加个白名单”那么简单，而是要绕过 firewalld 默认服务规则的陷阱，用精确的 rich-rule 控制流量源头。
必须用 rich-rule，别碰 --add-service=ssh
firewalld 的 --add-service=ssh 是全局放行 22 端口，跟“只允许跳板机访问”完全冲突。一旦执行这条命令，等于把门敞开，后续加的白名单规则可能被忽略或失效。
- 先清理旧规则：如果之前开过 SSH 服务，运行
firewall-cmd --permanent --remove-service=ssh - 再逐条添加精准规则，例如跳板机公网 IP 是
203.0.113.50：firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.50" port port="22" protocol="tcp" accept' - 别漏掉本机回环：从服务器本地调试（如
ssh localhost）也要能连，加一条：firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="127.0.0.1" service name="ssh" accept' - 如果跳板机还有内网管理地址（比如
192.168.10.10），同样单独加一条，不能靠网段匹配
确认默认策略并重载生效
firewalld 默认 zone（通常是 public）策略是 default: deny，但这个“deny”只是对未匹配任何规则的连接静默丢弃，不是主动拒绝。所以只要没写 reject 规则，其实已经足够——关键是确保没有漏掉的 accept 规则。
- 检查当前所有规则：
firewall-cmd --permanent --list-all，确认services:里不含ssh，rich rules:里只有你刚加的那几条 - 重载配置让永久规则生效：
firewall-cmd --reload - 验证是否生效：从非跳板机 IP 尝试 SSH，应无响应或连接超时；从跳板机 IP 连接应正常
配合跳板机自身加固，形成闭环
防火墙白名单只是第一道关卡。跳板机本身必须同步收紧：
- 禁用密码登录：
PasswordAuthentication no，只认密钥认证 - 禁止 root 直接登录：
PermitRootLogin no - 跳板机的防火墙也要反向限制：只允许运维人员办公 IP 访问它的 22 端口，其他一律拒之门外
- 后端服务器的 iptables/nftables INPUT 链默认策略设为 DROP，并只允许跳板机 IP 入站，不依赖 firewalld 单一控制
云环境用安全组替代，逻辑不变
在阿里云、AWS 或腾讯云上，不用 firewalld，改用安全组实现相同效果：
- 目标服务器的安全组入方向规则，只加一条：TCP 22 端口，源 IP 填跳板机的弹性公网 IP 或 NAT 网关出口 IP
- 务必删掉“0.0.0.0/0”这种全放开的 SSH 规则
- 跳板机所在安全组也要限制出方向：只允许它访问目标服务器的 22 端口，避免横向渗透
