OpenVPN 配置文件的便携性：可移植密钥与平台专属选项

同一个 .ovpn 文件在一个客户端里能建立隧道，在另一个客户端里却启动失败，而证书往往是第一个被怀疑的对象。更常见的情况是，文件里含有只有某一引擎才实现的指令。配置文件是与特定客户端的约定，而不是可移植的脚本。

把随身份一起走的内容，与属于某一平台的内容分开。这样一来，故障通常就会自己说出名字。

一个文件，两份约定

配置文件把三类内容打包在一起：身份材料，例如 CA 证书、客户端证书和私钥；传输信息，例如远端地址与协议；以及行为指令，例如 DNS 处理或设备选项。前两类在支持同一协议的引擎之间大体可移植。第三类正是各实现产生分歧的地方。把整个文件当作一个可移植单元，才制造出那些令人困惑的故障。

在某个平台的图形界面里能用的文件，并不自动适用于另一平台的命令行客户端。即便两者都是 OpenVPN，解析器和选项集也各不相同。因此导入成功并不能证明配置文件是可移植的。

身份与传输部分是需要保留的内容。ca、cert、key 和 remote 描述谁在哪里连接，对任何合规客户端都具有相同含义。

行为指令是需要对比的内容。例如 block-outside-dns 的存在是为了改变 Windows 下的 DNS 行为。Unix 客户端可能根本不认识它。

读接收方客户端的选项列表，而不是发送方的。OpenVPN 2.6 参考手册记录了引擎的选项，而图形界面的导入对话框并不是那份列表。

把某个选项报为无法识别的错误，属于解析器失败，而不是认证失败。连接根本没走到 TLS，所以换证书不可能有用。先读实际客户端与版本的第一个错误，然后只删除或替换该客户端无法实现的那条指令。为了让文件能加载而删掉证书或路由段落，正是把可用配置变成不安全配置的路径。

如果错误提到握手、证书或加密算法，说明配置文件已经解析成功，问题在别处。

把原文件保留在改动版旁边。当改动版日后出错时，原文件就是判断究竟是改动还是环境发生了变化的对照。

权限是另一道边界：创建隧道设备、安装路由、读取私钥都取决于本地权限。只有 root 能读取的密钥文件是正常部署，而不是配置文件缺陷。修复应落在所有权或能力上，而不是文件里。

用 sudo 运行客户端可以解决本地权限被拒的问题，却无法添加二进制程序并未实现的指令。它还会改变生效的用户密钥环、配置路径和网络管理器上下文，所以结果并不是同一次测试。

当服务商分别发布配置文件时，应取为接收方客户端准备的那一份。改造其他平台的文件是最后手段。它需要记录每一处改动的选项，并保留原文件的副本。

把身份、路由和 DNS 当作三个独立结果来测试。能认证、能路由却破坏了名称解析的配置，只是部分适配过的配置，而不是可用的配置。