防火墙软件包已安装，重启后规则却消失

软件包安装得很干净，规则也测试过，可下一次重启之后网关却完全敞开。事务里没有任何一步失败；失败的是「哪些东西会持久保留」这个假设。安装防火墙工具、决定哪些规则应当存活、在正确的时机恢复它们，是三件彼此独立的事。

症状究竟在告诉你什么

重启后消失的规则集，通常有三种归属：没有人保存过它，别的东西替换了它，或者它在所依赖的对象出现之前就被恢复了。前两种在配置里看得见；第三种只体现在顺序上。这就是为什么一次重启看起来像数据丢失，而实际上是顺序问题。

先把重启之前的事实写下来：哪项服务持有这些规则，它在启动时读取的是哪个文件或数据库，以及那个来源是否曾经被写入过。没有人保存过当前在用的规则集，是一个成立且最常见的解释。

不要从重装软件包开始。

使用持久化工具之前先读懂它

Debian 的工具把持久化当作插件问题处理：每个插件知道如何写自己的规则，再由一个包装脚本去调用它们。它的保存动作记录当时加载的一切，启动动作再把那份快照读回来。两个动作都不审查自己存了什么。

那是快照，不是审查。调试会话里留下的放行、做到一半的实验，或者另一个辅助工具塞进来的宽松规则，都会和你本想保留的策略一起变成永久状态。保存状态和批准状态是两回事，只有后者需要判断。先读一遍已加载的规则集，再决定哪些行值得留下。

读清已加载的内容之后，再有意识地保存。

决定什么应当存活

有些规则属于接口的生命周期，应当随接口一起消失。另一些必须比隧道活得更久，最清楚的例子是一条在你隧道断开时 禁止客户端流量回退到物理接口 的限制。这两类需要不同的恢复触发条件，而不是共用一份快照。

把三个时刻的目标结果写下来：开机、VPN 启用、隧道断开。然后检查你选的工具能否分别表达这三种情形。一个只是重新加载静态快照的持久化包能处理第一种，却可能处理不了另外两种，因为快照根本不知道隧道状态何时改变。如果它表达不了，这个缺口属于另一个组件。

决定答案的是策略，而不是软件包。

检查恢复顺序

恢复文件并不等于掌控结果。别的管理器可能替换规则，先前的 accept 可能把它们遮住，客户端也可能在限制落地之前就开始发包。要审查启动与重连时的行为，而不只是磁盘上有没有那个保存文件。

systemctl status netfilter-persistent
iptables -S

不要以为停止持久化服务是无害的，因为软件包记录了停止时的条件性清空。在这台远程管理的网关上把 stop 或 restart 当作实验之前，先确认该服务的实际配置。一个控制台会话和一份有记录的回滚，是这项测试之前的最低要求。

顺序是运行中系统的属性，而不是磁盘上文件的属性。

分别接受三个结果

把软件包安装、已加载的规则集和实际执行的策略记成三件独立的事实。支持帖里的一个包名只能回答第一件事，而那往往是最不重要的。

nft list ruleset

然后测试一个被允许的操作和一个必须的拒绝。

如果这条拒绝在重启之后、在隧道断开之后都成立，策略就活下来了。如果它只在这两种状态之一里成立，你只是发现了顺序问题，并没有修好它。