vpnc 弱加密报错：网关策略还是桌面修复？

当旧的 vpnc 连接起不来时，两种修复看起来同样快捷：传入旧的弱加密开关，或者放一个替你加上它的包装脚本。二者并不等价，因为一个只改变单个配置文件的策略，另一个却改变所有调用该路径的程序的行为。第一个问题是网关是否还提供弱提案，第二个是谁有权接受它。其余一切都是由这两个答案推出来的。

两种影响范围截然不同的修复

配置文件层面的改动只涉及一条连接、一个责任人和一个到期日。替换已安装的二进制文件则会涉及机器上的每一个前端，包括同事用于完全不同网关配置的桌面小程序。包装脚本还会让半年后调试主机的人看不到这次改动。

软件包校验是第一处代价：/usr/sbin/vpnc 上的文件一旦与其所属软件包不符，例行的安全更新就会变成一次调查。此后的升级要么静默覆盖包装脚本，要么拒绝应用，取决于包管理器如何处理被修改过的文件。这两种结果都不会出现在连接日志里，所以包装脚本的做法在第一次事故之前一直很有吸引力。配置文件里的一行远比一个没人记得被替换过的二进制文件更容易找到和删除。

过时开关究竟做了什么

vpnc 手册把单 DES 选项标记为过时，建议改用弱加密设置，并记录了另一个完全允许数据流量不加密的选项。这些是后果不同的不同让步。它们都不能让现代网关去协商它已不再提供的东西。

先看清失败发生在哪一阶段，再选择修复方式。被拒绝的提案和被拒绝的密码会产生相似的前端提示，但证据完全不同。

限定例外应该放在哪里

如果组织明知故犯地在一段有限时间内接受旧对端，例外应写在该对端的配置文件里，并附上责任人、复核日期和迁移到受支持协议的路径。把它挡在全局路径之外，正是“限定”一词的全部意义。

让网关责任人确认对端还在提议哪些算法，以及用什么来替代。客户端开关修不好服务器已不再发送的提案，而没人安排的服务器迁移会比临时方案活得更久。把复核日期和例外写进同一张工单，让这项让步到期，而不是变成永久。

检查协商过程，而不只是绿色图标

收集能指明阶段的证据，而不是对话给人的感觉。下面的命令都是只读的，前两条显示实际生效的是哪份配置和哪个版本。

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

第三条命令报告与软件包不再匹配的文件，被遗忘的包装脚本正是这样暴露自己的。第四条显示配置文件携带的让步，使例外不会通过一个被复制的文件悄悄扩散到第二个配置。改动前后都要运行这两条，并把输出与连接配置放在一起，而不是留在聊天窗口里。

在有人读过之前，不要把调试输出贴进工单，因为手册警告最高调试级别会倾倒包括密码在内的认证数据。验收标准是客户端与网关之间获得授权且受支持的约定，而不是某个终于变绿的菜单项。如果对端只提供已经损坏的算法，诚实的结局是带到期日的例外，或改用替代协议，这个决定属于网关的所有者。把决定记录下来，正是受管例外与意外策略变更之间的区别。