让每个 VPN 账号拥有自己的 NetworkManager 启动器

两个 VPN 账号、一个网关，以及一个按最后使用者身份连接的桌面图标。常见原因是启动器在连接前改写了共享配置的用户名，或者它查找的是两个配置偶然共用的显示名称。NetworkManager 本就通过 UUID 区分配置，因此这个图标可以准确指定其中之一，而不去动身份。它不该携带的是密码。

启动器只是指针，不是凭据仓库。

找到 UUID 并确认身份

列出已保存的连接，读取 UUID、连接 ID 以及每个配置所保存的用户名。在创建任何东西之前，先确认哪个配置属于哪个账号，因为显示名称只是标签，不是键。如果两个账号需要不同网关或不同配置，那是另一项配置工作。

在启动器里使用 UUID。按显示名称查找只在没人改名之前有效，之后图标就会以错误账号连接，或者完全连不上。

编写桌面入口

桌面入口需要类型、名称和可执行行。命令应当拉起那个 UUID，并让 NetworkManager 去索要密钥，nmcli --ask connection up uuid ... 正是为此。保留 Terminal=true，以便需要密钥时能看到提示。把占位符换成你真正观察到的 UUID，不要为了遮盖提示而额外套一层 shell。

Desktop Entry 规范把 Exec 定义为程序及其参数。它不是一个 shell 脚本，也不需要套一层。

让代理持有密钥

密钥属于每个用户的代理、密钥环或交互式提示。Exec 中的密码会出现在进程列表、桌面文件以及属性对话框的任何截图里。如果该配置需要密钥，就让受支持的提示去收集，并让代理为该用户记住它。

--ask 设计上就是交互式的。它不是无人值守自动化的配方，也不保证每一种认证挑战或插件都能被脚本化。

不要动辄用 sudo

修改或激活连接的授权来自 NetworkManager 的策略许可，而不是 Unix 特权。用 sudo 运行启动器不会让进程拿到其他用户的密钥环，也修不好网关的拒绝。在共享机器上，应检查哪些本地账号能看到哪些配置、每个密钥归谁所有；分开的图标本身并不构成隔离。

同一网关的两个活动配置也可能争夺路由 或违反并发规则。这是策略问题，不是启动器的缺陷。

验证整个操作

激活一次启动器，确认三件事：拉起的是哪个 UUID、网关看到的是什么身份、密钥提示是否出现在你预期的位置。如果连接失败，保留最初的错误信息。为了让快捷方式看起来自足而把密码写进命令行，只会掩盖那个错误，并制造更糟的问题。

把 UUID 和账号对应关系写进团队笔记。下一个改动配置的人需要知道哪个图标依赖它，而正是这条笔记能让一次改名不至于变成故障。