供应商 VPN 应用与 NetworkManager：状态归谁所有？
配置文件只指定插件，不代表供应商客户端的行为。在更换受管笔记本之前，先厘清注册、DNS、拦截和更新的归属。
导入配置文件并不等于替换客户端。NetworkManager 会保存插件类型以及插件专属的数据和机密，而拥有该类型的插件决定连接能做什么。供应商应用叠加在上面的东西，从注册到常开拦截，都存在于文件之外。切换是否安全，取决于你实际依赖其中哪些层。
文件指定的是插件，而不是一组功能
NetworkManager 的「VPN 设置参考」描述了一种选择插件的服务类型，还描述了只有插件才能解释的不透明数据字典和机密字典。配置文件是与某一种实现的契约，而不是任何客户端都能复现的行为说明。两个客户端可以说同一种协议，却在协商内容和启用哪些数据路径上不同。协议名称告诉你隧道是什么，从不告诉你周边客户端拿它做什么。
所以要比较需求，而不是包装。问题不是替代方案能否连上，通常都能；而是那些让原客户端可被接受的需求，是否在迁移后仍然成立。在安装任何东西之前把这些需求写下来，否则比较就变成了找第一个出问题的地方。
供应商应用在隧道周围还加了什么
供应商客户端通常把注册与设备姿态检查、带自有界面的二次验证流程、常开拦截、更新通道和支持工具打包在一起。其中一部分紧挨协议，另一部分则是只共用安装程序的不同产品。NetworkManager 可以替换隧道及其路由，连接状态变化时 dispatcher 脚本也能触发动作。但它不复制拦截引擎、证书续期流程，也不复现“哪个用户可以拉起连接”这一假设。
组件更多并不意味着更安全，更少也不意味着更弱。问题在于哪个组件执行了你被要求遵循的策略。如果审计员问隧道断开时是什么在拦截流量，答案必须指出真正做这件事的东西，而只会连接的配置文件不是答案。
归属真正分歧的地方
请把这张表当作归属地图而不是检查清单，因为下面的失败都是归属缺口，再多的客户端配置也补不上。每一行都点明层次、今天通常由哪一方持有，以及缺口最先出现在哪里。
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
每一行都要配一个可以重复的观察，而不是对客户端的感觉。一个经由预期解析器解析的名字、一条隧道停止后消失的路由，以及模拟断开后被拦截的连接，这三项观察合起来覆盖了表格的大部分。把观察写在它所证明的需求旁边，并保留失败的那些，因为失败的观察是记录中唯一能预测下一次事故的部分。
在不重叠归属的前提下切换
针对同一服务同时运行供应商客户端和 NetworkManager 连接，是这类比较最常见的出错方式。两者都会安装路由，两者都可能设置 DNS，两者都可能触碰防火墙状态。此时你测到的是第三种安排，它与两个客户端中任何一个的文档化行为都不相符。
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"第一条命令告诉你配置文件到底是不是 VPN 类型。第二条显示插件服务类型以及存了哪些机密，当密钥期望由代理而非文件提供时这一点很重要。日志是加载成功却未能协商的插件会开口的地方。如果三者都没有显示问题，缺口就在隧道之上的策略层，而不在连接本身。
在启用新连接之前断开旧客户端，保持端点和账户一致，并写下哪个组件拥有路由、解析器设置和拦截。正是这份记录，能防止下一次更新以两个所有者收场。