端点地址变化时的 UFW VPN 例外

客户端尝试重连，机器却什么都发不出去，而同一份配置上周还能用。端点主机名现在解析到另一个地址，出站例外仍写着旧的那个。仅这一条过期的放行，就足以让正常工作的终止开关变成彻底断网，而桌面上的每一个状态指示器都显示不出来。修复是一套小型流程，而不是改一行。

隧道重连之后，什么都出不去

一条指名目标地址的出站规则是某一刻的快照，而 DNS 应答不是。当服务商轮换地址时，客户端发往新对端的报文匹配不上任何规则，被默认拒绝丢弃。随后客户端报告超时，看起来像服务器故障，而不是防火墙故障。

把公开查询返回的地址钉死，今天能用，明天就坏。那是一次性改动，不是维护策略。

描述你真正想要的例外

先把规则需要的四个值写下来：获批的端点名称或地址集、传输协议、目标端口，以及报文离开所经过的接口。四项都属于这条放行，其中任何一项出错，规则看上去仍然合理。三项正确的规则，失败方式和四项全错的规则完全一样。在敲命令之前先把它们写下来，因为规则的好坏取决于背后的说明。

下面的命令展示了有线链路上一个 IPv4 UDP 端点的形态。请把两个值换成你对照部署核实过的值。

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

这条放行并不授权同一端口上的任意目标，不创建监听，也不覆盖 TCP。UFW 手册页说明了地址、接口与协议如何收窄规则，而这种收窄正是关键。

作为一套流程来刷新

把例外当成有归属和迁移的资源，而不是某个人记得去执行的命令。先从部署自己的解析器和端点清单里取出候选，并在隧道存在之前刻意规定这个名字如何解析。然后在触碰规则集之前，按预期的协议、端口和地址族校验候选。

先安装新的窄放行并确认它已加载，因为让客户端去用一个防火墙仍然封堵的地址，会产生看起来像服务器故障的错误。变更期间不要动无关规则。

通过客户端受支持的重连路径观察它的迁移，并确认它选了哪个远端地址。只更新 DNS 并不会搬动已有的套接字，而端点保持设置可能让客户端在记录变更很久之后仍留在旧对端上。

最后有意退役这条过期放行，在旧会话仍然活跃时容许已批准的重叠窗口。过早删除旧条目会带来短暂断网；永远留着则留下一条谁也解释不清的放行。

有意退役旧放行

删除才是风险最集中的地方，因为旧规则是目前唯一还在工作的东西。如果候选安装失败，就不要继续，也不要删除仍在承载流量的条目。如果删除本身失败，就把这条过期放行记为过期，而不是宣称策略已是最新。

当链路上行从以太网换成 Wi-Fi、传输协议改变，或某个服务在多个地址间轮换时，把整套复核重做一遍。针对接口的规则本应在网络变更后停止匹配，这种行为是正确的，即使它看起来像退化。

随后用无害流量证明这份约定。获批端点在配置期间必须可达，受保护的应用在连接后必须工作，无关的直接流量在中断期间必须保持封锁。要覆盖两个地址族，并包含一次故意失败的更新尝试，因为只改一次固定地址就连上的连接，证明不了上述任何一种情况。