nmcli 的 VPN 列表：已保存的配置与活跃隧道

你运行 nmcli connection show，本以为会得到 VPN 列表，却拿到机器曾经保存过的每一条连接，其中还包括一个网桥和一个热点。你找的 VPN 可能在里面，可能被标成了 vpn 之外的类型，也可能根本不是 NetworkManager 连接。要弄清自己属于这三种情况中的哪一种，需要两条命令。

两份列表，两个问题

connection show 回答 NetworkManager 保存了什么，connection show --active 回答当前什么连接挂在设备上。第一份列表包含未激活的配置，这是故意的：一条已保存但没起来的 VPN，仍然是你可能需要修复的配置。把两者混为一谈，就会让人以为隧道在运行，其实只有它的配置存在。

挑字段，而不是读默认表格，因为默认输出在窄终端上会藏掉类型，还会把长名字折行。

第一遍通常只需要 NAME、UUID 和 TYPE，然后你按 UUID 去看唯一关心的那一条。

TYPE 才是惊喜所在

OpenVPN 通过插件管理的连接显示为 vpn 类型，因为插件是通用 VPN 框架里的一个服务。原生 WireGuard 支持是独立的头等连接类型，所以按 vpn 过滤是找不到它的。一次没有结果的 WireGuard 隧道搜索，通常是过滤条件的问题，而不是配置缺失。这是架构差异，不是命名怪癖。

NetworkManager 后来学会原生处理的其他隧道类型也一样，所以在断定某样东西不存在之前，先读 TYPE 列。

先全部列出来再过滤，那条配置就出现了。

读 UUID，而不只是名字

名字是人会改的标签，一次不小心的导入之后，两条配置可能共用一个名字。UUID 才是命令和文件引用的身份。当某条记录看起来重复时，先比较 UUID 和底层设置，再删除任何东西。

激活命令两者都接受，正因如此，靠名字的习惯最终会改错配置。

当你改动的东西可能需要回滚时，把 UUID 抄进笔记。

已保存的配置不会告诉你什么

已保存的配置说明不了它的隧道是否起来了，一条活跃连接也说明不了里面的流量是否通畅。由 wg-quick 或某个 service unit 启动的隧道 根本不是 NetworkManager 连接，所以它不在两份列表里，而接口明明在过流量。在断定配置不存在之前，先检查接口和路由表。空列表只能证明 NetworkManager 不是它的主人。

同一个接口有两个管理者，是这个问题的另一种形态；它给出一份看起来正确的列表，而内核状态归别的东西所有。

每个接口只留一个管理者，列表才诚实，而且 nmcli 参考文档 记录了每种视图实际会报告哪些字段。

汇报时不要泄露密钥

带名字的 connection show 会打印设置，加上 --show-secrets 还会 打印私钥和密码。工单里的排障粘贴不需要这些。改为汇报类型、UUID、状态和相关路由，并把来自密钥仓库的内容全部遮盖。

交互式激活用 --ask 是补交缺失凭据的受支持方式，而无人值守的自动化需要另一套获批的安排，而不是保存明文密码。

简短、遮盖过的汇报，比完整转储更容易审阅。