给加密库改名修不好旧客户端

按顺序梳理加载器报错：缺的是哪个文件、二进制用的是哪种架构、它需要的符号是什么，以及失败发生在进程启动之前还是之后。这是四类不同的问题，而符号链接只能解决第一类。按顺序处理，可以避免常见结局：客户端能起来，却在第一次握手时失败。清单最后一步是用真实启动器验证，而不是手工试跑。

在改动任何东西之前，先逐字记下可执行文件的路径、架构以及第一条报错。

一条报错背后的四种不同失败

缺少共享对象是文件查找问题：加载器按名字去找，结果什么也没找到。缺少符号是接口问题：文件存在，但不导出二进制所引用的东西。符号版本不匹配属于同一类，只是带了更多细节。启动之后才报出的算法不受支持，是那个库加载成功之后内部行为发生了变化。每一种都需要不同的应对，只有第一种才属于命名问题。

ldd针对二进制和readelf -d针对其动态段运行，可以看出它到底要什么，这通常足以把文件问题和接口问题分开。

OpenSSL 3 迁移指南说得很直接：面向旧版本构建的应用至少需要重新编译，而且源码兼容性没有保证。接口变了，有些被弃用或移除。文件名别名既不能完成重新编译，也无法让旧二进制学会新接口。把较新的库挂在一个看起来更旧的名字下，得到的程序可能能启动，随后却在一个远不那么显眼的地方失败。

那比干脆的失败更糟。加载器报错会立刻点明问题，而操作中途才暴露的失败看起来像网络或凭据问题会把排查带向错误方向。

为了迁就一个客户端去替换发行版库，会改变这台机器上每个程序的环境，包括安全更新，以及所有依赖现有接口的东西。把旧库复制到二进制旁边范围更小，但它仍然制造了一份需要有人维护和打补丁的依赖。这两条都不是被认可的兼容路径，哪怕在落地当天看起来能用。实验结束后留下的全局别名更糟，因为没人记得它为什么存在。

针对实际的系统版本、架构和网关，使用厂商支持的客户端与依赖组合。某个包格式在一个人那里管用，并不能确立当前正确的路径；存档的教程只是关于过去的证据。

换成受支持的方案之后，检查正常启动器实际解析到什么：ldd针对已安装的可执行文件、它点名的库版本，以及服务传入的环境。然后再跑一次预期的认证和一次真实操作。带着改动过的环境手工调用，只能证明你的 shell 能把它拉起来。用户真正运行的是启动器、桌面项或服务单元。

如果不存在受支持的构建，就向 VPN 所有者询问替代方案或迁移路径。悄悄换成另一种协议，或者假定一个有着熟悉厂商名的客户端就能满足网关，只是把失败挪了个位置，并没有修好它。

在临时兼容安排无法避免时，把它写进文档、限定在那一个二进制上，并在受支持的构建到位后移除。