离线 VPN 软件包：让目标机器自己说明需要什么

你需要 VPN 客户端才能接入那个本应提供其软件包的网络，这是一个整齐的小循环。在另一台机器上下载一个 OpenVPN DEB，通常会以第二个缺失依赖收场，然后是第三个，接着整晚都在追查库版本。替代做法是让断网机器用它自己的说法，讲清它的包管理器需要什么。下文一切都源于这个“谁来问”的反转。

对 Debian 系系统来说，这场对话通过 apt-offline 进行，它是一个请求—回传的流程。它自己的运行时必须先存在于目标机上，从获批介质或管理员掌管的另一个引导程序安装，因为没有任何工具能从虚无中自我引导。

从目标机的包状态出发，而不是辅助机的

在做其他任何事之前，先记录目标机的发行版版本、用户空间架构和已配置的软件包源。这三项事实决定哪种 VPN 实现和哪种桌面集成是合适的，而它们正是联网辅助机无法提供的事实。

辅助机只负责下载文件；它不会成为依赖基线。一台已经装好 OpenVPN 的较新笔记本，其包状态与目标机完全不同，因此它的成功并不能证明目标机能接受什么。

也要确定你真正想要什么。VPN 引擎、NetworkManager 服务插件和图形化编辑器是彼此独立的软件包，正确选择取决于发行版以及用户将如何管理连接。无头服务器需要引擎和一个配置文件；桌面需要 那个让其网络设置掌管隧道的插件。请求错误的集合，会得到一次成功的安装和一个没人能启动的连接。

两次往返，按这个顺序

手册把操作分成三步：在断网系统上生成请求、在联网辅助机上下载、再回到目标机导入。在请求软件包之前先刷新目标机的仓库元数据，因为包请求正是依据那份元数据构建的，过期的索引会生成辅助机无法满足的请求。

在目标机上，一条形如 apt-offline set vpn-meta.sig --update 的管理员命令会写出刷新请求。把该文件带到联网机器，用 apt-offline get vpn-meta.sig --bundle vpn-meta.zip 下载一个包束。再把包束带回，在目标机上用 apt-offline install vpn-meta.zip 导入，同样以管理员身份。

现在从刷新后的元数据生成包请求，例如 apt-offline set vpn-deps.sig --install-packages openvpn，并用新的包束名重复这一趟。把每个请求与它产出的包束配对保存；依据旧元数据生成的包束并不是同一个请求，哪怕文件名看起来可以互换。

只有设计需要时才加入集成软件包

如果桌面应当通过网络设置来管理隧道，请求就需要引擎之外再带上匹配的插件。请写入你的发行版实际提供的具体包名，而不是凭记忆从别的发行版抄来的清单，并且清单一变就生成新的请求。版本锁定也值得一想：为更新版本构建的包可能满足名字要求，运行时却仍然失败。正是在这里，固定的四包组合成了负担，因为正确的清单是目标机的属性，只有目标机才能算出它。

这里同样如此：固定的四包组合成了负担。正确的清单是目标机的属性，而目标机是唯一能正确算出它的机器。

导入包束不等于安装 VPN

尽管名字如此，安装操作只是把 APT 数据放进包管理环境。它并不执行包事务。你要根据本地提供的资料完成并检查目标机上真正的 APT 安装，去读输出，而不是假定 ZIP 成功就代表软件已就位。

如果那次事务仍然要求尚不可用的文件，请保留具体的缺失依赖或仓库错误，并据此生成下一次请求。不要用别的发行版的 DEB 顶替，也不要关闭校验和或仓库身份验证来强行通过。手册明确警告不要跳过对已下载文件的校验，这有充分理由：未经校验的包比一次失败的安装更糟。

软件包只是前半程

安装软件与取得获批的端点、配置文件、信任材料和凭据是分开的，其中每一项都可能有各自受控的交接。一套能用的软件包而没有有效配置，什么也连不上。

然后要让这条离线传递路径继续活下去，以应对将来的更新。把第一次成功连接当成维护的终点，就意味着下一次安全更新要等到有人开车上门，离线网络正是这样悄悄落后好几年。