Linux 上 Viscosity 导出与普通 OpenVPN 配置文件的对比

把 Viscosity 的 .visz 文件改名为 .ovpn 并不会改变其中的内容，因为扩展名从来不代表某种协议。真正值得比较的，是带依赖的包与不带任何依赖的普通客户端配置文件。在让 Linux 上的导入程序读取它之前，先判断你实际拿到的是哪种容器。

每种容器包含什么

Viscosity 的导出文档描述了一种 .visc 连接包和一种 .visz 归档形式，后者是压缩的 tar 归档。包会把配置与它所依赖的证书、密钥和脚本文件一起携带。普通 OpenVPN 配置文件只是一个文件，它引用的任何东西都必须单独存在或内嵌其中。

这一差别就是全部比较。包内的关系是产物的一部分；普通配置文件的关系则是一种假设。在未保留这些关系的情况下把包移到 Linux，会得到一个能打开、却在第一个缺失引用处失败的文件。把证书内嵌的配置文件通过把所有内容放在一处来避免这种失败，这在需要轮换其中某个证书之前很方便。

外层扩展名说明你拥有哪种容器，而不是哪个客户端能使用它。

配置究竟从何处开始

在包内部，厂商记录了一个 config.conf 与其依赖文件并列，引用在本地解析。该文件才是起点，而不是归档的名称，也不是目录列表中恰好排在最上面的某个证书。

在 Linux 上，包可能以目录而非单个对象的形式出现，因为归档会展开成预期放在一起的文件。在你解压到的工作区中保持相对路径一致，不要手工把 Windows 绝对路径改写成 Linux 路径。缺失的依赖文件与错误的路径会让客户端给出同样的抱怨。

为了压下这条抱怨而删除信任或身份选项，并不是修复。

包不会一并带走的东西

Viscosity 自身的偏好设置并不都是 OpenVPN 选项。脚本、路由行为和应用程序设置可能需要由 Linux 客户端受支持的集成来表达，而不是复制成另一个程序可以执行的文本。

在读懂并确认某个随包脚本已被授权之前，把它当作数据看待。仅仅因为导出里包含它就运行它，会把你本该做的审查颠倒过来。同样的谨慎也适用于内嵌的凭据：包可能携带私钥材料，因此工作副本应放在受保护的位置，而不是下载文件夹。

在迁移被接受之前，原件保持受保护状态。

Linux 一侧必须决定什么

决定这条连接由谁拥有：仅用 Community OpenVPN、NetworkManager 插件，还是其他受支持的客户端。每种接受不同的选项集，并且以不同方式管理路由、解析器和机密。在一个导入程序中成功打开的文件，可能被另一个拒绝，而导入成功并不能证明与预期连接兼容。询问运维人员是否已有兼容 Linux 的配置文件，因为从受支持的产物开始，比翻译一个更省事。

把服务器信任、客户端身份和私钥保护当作三个独立的问题。

连接之前的审查

检查端点与传输、认证方式、每一处文件引用，以及预期的路由与 DNS 策略。然后分别验证连接和所需应用，因为隧道起来并不能说明应用能否到达它需要的地方。

openvpn --config ./config.conf --verb 4

把协商出的结果与运维人员所说的配置文件应有行为作比较，并记录 Linux 客户端忽略的任何选项。

迁移被接受后，通过常规的凭据处理流程退役传输副本。留在共享文件夹里的包，就是留在共享文件夹里的凭据。