用于 VPN 日志的 journalctl：连接属于哪个单元？

请从真正拥有 VPN 连接的 systemd 单元入手，而不是凭记忆使用某条日志命令。直接的 OpenVPN 服务、wg-quick 单元和 NetworkManager 配置文件会把有用信息放在不同单元里，查错单元只会得到看起来像沉默的空结果。先比较三种常见所有者，再收窄窗口，然后按顺序阅读各阶段。

比较三种常见所有者

OpenVPN 客户端服务通常是按配置文件命名的实例单元，例如 [email protected]。它的信息包括配置路径、选项解析、TLS 握手以及客户端执行的路线安装。

wg-quick 单元在设计上更安静。接口配置在启动时完成，握手由内核处理，常规密钥更新默认不记录，因此 wg show 往往比日志更有信息量。当你把一个会记录协商过程的协议和一个不记录的协议相比较时，这个差别很重要。

NetworkManager 拥有自己创建的配置文件，即使底层插件是 VPN 辅助程序，其信息也位于 NetworkManager.service 之下。当配置文件以此方式管理时，要同时查询管理器和辅助单元。

把查询收窄到一个单元和一个窗口

查询你确认的单元，并把时间限制在你正在排查的那次尝试上。通常一天就够；如果机器经常重连，更短的窗口更好。

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

在信任查询之前核对已安装的名称。发行版打包会重命名单元，而以文件形式存在的配置文件可能从未被启用为服务。如果单元不存在，空日志说明的是部署问题，而不是隧道问题。

阅读第一个失败阶段

按发生顺序阅读事件：端点查找、传输、身份、认证、路线安装，以及随后应用程序的失败。第一个具体失败才值得调查，因为它之后的一切都是结果。

成功启动的服务并不能证明每个所需资源都可访问。重连循环可能产生多次独立协商，所以要把配置文件名和尝试时间与事件放在一起，并只读一次尝试，而不是混在一起的流。单次尝试是有因果的序列，混在一起的流则是重复行组成的墙。继续往下读之前，先把第一个错误写进工单。

不要把失败的服务和手动客户端混在一起

如果你在服务失败后手动启动了客户端，它的输出会去别处，行为也可能不同。在采取受支持的修正后，从同一所有者和同一请求获取新结果，让对比显示变化，而不是把两个不同程序混在一起。

不要为了与另一台主机对齐而改动原始时间戳。要单独记录时区和已知的时钟差异，因为被你编辑过的时间线不再是证据。

分享摘录，而不是导出

日志条目可能包含用户名、端点地址、私有拓扑和脚本环境信息。要审阅实际摘录并隐去敏感内容，而不是发布完整无限制的导出。引用能证明失败的那些行，其余部分作概述。简短且经过审阅的摘录比没人读的文件更容易处理。

发送窄窗口、单元名称和第一个失败阶段，并说明你已经排除了什么。systemd journalctl 手册记录了选择器和输出选项，如果你需要发行版版本支持的形式。