一次生产环境防火墙配置的真实复盘：从误判到规则重构 这次事件并未造成业务中断，但
这次事件并未造成业务中断，但其警示价值远超常规演练。它彻底修正了我一个根深蒂固的认知：任何针对生产环境的操作，无论表象多简单，都必须以事故预案的严谨度来执行。
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
以下是一次发生在生产服务器上的真实操作记录与深度反思。
起因极为常见：为一台线上生产服务器启用Linux防火墙。
环境说明：目标为一台线上生产服务器，SSH端口已修改为非默认的22端口。操作系统为麒麟系统，预装防火墙管理工具firewalld，当时处于默认禁用状态。
操作目标明确：规范服务器防火墙配置，收敛不必要的端口暴露。当时我认为这只是几条命令的常规操作，几分钟即可完成。
通过SSH成功连接至服务器，会话状态正常。
确认firewalld已安装但未启用。
检查防火墙默认放行的服务与端口。从下图可见，系统已默认放通“ssh”服务。
看到此配置后，我误判SSH连接已受保护。随即执行了启动命令：
systemctl start firewalldSSH连接瞬间中断。无错误提示，终端仅显示连接断开信息：
第一反应是生理性的：心跳加速，手心出汗。本能地尝试重连。
结果直接而明确：
No route to host至此，一个致命疏漏才清晰暴露：我是在唯一的SSH会话中，执行了防火墙规则的重载操作。
冷静后，开始复盘整个故障链。
答案是：并未生效。
虽然默认配置包含“ssh”服务，但忽略了一个关键细节：firewalld中“ssh”服务的默认定义仅放行22端口。其配置本质为：
而我服务器的实际SSH端口是：
SSH Port = 10022结论明确：防火墙生效瞬间，非22端口的SSH连接被立即阻断。
这是firewalld的核心工作机制。执行reload时，所有规则会重新加载并立即生效，未明确放行的端口会被瞬间拦截，当前活跃的SSH会话因此中断。这是设计特性，而非缺陷。
应在启动防火墙之前，于对应的zone配置文件（例如`/etc/firewalld/zones/public.xml`）中，添加对实际端口的精确放行规则：
事故本质总结：我“假定”SSH服务已被放行，而防火墙实际仅放行了默认的22端口。
ss -lntp | grep ssh
# 或
grep Port /etc/ssh/sshd_config假设确认端口为10022。
firewall-cmd --add-port=10022/tcp --permanent添加后必须验证：
firewall-cmd --list-ports确保输出包含：
10022/tcp这是一条安全底线。在操作可能影响远程连接的防火墙规则前，一个审慎的做法是设置一个定时任务，例如在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顺序错配，即是生产事故。
这次有惊无险的经历，代价是一次肾上腺素飙升，但换来的是运维习惯的彻底重构：所有生产环境操作，无论复杂度高低，都必须以潜在故障为前提进行推演和防护。如果你也需要在生产环境操作防火墙，希望这篇复盘能帮你规避一次相同的连接危机。
菜鸟下载发布此文仅为传递信息，不代表菜鸟下载认同其观点或证实其描述。
