一次生产环境防火墙操作的真实复盘：从“心跳加速”到“彻底改掉坏习惯”
这次事故虽然没有引发业务中断，但它带来的价值远超一次普通的故障演练。它彻底扭转了我一个根深蒂固的观念：所有在生产环境里“看起来很简单”的操作，都必须当成一次潜在的事故来严肃对待。
这不是技术演示，也不是段子分享。下面要讲的，是一次真实发生在生产服务器上的操作与反思。
事情的起因简单到不能再简单：为一台生产服务器开启Linux防火墙。
1. 事故背景
先交代一下环境：一台线上生产服务器，SSH端口并非默认的22。操作系统是麒麟系统，预装的防火墙管理工具是firewalld，当时处于默认未启用的状态。
操作目标非常单纯：规范服务器的防火墙配置，减少不必要的端口暴露。当时的我信心满满，觉得这不过是几条命令、几分钟就能搞定的小事。
2. 事故经过（真正的翻车点）
(1) ⏱ 21:06
通过SSH顺利连接到服务器，一切正常。
(2) ⏱ 21:07
确认firewalld已经安装，但尚未启用。
(3) ⏱ 21:08
开始检查防火墙默认放通了哪些服务和端口。从下图可以看到，系统已经默认放通了“ssh”服务。
看到这里，心里想的是：SSH服务都放行了，那肯定没问题了。于是，紧接着执行了启动命令：
systemctl start firewalld(4) ⏱ 21:16:02
SSH连接瞬间断开。没有报错，没有提示。终端窗口里只剩下一行冰冷的断开信息：
第一反应不是技术分析，而是纯粹的生理反应：心跳骤然加快，手心开始冒汗。下意识的第一动作就是尝试重新连接。
结果非常直接：
No route to host直到这时，一个致命的问题才清晰地浮现出来：我是在唯一的SSH连接会话里，执行了防火墙的重载操作。
3. 事故原因定位
冷静下来之后，开始复盘整个链条。
(1) 防火墙真的“放行 SSH”了吗？
答案是：没有。
虽然默认配置确实放通了“ssh”服务，但忽略了一个关键事实：firewalld中定义的“ssh”服务，默认只放行22端口。其配置本质是这样的：
而我的服务器SSH端口是：
SSH Port = 10022所以结论非常明确：防火墙生效的那一刻，非22端口的SSH连接被直接拦截。
(2) 为什么reload会立刻断线？
这是firewalld的工作机制决定的。执行reload时，它会重新加载所有规则：新规则立即生效，未放行的端口瞬间被拦截，当前的SSH会话自然也就中断了。这不是bug，而是设计如此。
(3) 正确的配置应该是什么？
应该在启动防火墙之前，就在对应的zone配置文件（例如`/etc/firewalld/zones/public.xml`）中，添加对实际端口的放行规则，像这样：
事故本质一句话总结：我“以为”放行了SSH，实际上防火墙只放行了默认的22端口。
4. 正确做法复盘（如果重来一次）
(1) 第一步：确认SSH实际监听端口
ss -lntp | grep ssh
# 或者
grep Port /etc/ssh/sshd_config假设确认端口是10022。
(2) 第二步：放行具体端口，而非笼统的服务
firewall-cmd --add-port=10022/tcp --permanent添加后务必确认：
firewall-cmd --list-ports确保输出中包含：
10022/tcp(3) 一条关键的“保命”经验
这可以算是一条生死线。在操作可能影响远程连接的防火墙规则时，一个谨慎的做法是提前设置一个定时任务，比如在5分钟后自动关闭防火墙。这样，万一因为规则错误导致无法连接，这个定时任务就能在关键时刻自动恢复访问，为补救争取时间。
*/5 * * * * systemctl stop firewalld话说回来，如果这次用的是iptables，后果可能会更严重。iptables与firewalld一个很大的不同在于，它的规则是立即生效的，没有缓冲地带。
如果当时错误地先执行了这样一条命令：
iptables -P INPUT DROP那面临的就不是SSH断线，而是服务器直接失联。使用iptables时，正确的规则顺序至关重要：
# 1. 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 2. 放行SSH端口
iptables -A INPUT -p tcp --dport 10022 -j ACCEPT
# 3. 允许本地回环通信
iptables -A INPUT -i lo -j ACCEPT
# 4. 最后，设置默认拒绝策略
iptables -P INPUT DROP顺序错一个字，就是一场事故。
5. 写在最后
这次有惊无险的经历，代价是一次“心跳加速”，但换来的是一个职业习惯的彻底修正：所有在生产环境里“看起来很简单”的操作，都必须被当成潜在的事故来对待。如果你也需要在生产环境操作防火墙，希望这篇复盘能帮你避免一次同样的“心跳时刻”。
