WebRTC IP 泄露检测：从漏洞到功能

WebRTC——Web Real-Time Communication（网页实时通信）——的设计初衷是让视频通话、文件共享和点对点数据传输可以直接在浏览器中进行。为了建立这些连接，浏览器需要发现自身的网络接口，并与远端对等方协商连通性。这个过程会用到 STUN（Session Traversal Utilities for NAT，NAT 会话穿越应用程序）和 TURN（Traversal Using Relays around NAT，使用中继穿越 NAT）服务器，它们帮助浏览器发现自己的公网 IP 地址并穿越 NAT 防火墙。

其副作用非常强大：即使用户通过 VPN 连接，浏览器的 WebRTC 栈仍可能暴露隧道背后的真实 IP 地址。之所以如此，是因为 WebRTC ICE（Interactive Connectivity Establishment，交互式连通性建立）候选项包含了 VPN 无法屏蔽的本地网络接口地址。

泄露的原理

当浏览器创建 RTCPeerConnection 并收集 ICE 候选项时，它会向 STUN 服务器查询以发现自己面向公网的 IP。但它同时也会枚举本地网络接口——包括物理网卡的私网 IP。如果 VPN 只在 IP 层对流量做隧道，却没有配置浏览器的 WebRTC 栈专门使用隧道接口，真实 IP 就会通过 host 候选项泄露出去。

在 tracio.ai，我们会谨慎地探测这一行为。我们的 IP Intelligence 系统构造一个受控的 STUN 请求，并分析浏览器返回的 ICE 候选项。当来自 STUN 的公网 IP 与我们在服务器端看到的 IP 不一致时，我们就标记出 VPN 或代理。当本地接口 IP 揭示出一个与其声称的地理位置相矛盾的私网地址段时，我们会提高其可疑评分。

从漏洞到检测信号

大多数注重隐私的浏览器已经修复了这个泄露——Chrome 要求用户明确授权才能使用 WebRTC，Firefox 提供了禁用非代理 UDP 的设置。但这场军备竞赛仍在继续：一些 VPN 客户端并未正确配置 WebRTC，较旧的浏览器版本依然存在漏洞，而"已修复"与"仍在泄露"的 WebRTC 响应之间的行为模式，本身就是一个有用的信号。

我们的做法是把 WebRTC 响应视为一个复合信号：host 候选项是否存在、返回的 ICE 候选项数量、候选项的类型（host、srflx、relay）以及响应时延，都会贡献于设备指纹。即便没有任何 IP 泄露，WebRTC 的行为模式也是独特的。

TURN 服务器探测

除了 STUN，我们还会探测 TURN 服务器行为。TURN 中继通常在直接的点对点连接失败时使用——这在严格防火墙后的企业网络中很常见。TURN 分配（allocation）响应会揭示中继路径的信息：传输协议（UDP、TCP 还是 TLS）、中继地址以及分配的生存期。

我们的 SignalProbe 系统会向我们自己的中继服务器发送精心构造的 TURN 分配请求。响应时间、所支持的传输方式以及分配成功/失败的模式会因网络环境而异，为设备指纹提供了额外的信号多样性。

隐私方面的考量

我们想说清楚：tracio.ai 并不利用 WebRTC 泄露去对用户去匿名化。我们的系统检测何时正在使用 VPN，并将其作为风险信号上报。我们从不存储或暴露泄露的 IP 地址。信号是二元的："检测到 VPN 且存在 WebRTC 不一致"或"WebRTC 行为与直连一致"。

这种做法为欺诈防范团队提供了他们所需的信息——某个访客正在掩盖其真实位置——同时不损害个人隐私。该信号有助于检测协同欺诈攻击，即多个账户来自同一个被隐藏的位置。