一份配置，两个主人：NetworkManager 还是 systemd

.ovpn 文件在有人接管它之前不会做任何事。在 Pi 桌面上，可能的接管者是 NetworkManager（它把导入的连接存在自己的密钥文件里）和一个从目录读取配置的独立服务单元。这是两种运行模式，存储方式、凭据处理和激活规则都不同。有意识地二选一才是全部工作；把文件复制到两处只会让选择变成偶然。

两者可以在同一台机器上工作，但不能在同一时刻占用同一条隧道，而且这种冲突看起来像网络故障，而不是配置故障。

接管同一条隧道的两种方式

NetworkManager 的 OpenVPN 插件会新增一个编辑器和一项服务替你管理连接，而安装 OpenVPN 程序并不会安装这套集成。独立单元正好相反：没有编辑器，没有桌面集成，只有一个配置文件和单元授予的权限。前者把连接状态存在自己的数据库里，后者把它存在配置和单元指定的位置。多数困惑来自一个假设：导入的配置和复制的文件是同一个对象。

它们并不是同一事物的两种视图。编辑下载下来的文件，既不会改变 NetworkManager 保存的内容，也不会改变单元读取的内容，而这两者中任意一个都可能是你刚刚测试的那条隧道的搭建者。

沿着桌面实际使用的连接去查

有文档记载的导入操作，nmcli connection import type openvpn file office.ovpn 会通过插件创建连接。记下它的 UUID，之后就用这个标识符，因为名称会被改动，两条连接也可能共用同一个标签。nmcli connection show 会列出存在的内容，读取连接自身的属性则能看出它来自哪个文件、保存了什么。如果你正在编辑的 UUID 不是桌面激活的那个，你的编辑就只是装饰。

密钥保存在主人自己的存储里。为了弄清哪份配置在生效而把所有已保存的密钥都倒出来，既慢又危险；不如去问连接对象，并把私有材料放在主人期望的位置。

导入的连接运行时不需要图形会话，但它仍可能需要一个凭据来源。它能否无人值守地启动，取决于它的权限和密钥，而不取决于桌面是否存在。

在依赖单元模板之前先读它

当软件包提供上游风格的客户端单元时，名为 office 的实例对应单元的已配置目录中的%i.conf 文件；对 2.6 模板来说，这个目录是/etc/openvpn/client 。在相信指南里的示例之前，先读已安装的单元和任何附加文件，因为各发行版会挪动路径。从终端手动启动，并不能说明服务如何看待文件、密钥或权限。桌面的密码对话框同样不能证明非交互式单元有获得同一密码的正当途径。

只给单元它需要的东西。因为一个被引用的文件读不了就放宽整个服务沙箱，是用一个小权限修正换一次大暴露，而报错通常会点出需要关注的那个文件。

在不失去访问的前提下退役重复项

如果两个主人都能启动这条隧道，早晚会有一个在错误的时刻胜出，败方的路由和设备就被留在那里。通过它自己的主人移除意外的重复项 留一条恢复通道，并确认剩下的主人在重启后仍能连接。两套故意分开、路由策略不同的 VPN 是另一个设计问题，而不是允许两条启动路径去争同一条连接。

然后写下你接受的生命周期：手动激活、登录，或开机并重连。检查保存的端点、对端认证以及隧道本应到达的资源，因为重装桌面并不能代替知道哪份配置实际跑过。