VPN 端点允许列表：你忘记的 DNS 刷新

在防火墙例外里输入 vpn.example.com，感觉就像订阅了 DNS。实际通常是在加载时完成一次转换，此后规则只保存地址，没有任何东西刷新它们。现在有两个组件分担这项工作：负责应答的解析器和负责存储的防火墙。大多数端点故障都始于那次交接从未被设计的地方。

规则里的主机名不是实时订阅

有些工具在加载配置时解析名称；另一些保留主机名并按自己的计划重新解析；还有一些只接受地址。可见的配置很少说明是哪一种。文档示例通常假设加载时解析，所以迁移时这一差异会让人意外。在假设地址变更会被察觉之前，先阅读实现的行为，因为 一份过期的允许列表看起来和正常工作的列表一模一样 直到端点迁移为止。

即便规则写对了主机，也可能放行错误的地址。这个差距才是迷思所在，而不是拼写错误。

缓存 TTL 不是防火墙的计时器

DNS 记录带有生存时间，解析器会在该时段内缓存应答。DNS 规范 定义了这种缓存行为，但它管的是 DNS 数据，而不是防火墙独立的地址存储。较短的 TTL 不会在原本没有刷新任务的地方凭空创造任务。缓存还会发生在不止一层，因此终端看到的应答未必是防火墙看到的那个。

向实际产品提出三个问题：何时解析、结果存在哪里、什么会触发更新。如果答案只是启动时，那么长寿命会话可能比它当初被放行的地址活得更久。

dig +short vpn.example.com
resolvectl query vpn.example.com

把刷新和失败设计成同一套策略

受维护的例外需要明确答案：在客户端选择新地址之前由什么触发刷新，允许集合如何变化而不打开宽泛的临时窗口，以及何时移除过期条目。把这些答案写在规则旁边。

有意识地选择失败行为。保留旧地址可能保住会话，却留下过期许可；清空集合可能让恢复无路可走。两者都不该是失败查询的意外结果。把选定的行为写进运行手册，让下一位操作者在压力下不必即兴发挥。

引导 DNS 也要保持狭窄。对公共解析器的无条件例外，是它匹配到的一切的直连 DNS 路径，而不只是端点名称。

要证明端点变更，而不是第一次连接

如果客户端支持的管理器已经协调解析和阻断，就用它。在站点管理的 PF 主机上，保留站点的归属和恢复计划，而不是从生命周期行为不同的另一平台照搬主机名表语法。

在获得批准且无害的测试中，比较客户端选择的地址与受控变更前后的生效允许集合。覆盖查询失败、删除不再有效的条目，以及在支持时覆盖不同的地址族。目标隧道应当恢复，而不相关的直连流量仍受策略约束。首次连接成功只能证明最初的转换恰好正确。