openvpn3 session-start 无视你的凭据文件

用 2.x 客户端连接，配置文件可以使用；把同一个文件交给 3.x 客户端，它却停在密码提示上。把 --auth-user-pass creds.txt 交给 openvpn3 session-start，结果也一样，因为新客户端没有读取该文件的阶段。这种拒绝是刻意的：凭据属于会话，而会话由服务创建，而不是由你终端里的进程创建。请在对交互式提示和 autoload 助手之间做选择，并了解两者各自保存什么。

为什么已保存的文件无处可用

在新设计中，配置管理和会话管理是两套通过系统总线通信的独立服务。正是这种分离让普通用户能够启动会话，而无需特权守护进程代其读取受保护的密码文件。基于文件的凭据在这种模型里没有位置，因为根本不存在读取它们的守护进程端启动过程。拒绝是架构的结果，而不是缺少功能。

值得说出旧模式，以便更容易改掉：配置文件引用一个凭据文件，隧道启动时守护进程读取它。在新模型中，凭据属于会话，并在该会话开始时提供。openvpn3 session-start --config work.ovpn 会询问这些凭据，而 --auth-user-pass creds.txt 被拒绝，因为那条路径上没有任何东西会打开文件。你能找到的每份 2.x 教程都假设了一个已不存在的阶段。

配置和站点本地设置也被分开，这解释了第二个意外。配置文件看起来可能很完整，但它建立的连接却缺少路由和解析器配置。这些部分作为站点本地设置单独应用，与导入的文件分开。

提示路径以及它留下的会话

在会话启动时提供密码才是预期的工作流程。客户端只询问一次，把凭据交给会话后端，然后继续：

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

这条路径不会向磁盘写入任何内容。终端关闭后会话仍继续运行，这让期望进程随 shell 一起结束的人感到意外。把会话处理移入服务正是为了这一点。会话比请求它的终端活得更久，必须显式停止。

对于面前有人的工作站，这也是最安全的选择，因为没有需要保护或遗忘的已保存秘密。只有在无人输入的地方才不适用。

键盘前无人时的自动化

在机器必须无人连接的地方，项目提供了 openvpn3-autoload。它读取一个配置目录以及每个配置对应的描述符，描述符以明文提供凭据。该助手是单独的二进制文件，通常位于 /usr/sbin/openvpn3-autoload，而不是 session-start 的某个选项。设置它意味着创建目录、以描述符期望的名字复制配置并写入描述符。

单用户设置如下，以将拥有该会话的账户运行。目录权限会把其他本地用户挡在外面：

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

描述符指明凭据并要求自动启动。请把密码值留在版本控制之外：

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

然后调用一次助手并确认会话出现。第二条命令是检查，而不是另一个设置步骤：

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

启动时，名为 openvpn3-autoload.service 的打包单元使用系统级目录 /etc/openvpn3/autoload，而不是单用户目录。该位置需要 root 所有权和更严格的权限，而描述符仍以明文保存密码。取舍很明确：密码现在落在磁盘上，所以请把该目录视为秘密，将其排除在主机外备份之外，并在有人在场时始终选择交互路径。

看起来像密码故障的总线故障

有些被归咎于凭据的故障根本不是那么回事。命名服务激活路径的权限错误意味着两种情况之一：后端没有运行，或者调用者没有权限激活它。任何配置文件的修改都不会改变其中任何一种。在改动配置之前，请检查服务状态和随附的总线策略。

下面的命令把两者区分开来。第一条报告后端是否在运行；第二条显示最近的总线错误：

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

另一种常见的误读是会话出现后立刻消失。这种模式通常意味着站点本地设置从未被应用，因此隧道在没有使其有用的路由和解析器改动的情况下就起来了。请读序列而不是最后一行：会话是否创建、是否达到连接状态、是否存活，是三件独立的事实。

当仍在使用的旧客户端

2.x 客户端仍然接受凭据文件，而密钥环可以在秘密从不落到磁盘的情况下回答它的提示。包装器会解析条目，因此文件指明的是查询而不是密码。这种安排依赖已解锁的密钥环，而没有登录会话的容器或在有人登录之前启动的单元无法提供。随后查找工具会报告一个它无法写入的集合，于是密钥环故障看起来像凭据故障。

在构建上述任何东西之前，先检查配置文件里的 keepalive 设置是否完全消除了重启的需要。一直保持运行的会话永远不会到达你试图自动化的提示。