两个检测器可以观察同一个用户却给出不同的结论,而且两者都对。接入链路旁的观察者看到的是 VPN 的外层会话;网站看到的是从出口送来的应用连接。这是两条不同指纹的连接,一方的证据不能迁移到另一方。在讨论任何 TLS 或 TCP 测试之前先说明观察点,才让结论有意义。

不说明观察点的检测器描述的是观点,而不是测量。

两个观察点,两条不同的连接

外层会话属于隧道协议:它有自己的报文格式、自己的状态机、自己的时序。内层连接是浏览器向网站发起的 TLS,经由隧道承载,再从出口转发出去。两者同时存在,却不是同一条流。一个是接入网络能看到的东西,另一个是目的地能看到的东西,而终止其中任一方的中间设备会同时改变两幅图景。

这个差别解释了检测讨论中的大部分混乱。只报告某条流某一件事的测试,回答的往往是另一个层次的疑问,而不是操作者脑子里的那个问题。

接入路径上的观察者看到什么

在接入链路旁,可见的材料就是隧道协议本身:OpenVPN 的控制与数据包类型、WireGuard 固定尺寸的握手与数据模式,或者部署附加的任何封装。分类器能否识别它们,取决于什么可见、由哪种传输承载、是否存在额外的混淆层。可识别的模式是关于某条流的证据,而不是关于其背后之人身份或意图的证据。

443 端口只是到达某项服务的一种惯例。它不会把每种隧道传输都变成 HTTPS。

网站实际看到什么

使用路由式隧道时,浏览器仍与网站自行建立自己的 TLS 会话。出口处的转换不会把 VPN 网关变成浏览器的 TLS 端点,因此网站收到的 ClientHello 描述的是浏览器或其 TLS 库。所以 JA3 式指纹刻画的是应用连接,而不是承载它的 VPN 软件。只有刻意做终止的代理才会改变这种安排,而且必须单独识别它。

TCP 观察需要同样的谨慎。转发、转换和由代理新开连接是三种不同的设计,其中只有一种会重写传输栈。单一异常特征并不能唯一地说明存在隧道。

把结论留在证据范围之内

网络分类、协议观察、应用指纹和账号信号都是风险决策的输入,每一项都有误报、漏报和缺失的证据。托管网段里的地址并不能证明什么商业 VPN,常见的浏览器指纹也不能证明什么直连 VPN。评估检测器时,应使用带有已知路径的授权数据集,并记录每条结果来自哪种观察。

把协议分类与会产生后果的访问决策分开。定制响应或畸形数据包的花招并不能验证其背后的推断;它只是对猜测施加压力。

有用的报告会写明观察、观察点和置信度。只有一行「检测到 VPN」的结论,恰好把别人能用来核查的那部分藏了起来。

相关文章