NM OpenVPN：保存下来的配置文件不是你的 .ovpn 文件

同一个 .ovpn 文件在 shell 里能连上，导入 NetworkManager 之后却超时。最自然的结论是 VPN 坏了。更可能的解释要小一些：NetworkManager 并没有保留这个文件，而是把其中一部分导入成一个已保存的连接，实际运行的隧道用的是那份保存下来的数据。文件现在写了什么，跟配置文件里存了什么没有关系。

文件不是配置

导入是一次翻译，不是挂载。插件能理解的选项会变成连接 vpn.data 字典里的键；它不理解的选项会被丢弃或记录在别处，而原始路径只是一个引用。之后再修改源文件，不会改变已经保存的连接。

这个缺口解释了一整类报告：共享密钥轮换了、文件更新了，隧道却仍然失败。保存下来的配置文件仍然指向旧路径或旧值，而命令行之所以还能用，是因为它读的是你修改过的那份文件。两个客户端，两个真相来源，只有其中一个被更新了。

读保存下来的配置，而不是读对话框

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

两个配置重名时用 UUID，并确认服务类型是你预期的 OpenVPN 插件，而不是碰巧装上的另一种 VPN 类型。然后把端点、传输和证书引用与能正常工作的调用做对比。

图形编辑器里看得见的值，并不能证明它被保存了。保存、重新打开，再通过命令行读回来；历史上的保存缺陷是检查已存数据的理由，而不是每个当前版本都有同一个 bug 的证据。这项检查只需要一条命令。

两个键，以及一个要紧的方向

对于使用 TLS 认证的连接，插件会把共享密钥路径存在 ta 里，把方向存在 ta-dir 里——前提是部署确实使用方向。两者都住在配置的数据字典里，而且都必须与服务器的预期一致。

方向是服务器侧的决定，由客户端表达出来。因为邻近配置有方向就跟着选一个，正是让一把本来能用的密钥开始握手失败的原因。如果服务器配置没有方向，客户端就不应该自己造一个。

密钥文件本身必须在插件真正运行的环境里可读。受限制的软件包看到的文件系统和普通桌面安装不同，所以你在 shell 里能看到的路径，服务可能根本看不到。

更新一个条目，而不是整个字典

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

前面的加号会更新单个字典条目。而 vpn.data 不加加号直接赋值，会替换整个字典，一个缺失的键就是这样变成五项坏掉的设置。改完把配置读回来，确认其他条目还在。一个丢了远端端点和证书的字典，会让你这一下午比开始时漫长得多。

通过常规控件重新连接，并观察失败发生在哪一步。如果共享密钥这道门现在过了，而客户端报告证书或用户认证错误，那你就往前走了，接下来的排查是另一回事。

不要把控制通道的几种模式混为一谈

tls-auth, tls-crypt、以及 tls-crypt-v2 是不同的安排。长得相似的密钥文件并不能让它们互换，而因为别的配置里有一把格式化过的密钥就去填 TLS-Auth 字段，只会做出一个失败方式像密钥错误的配置。

使用与服务器配置中模式相匹配的插件映射。模式不清楚时，去问服务器所有者，而不是从文件第一行去猜。

当隧道承载你的管理会话时，要留一条恢复路径。保存过的改动不一定是已生效的改动，导入成功也不证明源文件里每个选项都被支持。在你重新连接正在使用的链路之前，这两个缺口都值得知道。