如何用已签发的文件组装 OpenVPN 客户端配置文件

运维人员会把 CA 包、客户端证书及其私钥交给你，而这些文件不接进同一份配置，客户端就不会启动。配置只是配置：它指向这些文件，并不包含它们，改配置也不可能把它变成证书。本演练从一台已获批准的笔记本电脑开始，到一份能从已知目录启动的配置结束。它不创建 CA、不登记新证书，也不碰服务器。

这里的目标是 Linux 上的 OpenVPN 2.6 命令行客户端，采用 UDP 上的 TUN 路由，并使用证书认证。

只收集客户端一侧的文件

在受保护的目录中操作，收集已批准的 CA 信任材料、签发给你本人的客户端证书，以及与之匹配的私钥。本例中文件名分别是 ca.crt、laptop-a.crt 和 laptop-a.key。文件名只是标签，并不能说明每个文件里装的是什么。

如果私钥是在登记时生成的，它从未离开过那台机器；签发方只需要把已签名的证书和公开证书链交回。确认证书带有服务所要求的客户端角色。还要确认这把私钥属于该证书，而不是上一次尝试留下的旧证书。公私钥不匹配会在很久之后才表现为 TLS 失败，看起来却像服务器的问题。

CA 的私有签名密钥、服务器的私钥和 DH 参数都不要放进这个包。

把文件接进一份小配置

下面的配置刻意写得很短。每一行要么选定端点，要么约束客户端接受的证书身份，要么指向三个文件之一。

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

remote 行选择网络端点。remote-cert-tls server 要求对端出示带服务器角色的证书。verify-x509-name 固定期望的名称，这里是 vpn-gateway，即服务器证书在 OpenVPN 默认名称字段下的 Common Name。这个值并非从 DNS 主机名推断而来，所以请使用运维方给出的身份方案。

不要仅仅因为某个测试端点显示了另一张证书，就把这些检查删掉。

这份基础配置假定没有单独的账户质询，也没有控制通道密钥。如果服务需要 auth-user-pass、tls-auth 或 tls-crypt，请保留拿到的配置和材料，因为你自己生成的控制通道密钥不会与服务器持有的那一份匹配。也不要从旧示例里照搬压缩或加密相关行，而应保留服务方的加密策略。

把工作目录显式化

相对路径跟随进程的工作目录，而不是 .ovpn 文件所在的目录。

这一点会让那些把配置挪到新文件夹、以为私钥也会跟着走的人吃亏。对于管理员指定的目录，下面的命令会先切换到绝对路径，再读取配置及其引用。

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

桌面导入向导或系统服务可能会替你打包依赖，并套用它自己的规则。它也可能使用与你测试时不同的工作目录。请确认你的启动方式如何解析私钥、证书和 CA 的路径。只移动 .ovpn 文件并不会把单独存放的私钥一起搬走。

让私钥只对预期的用户或服务身份可读。

验收交付，而不是看文件名

在第一次获批连接之前，检查端点、证书身份、签发方和有效期窗口；然后确认文件引用能从你实际使用的工作目录解析出来。连接之后，再测试路由策略本应提供的应用与 DNS 行为。三个能读的文件并不能证明服务器授权，也不能证明资源路径可用。

如果出现口令提示，它属于私钥，而不是 VPN 账户。

最后，把整个包当作凭据材料登记造册。把同一张证书和同一把私钥交给第二台笔记本就是在复制身份，改个文件名也换不来第二次登记。组装配置与签发配置的差别正在这里。