本地系统日志能揭示 VPN 连接的哪些情况

每台桌面都会留下自己关于 VPN 做了什么的记录，而应用导出的日志通常是其中最不完整的。服务管理器记下单元何时启动，内核记下接口何时出现，网络栈记下路由何时没能生效。这些设施都不知道客户端想做什么，客户端也不知道内核如何处理了它的请求。

只看其中一份记录，很容易得出错误结论。读同一分钟的两份记录，先后顺序就会显现。

三种设施，三套词汇

在 Linux 上，systemd 日志捕获来自 wg-quick@wg0 或 NetworkManager VPN 插件的单元生命周期消息，内核环形缓冲区则承载接口与路由消息。在 Windows 上，事件日志把故事分散到系统、WLAN 和远程访问提供程序，各自使用自己的标识符。在 macOS 上，统一日志承载限定在子系统内的消息，图形界面控制台只能部分显示。

这些词汇并不互通。一个平台的事件标识符在另一个平台上毫无意义，一张 Windows 对话框的截图也证明不了任何关于 Linux 单元的事情。

三者共同的要素是时间戳、来源和严重级别，正是这三样让客户端日志与操作系统记录之间的关联成为可能。可用性也各不相同：没有日志的容器、被裁剪的 Windows 镜像，或构建时下调的日志级别，都可能把整整一层藏起来。

一行“已连接”能证明什么、不能证明什么

服务启动事件记录的是本地单元被要求启动，且没有立即退出。它不记录握手是否完成、对端密钥是否有效、路由是否真的可用。把这一行当作隧道已建立的证据，是这些日志中最常见的误读。这一行证明的是意图和进程状态，对可达性什么都证明不了。

转发状态是另一个观察项，它来自路由表，而不是任何日志。

网卡事件可以解释一次静默失败：接口起来了，地址分配了，但路由因为某条策略规则被拒绝而从未安装。在这条时序里，每一行可见记录看起来都健康，实际上什么也没被转发；要看出这一点，唯一的办法是把日志时间戳与同一时刻的路由表对照。把客户端自己的事件顺序摆在两者旁边，因为客户端才是唯一知道自己请求了什么的来源。你需要的两个事实几乎从不落在同一行。

之后再重连会覆盖这幅图里最有趣的部分，所以在第一次失败时就抓取时间窗，而不是等重试三次之后。

关联一个窄时间窗

把尝试时间连同所在时区记下来，然后取出前后几分钟。窗口里的第一条错误，几乎总是早于支持工单引用的那条断开记录。

journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20"
ip route show table all | grep wg0
log show --last 20m --predicate 'subsystem == "com.apple.network"'

每条命令回答问题的不同部分：第一条给出生命周期，第二条给出转发状态，第三条给出 macOS 网络子系统。在 Windows 上按提供程序名称过滤系统日志，而不是滚动整个通道，并且只导出匹配的事件。

把摘录控制在读者能跟得上的长度。二十分钟、四条相关事件的时间窗足以支撑一个结论；一整天的、上千行的导出什么都支撑不了。

这些记录止步于何处

本地记录描述的是设备，而不是路径。它们无法显示提供程序存了什么、会话是否与账户匹配，也无法显示目标端看到了什么。提供程序声称不留日志，并不能说明你笔记本上的操作系统如何；一条本地事件也证明不了该提供程序的历史记录。

它们还会带上超出预期的个人数据：用户名、主机名、挂载路径和设备标识符会出现在普通系统消息里，即使没有任何浏览内容。把这些内容删掉再附到工单上，并把原始文件置于常规访问控制之下。

在受管设备上，应向 IT 索取相关摘录，而不是试图清除组织层面的日志。诊断的目标是用两个来源回答一个窄问题，而不是拿到这台机器的完整历史。