一次生产环境防火墙操作的真实复盘:从“心跳加速”到“彻底改掉坏习惯”
这次事故虽然没有引发业务中断,但它带来的价值远超一次普通的故障演练。它彻底扭转了我一个根深蒂固的观念:所有在生产环境里“看起来很简单”的操作,都必须当成一次潜在的事故来严肃对待。
这不是技术演示,也不是段子分享。下面要讲的,是一次真实发生在生产服务器上的操作与反思。
事情的起因简单到不能再简单:为一台生产服务器开启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. 写在最后
这次有惊无险的经历,代价是一次“心跳加速”,但换来的是一个职业习惯的彻底修正:所有在生产环境里“看起来很简单”的操作,都必须被当成潜在的事故来对待。如果你也需要在生产环境操作防火墙,希望这篇复盘能帮你避免一次同样的“心跳时刻”。
