客户端更新后 VPN 就断了？先比对协商过程

更新会替换解析你的配置文件、并负责协商隧道的那个组件。升级后的第一次失败是对某项具体改动的证据，而不是对该版本的判决。把这条报错连同版本号和时间戳一起保存下来，是你在重装任何东西之前能做的最有价值的一步。

这类断裂大多由两种机制造成。把它们区分开，就是这项工作的核心。

协商在你的脚下改了什么

OpenVPN会协商数据信道的加密算法，而不是从单条指令里直接取值，而控制这场协商的选项在不同版本之间改过含义。为旧客户端写的配置文件可以连上，随后却无法在数据信道上达成一致，表现为连接中断，而不是一条清晰的配置错误。新版本还会收紧或取消旧有行为，并为尚未迁移的对端提供兼容模式。因此一次升级可能从未改动文件的任何一个字节，却让原本可用的配置文件失效。

对客户端的影响是不对称的。控制信道起来了，认证也成功了，之后隧道才死掉——这是协商不一致的特征，而不是配置文件被拒。

在推测服务器之前，先读一下已安装的版本。那个字符串是本地事实，你不需要向任何人要访问权限就能核对。

配置文件可能解析成功，却表达了别的意思

一条能通过解析的指令，未必还做着作者当初想做的事。选项可能为了兼容而被接受然后忽略，可能被改名，可能只在比以前更窄的情形下生效。由于什么都不报错，配置文件看起来是对的，底下的行为却已经变了。正是这种沉默，让这类回归代价高昂。

先问清楚哪些行真正决定了协商结果，再拿它们对照你当前所运行版本的文档。这个比对很短，而修正与回滚的差别就在这里。

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

平台也在同一时间动了

客户端版本很少单独到来。一次操作系统更新、一个如今要求明确授权的权限提示，或一条下发到设备上的管理策略，都可能落在同一周里，制造出一场被归咎于客户端的故障。移动平台还多一层：应用向系统申请隧道，而由系统决定这条隧道能路由什么。

把这些改动单独记在时间线上。当认证成功但路由或域名解析失败时，值得关注的是握手之后的阶段，而削弱证书校验根本触不到它。

重新测试当初触发报告的那个事件

复现原始顺序，而不是简化版：初次连接、失败的那个应用，以及网络变化后一次普通的重新连接。一条在测试条件下能起来、却仍在重连路径上掉线的隧道并没有被修好，而这个差异通常标出了真正缺陷所在。漏掉重连步骤的报告，关掉的是仍然开着的缺陷。

与其整体回滚，不如通过已验证的渠道拿到运营商支持的配置文件或厂商的修正。大范围降级也会把该更新携带的安全修复一并退回，这笔交换很少值得一条能用的连接。