在不丢失主机的前提下规划 OpenVPN 维护窗口

重启 VPN 服务会终止所有正在使用它的会话，因此这个窗口必须围绕沟通来安排，而不是围绕包管理器。用户需要足够的提前通知来完成敏感工作，而你需要一条不依赖你即将停掉的那条隧道的回程通道。手册里的其他内容都是为了让这两件事变得可控。只要漏掉其中任何一条，例行更新就会变成没有出口的故障。

下面的顺序是刻意的：每个阶段都会产出下一阶段需要的东西，而任何一个阶段都可以在变更开始前叫停它。

在改动之前先记录现有的服务

读已安装的单元，而不是你记忆中写过的那个：systemctl cat [email protected] 会打印单元以及所有 drop-in，systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory 会显示实际运行的内容以及以谁的身份运行。要以该单元指明的二进制为准去查询，因为从 shell 里执行 openvpn --version 可能指向另一个构建。记录配置文件路径以及它引用的每一个文件。

也要记下正在监听的套接字：ss -lunp | grep 1194 会告诉你守护进程今天占用了哪个地址和协议。如果答案与配置文件的暗示不符，那就是某个 drop-in 或环境文件在覆盖它，而升级会继承这个意外。

准备一套别人也能用的恢复套件

恢复套件必须能让同事在 03:00 没有你在场时也能用。要包含生效的配置及其引用的每个文件、由 PKI 负责人掌控的信任与吊销材料、每个客户端的分配与钩子，以及今天安装的确切软件包版本。只有一个文件名的副本算不上配置。把它存放在值班运维不依赖 VPN 就能拿到的地方。

访问控制同样适用于这套材料，因为其中含有私钥或后端凭据。不要因为软件包版本变了就重建 CA 或重新签发身份。

用真实客户端在试点监听器上演练

在独立监听器上运行候选版本，配它自己的端口与地址规划，而不是和生产实例挤在同一个套接字上。用用户实际运行的客户端引擎去连接，包括那个难缠的。检查地址分配、下发的 DNS、一个关键应用，以及一条应当保持封锁的路径。自定义钩子必须在服务真实的权限与文件系统上下文中运行，因为 root shell 并不能证明它们。

读发布说明要看行为变更，而不只是新功能。加密套件和 TLS 默认值会随版本变动，一个仍能解析的配置照样可能在握手中失败。如果升级需要改配置或证书，就把它作为单独一步，而不是塞进软件包更新里。

从隧道之外一次完成切换

从一条不经过该服务的控制台或管理网络开始这个窗口。确认用户已经被通知，并且第二位运维知道怎么回滚。由负责人执行准备好的变更，然后用 sudo systemctl restart [email protected] 重启，并用 journalctl -u openvpn-server@office -b -f 跟踪日志。只改了单元定义时，重载就够了；配置变了则需要重启进程。

预期每个客户端都会重连，也预期有些应用会话不会恢复。与那些受不了中断的业务负载协调一次干净的暂停。

接受或回滚，然后告诉用户到底改了什么

验收是一次全新登录、一次真实操作，以及限制依然生效。单元是活动的、状态行是绿的，这些只是进程层面的事实。如果窗口内没通过验收标准，就用准备好的方式回滚，而不是恢复一个文件然后祈祷；换掉的二进制或服务策略不会因为恢复配置而复原。窗口期间做过的吊销或授权变更要保留下来，别让回滚把安全工作也撤掉。

为下一位运维记录版本、配置变更和验收结果，让试点监听器退役，并告诉用户现在该用哪个配置。没有这份说明就结束的窗口，会在下次更新时被重新翻出来争论。