VPN 日志能证明什么、不能证明什么

在选择日志收集器之前，先确定审计要认定的究竟是哪个事件。问哪个 VPN 会话访问了某个目的地址，与问哪个人打开了某个页面，是两个不同的问题。两者需要不同的记录、不同的关联和不同的置信程度。OpenVPN 连接日志能回答前者，无法回答后者。

先命名事件，再选择收集器

会话记录显示被接受的身份、起止时间，以及服务器按其自身策略分配的地址。解析器日志显示某个名字曾在那个解析器上被查询。流量记录显示地址、端口、协议和时间，应用日志显示该应用实际处理的事务。这四者中任何一个都不能替代另一个。

它们各自认定一个事件，其余仍然悬而未决。先把问题写下来，就不会拼凑出数据无法支撑的故事。

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

第一条命令显示服务日志中的会话事件。第二条打印当前客户端列表及其被分配的地址，这正是审计关联所依赖的映射。第三条显示实时流量状态，仅在连接仍然存在时有用。

查询不等于访问

浏览器会推测性地解析域名、缓存结果，并在不再询问被监控的解析器的情况下重复使用。因此解析器日志里出现的名字只能证明发生过查询，不能证明发生过访问。HTTPS 上的 DNS 进一步放大了这一缺口，因为这样配置的浏览器会把提问发到你惯常的日志记录器永远看不到的地方。

目的地址本身也说明不了更多。一个地址可能承载许多互不相关的站点，反向 DNS 只是猜测而非还原，TLS 握手时可见的主机名也不是加密会话内部的请求路径。

要得到精确的事务，需要应用自身的事件记录，或者明确支持日志记录的代理设计。CONNECT 隧道给代理的只是目的地址和流量体积，而不是其中的页面路径。对网络拥有管理权限，并不等于可以悄悄替换应用的信任模型。

在指认某个人之前，先关联身份与时间

带有内部源地址的流量记录，只有在该地址同一时间被关联到某个会话时才有意义。地址会被复用，同一个地址一小时前可能属于另一个会话。静态分配只是保持关联的一种方式，并非唯一方式。

转换边界会进一步削弱关联。如果多台设备在你的观测点之前就共用了一个源地址，你所能识别的最好结果是共享网关的会话，而不是单台设备。多个人共用的证书或账号也有同样的效果。

记录时区、时钟来源、观测点以及每一次转换环节。记录缺失可能意味着流量条目已过期、传感器被绕过，或应用日志被关闭。缺失并不能证明什么都没有发生。

然后为声明的目的定义最少字段、允许的读者和保留期限。关联与误归属是设计问题，而不是事后补救；能够识别个人身份的元数据，应当得到与它所依赖的身份映射同等的保护。

用你能控制的活动检验审计

生成你已知其会话与应用的可允许流量，然后检查每条记录实际捕获了什么。在不加载页面的情况下做一次查询，从缓存加载一个页面，并通过代理建立连接，看看会出现哪些事件。

报告证据所能支撑的事件，并说明它不覆盖什么。范围声明清楚的谦逊记录能经得起复核；由猜测拼凑出的宏大浏览史则经不起。