Linux防火墙：iptables规则持久化

理解 iptables 规则与持久化机制

iptables 的规则默认仅存在于 Linux 内核的 Netfilter 框架内存中，系统重启后所有动态添加的规则将彻底丢失。持久化的核心机制是将内存中的规则导出为静态文本文件，并在系统启动早期由初始化脚本或服务重新加载。在 Debian/Ubuntu 体系中，通常依赖 iptables-persistent 或 netfilter-persistent 软件包，它们会在 /etc/iptables/rules.v4 和 /etc/iptables/rules.v6 中维护规则，并通过 systemd 服务在 sysinit.target 阶段调用 iptables-restore 完成恢复。而在 RHEL/CentOS 7 及更早版本中，规则通常保存在 /etc/sysconfig/iptables，由 iptables 服务在启动时读取。理解这一差异是避免跨发行版配置失效的前提，因为不同发行版的启动流程与服务命名存在本质区别，直接混用会导致规则无法在引导阶段被正确注入内核。

保存当前 iptables 规则并配置开机恢复

要实现规则持久化，首先需使用 iptables-save > /etc/iptables/rules.v4 命令将当前生效的 IPv4 规则完整导出至指定路径。对于 Debian/Ubuntu 系统，推荐安装 netfilter-persistent 与 iptables-persistent 包，安装过程中系统会提示是否保存当前规则，确认后会自动生成规则文件。随后执行 systemctl enable netfilter-persistent 确保服务开机自启。在 RHEL/CentOS 环境中，可直接将规则保存至 /etc/sysconfig/iptables，并通过 systemctl enable iptables 激活服务。若使用较新的 firewalld 或 nftables 替代方案，需注意底层兼容层可能拦截 iptables 命令，此时应通过 iptables-legacy-save 明确指定传统后端。操作完成后，务必核对文件权限（通常为 600）与属主（root），防止未授权篡改导致启动加载失败。

重启后验证规则是否真正生效

规则保存后，必须通过重启验证其是否真正恢复。重启前，执行 iptables -L -n -v 查看当前链的包计数与策略，或使用 iptables -S 获取可执行的规则列表。重启完成后，再次运行相同命令，对比输出内容是否一致。更严谨的做法是使用 iptables-save | diff - /etc/iptables/rules.v4 进行逐行比对，确保无遗漏或格式错乱。此外，仅依赖命令行输出不足以证明策略生效，应结合实际网络测试：例如在规则中放行 TCP 80 端口后，使用 curl -I http://<服务器IP> 或 nc -zv <服务器IP> 80 验证连通性；若配置了 DROP 策略，可通过 telnet 测试被禁端口是否返回 Connection refused 或超时。只有命令输出与实际网络行为双重吻合，才能确认持久化配置已完整落地。

排查持久化失败与远程锁死风险

持久化失败通常源于规则未正确导出、服务未启用或路径不匹配。排查时应首先检查 systemctl status netfilter-persistent 或 iptables 服务的运行状态与日志，确认启动阶段是否报 iptables-restore 语法错误。IPv4 与 IPv6 规则混淆是另一高频问题，需确保 rules.v4 仅包含 IPv4 规则，rules.v6 仅包含 IPv6 规则，避免混用导致加载中断。在远程服务器操作时，误封 SSH 端口（默认 22）将直接导致连接断开且无法恢复。安全做法是：在添加 DROP 策略前，务必先执行 iptables -A INPUT -p tcp --dport 22 -j ACCEPT，并配合 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 放行已建立连接。更稳妥的方案是使用 at now + 5 minutes 设置定时清除规则，或在修改前开启 screen/tmux 会话，确保即使 SSH 断开也能通过控制台回滚配置。