在不记录浏览目的地的前提下监控 VPN 对端

监控一个 VPN 对端需要四项事实，其中没有一项是目的地。隧道是否在线、上次交换流量是何时、涉及哪些密钥、移动了多少，这些就足以判断可用性。超出这些的任何内容都是关于人的记录，它应当是深思熟虑的决定，而不是打开状态页面的副作用。先从你必须回答的问题出发，再选择能回答它的最小输出。

先定问题，再选工具

先写下运维问题：这个对端是否已连接、是否在传输流量？这个问题需要实时视图，而实时视图没有保留问题。第二个问题——上周二 02:00 时该对端是否连接——需要存储序列，因而需要一项保留决定。把这两者分开就是全部设计，因为实时视图很便宜，而存储序列会演变成一场数据保护讨论。

同样要把健康检查与状态输出分开。最近的握手只能证明隧道完成了协商，不能证明其背后的私有应用在工作，所以应通过经授权的检查来测试应用，而不是从计数器推断。当检查失败而握手仍很新时，问题出在隧道之外。

读取能回答它的三个字段

WireGuard 的简易状态输出包含接口、公钥、端点、最近握手与传输计数器。判断在线需要公钥和最近握手；必要时加上字节计数器以观察移动。端点对在线判断并非必需，是最该舍弃的字段，因为它能指明设备从何处接入。手册页说明了工具打印的每个字段，篇幅短到读一遍就够：

wg show
wg show wg0 latest-handshakes

把这些数字当作年龄而非布尔值来读。握手只有相对于协议自身的密钥轮换间隔才算新鲜，而一个没动过的计数器可能意味着对端空闲，而不是损坏。把两者放在同一视图里，让年龄与移动一起被读取。

选择你能为之辩护的间隔

每个状态采样都是一条记录，所以 间隔是一项披着监控外衣的保留决定。十秒采样提供细致信息，却让存储行数成倍增加；一分钟采样通常只花六分之一的成本就足以判断可用性。间隔应依据你承诺的响应时间来定，而不是依据工具能做到什么。然后把数字写在仪表盘旁边。

对 OpenVPN 而言，状态机制会按配置的间隔写文件。服务器配置里写成这样 status /var/log/openvpn-status.log 60，末尾的数字是两次重写之间的秒数，文件是被替换而非追加。这个细节很重要：被替换的文件没有历史，而追加的采集器会创造历史。

也要确认采集器遵守该间隔。一个每秒采样、却每分钟只存一行的工具，仍然每秒都在读取。

保持标签稳定，限制映射范围

公钥即使没有绑定名称也能标识设备关系，因此要把密钥当作个人数据，而不是不透明标识符。用能在重连后存活的稳定内部标识符给对端打标签，并把标识符到人的映射放在受限之处。写入时间序列的仪表盘即使 VPN 自己不保留文件，也已是一份存储记录。当仪表盘是唯一存储时，保留规则就落在仪表盘上。

也要审查导出路径，因为被复制的 CSV 会比生成它的系统活得更久。聚合可用性往往足以支撑报告：窗口内存在握手的对端比例回答了运维问题，而无需列出谁在何时连接过。

记录你收集什么、不收集什么

用平实的语言写下收集说明：哪些字段、来自哪个接口、以什么间隔、存于何处、保留多久、谁能读取。把它放在运行手册旁边，而不是放在事故期间没人会打开的政策仓库里。说明还应写明监控看不到什么，因为正是这一点阻止别人以为没有浏览数据就等于没有记录。

每当监控发生变化就复查保留窗口，因为新字段会悄悄延长被保留的内容。随后按说明删除你声称删除的内容，并验证删除确实发生。