Linux 发行版究竟能支持哪个 OpenVPN 软件包

点名某个 OpenVPN 发行版的说明通常暗指某项功能，版本号只是它的替代指标。等你读到这些内容时，发行版可能已经提供了比指定版本更新的东西，却仍缺少你需要的集成；也可能提供的是更旧、但已经满足要求的东西。把版本号当成目标，只会做出什么也解决不了的仓库改动。把它当成需求的症状，得到的决定要小得多。

三个问题把两者分开：哪种实现、哪个基础发行版、以及谁负责更新。

版本号不是功能需求

先问连接需要什么，再问哪个软件包提供它。配置可能需要某种加密算法、TLS 模式、认证插件或管理接口，而报告出令人满意的版本字符串的构建也可能缺少其中任何一项。反过来，稍旧的构建或许已经实现了配置用到的一切。版本字符串是打包者的总结，不是功能清单。

要弄清这条说明指的是“该功能或更新版本”，还是“恰好这个构建经过测试”。两种答案会指向不同的仓库。

代号必须与基础发行版匹配

仓库按发行版的代号索引，而派生发行版的发行名并不是其基础发行版的代号。读 /etc/os-release 查看 VERSION_CODENAME 和 ID_LIKE，确认派生版跟随的是哪个基础发行版。一个把某个桌面发行版对应到某个 Ubuntu 代号的旧回答，对下一个版本毫无说明。猜测代号，正是系统最终拉取到针对另一套 C 库构建的软件包的方式。

在添加任何东西之前，先用 apt-cache policy openvpn 看看包管理器已经提供了什么。如果 已安装的候选版本已满足要求，仓库的问题就不存在了。

上游仓库究竟绑定在什么上

上游渠道为特定基础发行版发布构建，其说明会 把仓库行与签名密钥配对，并给出受支持的代号。这些部分不是可以随手换成你知道的某个代号的占位符。依赖是相对于构建所面向的发行版解析的，所以装得再干净的包仍可能破坏共用某个库的无关软件。

阅读你所选实现的仓库指南，遵循它当前的兼容性表，而不是旧博客的转抄。

安装不等于集成

替换 openvpn 二进制并不会补上缺失的 NetworkManager 插件、导入对话框或桌面编辑器。它们位于独立的软件包中，例如 network-manager-openvpn 及其桌面版，并与客户端库有各自的版本关系。OpenVPN 3 Linux 又是另一种实现，有自己的会话与配置模型，因此它的软件包并不能直接替代 2.x 配置的工作流程。

在动手安装之前，先确定哪个组件拥有正在运行的隧道。同一台主机上两个管理器，会造成与两个客户端相同的重复隧道混乱。

把三项决定写下来

记录实现、基础发行版和更新的负责人，并注明其中哪一项预计会变化。当发行版发布后仓库行失效时，未来的升级读到的就是这份记录。没有它，下一个人就会用更新的版本号重演猜测代号。

如果你需要的渠道已不再支持该基础发行版，答案是迁移平台，而不是退回三个发行版之前的仓库。