ConnMan VPN：菜单消失是守护进程的问题，不是协议问题

常见的误解是：桌面上没有 VPN 入口的 ConnMan 系统就没有安装任何 VPN 支持。实际情况往往是 Wi-Fi 支持存在，而 VPN 守护进程、供应商配置或认证代理这三者各自缺失，这是三种彼此独立的缺失。菜单只是这些组件的一个视图，并不是功能本身。 核对版本与打包情况 一条命令能告诉你的，比任意数量的桌面缺陷报告都多。

传言：菜单就是 VPN 功能

先看已安装的 ConnMan 版本以及随它一起装上的软件包。旧版本的缺陷报告描述的是另一套功能集合，引用它通常以有人重装了一个本不需要替换的网络管理器收场。

动手改之前，先写下你实际拥有的东西： 守护进程的二进制文件、供应商目录，以及是否存在代理。

哪个守护进程拥有这条隧道

在 Debian bookworm 的 ConnMan 1.41 文档中，connman-vpnd 是与 connmand 并列管理 VPN 连接的守护进程。文档列出了若干具名 VPN 助手的集成，其中包括 OpenVPN 与 OpenConnect。这份清单只是关于助手能力的陈述，并不保证每种协议或每种认证流程都能工作。请把它当作待查清单，而不是兼容性保证。

接着把集成方式与网关获批的协议对上。Cisco 这个词并不会告诉你需要旧式 vpnc 连接还是兼容 AnyConnect 的流程，选错会产生看起来像凭据问题的认证失败。

如果独立助手和 ConnMan 都能把隧道拉起来，就要在任一启动之前定下路由、DNS 和生命周期的归属。

守护进程的设置不是供应商的设置

守护进程的全局配置与单个供应商的配置是两种不同格式的不同文件。在文档记载的 bookworm 布局中，守护进程读取 /etc/connman/connman-vpn.conf，而供应商的置备文件位于 /var/lib/connman-vpn/ 下，后缀为 .config。把一份 OpenVPN 配置丢进该目录，并不会让它变成 ConnMan 的置备文件。而 对应版本的供应商手册 则说明了供应商各个段落，以及这些文件真正需要的、与类型相关的字段。

只通过已安装集成所支持的映射来翻译。证书信任、私钥引用、网关身份、路由和认证输入各自承担各自的角色，为另一种供应商类型准备的样例，不会仅仅因为两者都需要服务器地址就可以互换。

当供应商加载失败时，把它里面的字段与已安装版本的手册比对，而不是与博客上的示例比对。

认证代理是独立的依赖

供应商定义依然可能需要代理来获取凭据或完成认证交换。就它的 OpenConnect 集成而言，同一份手册说明：缺失的认证相关取值可以通过 VPN Agent API 请求，而短期 cookie 通常不适合作为永久配置密钥。该机制并不保证支持所有浏览器登录、MFA 提示或网关姿态检查。请与负责部署的人一起确认整个流程。

不要用把密码或会话令牌写进广泛可读文件的方式来弥补代理的缺失。那会把缺失的集成变成凭据泄露，而第二个问题的寿命比第一个更长。

如果网关需要交互式登录，那么代理是设计的一部分，而不是可选项。

要验证四个结果，而不是一个

在获得授权的置备之后，分别检查四件事：供应商已被选中、连接已通过认证、生效路由正是你想要的、解析器的行为符合预期。守护进程在运行、供应商出现在列表里、应用程序能访问到它的资源，这是三个不同的结果，只有最后一个才是用户真正的目标。把它们分开记录，你才知道该修哪一环。

这项检查里还要包含重连行为以及所要求的不可用状态策略，因为一条只升起一次、之后再也不恢复的隧道算不上部署完成。在改动 VPN 集成的同时，要保证可用的基础网络配置仍然可以回退。

为了一个按钮而替换 Wi-Fi 管理器，比所需的那个缺失操作大得多，通常只是传言赢了。