旧 VPN 配置里的过时加密行：复制之前先读一遍

这份配置写于 2016 年，至今仍能导入，也仍能连接。正因如此，没有人再去看它。当初读取这些指令的客户端早已消失，而当前版本对其中若干条可能另有解释。

文件还在，不等于配置仍然适用。把这两件事分开，正是大部分工作。

查清配置是哪个客户端写的

从发布方和版本开始。指令的含义由读取它的实现来定义。曾经用来选择算法的一行，可能变成回退列表、警告，甚至硬性报错。解析它的是哪个版本，决定了结果。

OpenVPN 是最清楚的例子。2.5 版引入了 data-ciphers，并改变了旧 cipher 指令参与协商的方式。只带有 cipher AES-128-CBC 的配置，如今给出的提案远比作者本意狭窄。

去读那个如今会报警或失败的设置对应的发布说明。日志里的警告是关于当前版本的事实，比任何人“当初为什么加这一行”的记忆都可靠。

看看实际协商了什么

导入成功只能证明解析通过，不能证明策略生效。协商结果会在连接建立后出现在客户端日志里。它可能与配置文件两端的设定都不同。

# OpenVPN: what did this session agree on?
sudo journalctl -u openvpn-client@office --since '5 min ago' | grep -i 'cipher\|Data Channel'

# which directives does the profile actually carry?
grep -n -E 'cipher|auth|tls-|dh ' office.ovpn

一次被接受的导入如果悄悄丢掉某条指令，留下的配置就会读起来是一套、跑起来是另一套。正是这个缺口，让一份标着“已加固”的文档协商出比它自己的文字更弱的东西。日志是唯一能看出差异的地方。信任这份文件之前，先读日志。

升级的是整套安排，而不是某一行

去拿运营方维护的配置，而不是不断堆砌算法名，直到导入不再报错。靠试错加行，等于把修复方向弄反了。它让客户端去迁就一个未知服务器，而不是先弄清服务器支持什么。

服务器也可能需要协同升级。当前客户端无法为一个对端从未提供的提案制造支持。客户端侧的任何选项，都替代不了尚未更新的网关。

不能牺牲的是验证。删掉证书检查、关掉主机名校验，或者为了保住旧配置而停掉更新，都会把兼容性问题变成信任问题。这通常是一次一个小编改慢慢发生的。

确认结果，并记录例外

改动之后，再检查一次协商出的套件，并测试隧道存在所服务的那项资源。协商如愿却仍然到不了服务的配置，问题出在路由或身份上。它没有密码学方面的问题。

把上一份已知可用的配置备份在被保护的地方。只有旧文件还在，比较才有可能。

任何兼容性例外都要记录负责人和复核日期。没有人负责的临时安排，会变成永久政策。下一个读到这份文件的人，会以为那是刻意选择的。