跳到主要内容

每隔几年,就会有某个浏览器功能对隐私的影响远超所有人的预期,WebRTC 就是其中之一。它让网页可以直接在浏览器里完成视频通话、屏幕共享或语音聊天,无需安装任何东西。为了做到这一点,浏览器必须弄清楚有哪些网络地址能够连到你的电脑,并且可以把发现的结果告诉网页。如果这份列表里包含网络运营商分配给你的公网地址,那么即使 VPN 隐藏了你的普通浏览流量,在这一项功能上看起来也像是被绕开了。

本文讲的是如何测试 WebRTC 泄漏:在 Chrome 和 Firefox 中怎样读取结果,怎样区分无害的私有地址与真正的暴露,以及出现问题时该调整什么。概念本身请看什么是 WebRTC 泄漏,这里重点放在测试。

WebRTC 泄漏测试到底在找什么

WebRTC 通过一个叫 ICE 的过程连接两端。简单说,浏览器会收集一份**候选地址(candidate)**列表,每一项都是一条可能连到它的途径。网页用几行脚本就能读到这份列表。

你可能看到四类候选地址:

  • 主机候选(host)。 你设备或本地网络上的地址,比如私有地址 192.168.1.20。按互联网地址分配规则,它们属于私有段,离开你的家或办公室就几乎没有意义。
  • 服务器反射候选(server-reflexive)。 浏览器联系辅助服务器(称为 STUN 服务器)时,对方看到的公网地址。这一项最关键。如果开着 VPN 时它是你运营商的地址,那就是泄漏。
  • 中继候选(relay)。 直连失败时使用的中继服务器地址,只在部分配置下出现。
  • mDNS 名称。 现代浏览器常用一个以 .local 结尾的随机名称取代你真实的本地地址,目的就是不暴露内网结构。

泄漏测试页面只是把这些候选地址收集起来再打印出来。测试并不能证明某个网站在窥探,而是展示任何网站都能读到什么。这一切背后的标准见 W3C WebRTC 规范,MDN 的 WebRTC API 指南则用开发者易读的方式讲了同样的概念。

准备干净的测试:先记基准,再管扩展

只有能与某个参照对比,结果才有用。请在连接 VPN 之前完成下面的步骤。

  1. 关闭 VPN,等待十秒。
  2. 在想要检查的浏览器里,用普通窗口打开 WebRTC 测试页面。
  3. 抄下所有候选地址:公网地址、私有地址和 .local 名称。这就是你的基准,这里的公网地址应当是你运营商的。
  4. 查看有哪些扩展正在运行。 广告拦截器、隐私扩展和某些 VPN 扩展都会改变 WebRTC 行为。把它们列出来。第一次测试请用禁用了扩展的配置文件或隐私窗口,这样看到的是浏览器自身的行为。
  5. 记下浏览器版本。 不同版本行为不同,以后重测时会用到。

有了基准,主测试的规则就很清楚:VPN 连接期间,列表里不能出现你基准里的公网地址。

如果想同时做一次常规泄漏检查,可在同一次会话里按如何检测 VPN 的 IP 地址泄漏的步骤操作。WebRTC 泄漏与普通网页请求泄漏是两回事,其中一项干净并不能说明另一项。

在 Chrome 中测试

Chrome 与其他基于 Chromium 的浏览器,WebRTC 行为大体相同。按下面的顺序做。

  1. 连接 VPN,等应用显示已连接。
  2. 打开一个新的无痕窗口。除非你特别允许,扩展在那里默认是关闭的。
  3. 加载 WebRTC 测试页面,等它收集完成,可能需要几秒钟。
  4. 逐行阅读列表,对每一行问:这是私有地址、.local 名称,还是公网地址?
  5. 把所有公网地址与你记下的基准对比。
  6. 再刷新两次。每次收集的结果可能略有出入。
  7. 如果你使用扩展,就逐个启用后再测一遍。调整 WebRTC 的隐私扩展可能去掉浏览器原本会显示的某个地址。

在当前版本的 Chrome 里,常见情形是用 .local 名称取代你的私有地址,外加一个公网地址。VPN 正常工作时,那个公网地址属于 VPN。如果出现两个公网地址,一个 IPv4、一个 IPv6,请把两个都与基准对比,因为泄漏常常藏在第二个里。较早的短格式地址在 RFC 791 中定义,IPv6 的行为在IP 泄漏的配套文章里有说明。

Chrome 没有为普通用户提供关闭 WebRTC 的内置开关。限制地址暴露的设置是留给扩展使用的,所以 Chromium 浏览器上的许多修复方案都以扩展形式出现。对待它们要像对待任何扩展一样谨慎:看清它们索要的权限,参见浏览器扩展与应用的对比。

在 Firefox 中测试

Firefox 开放了更多自身设置,对理解行为很有帮助。

  1. 连接 VPN 并确认它处于工作状态。
  2. 打开一个隐私窗口。
  3. 加载测试页面,等待候选地址收集完成。
  4. 像 Chrome 那样读取列表并与基准对比。
  5. 如果想做实验,在地址栏输入 about:config 并接受警告,搜索 media.peerconnection.enabled。
  6. 把该值设为 false 会关闭浏览器的 WebRTC。重新加载测试页面,应当完全看不到候选地址。
  7. 实验完成后改回 true,除非你确定自己不需要浏览器内通话。关闭 WebRTC 后,视频会议网站、语音聊天和一些文件共享工具会无法使用。

Firefox 还有一些设置,能让浏览器在处理地址时更保守,而不必完全关闭 WebRTC。在高级页面搜索 media.peerconnection 即可看到。修改高级设置要小心:改前记下原值,如果浏览器行为异常,用同一页面的重置选项恢复。

由于 Firefox 可以开关该功能,它是证明因果关系的好办法:开着 WebRTC 时有泄漏,关掉就没有,说明问题出在 WebRTC,而不是整个 VPN 隧道。

读懂候选地址列表:判断表

下面是在 VPN 已连接时,对看到的内容进行分类的方法。

列表中的候选地址 示例 是否泄漏 原因
以 .local 结尾的随机名称 a1b2c3.local 否 浏览器正在隐藏你的本地地址
私有 IPv4 地址 192.168.1.20 或 10.0.0.5 通常否 只在你自己的网络内有意义
公网地址,与 VPN 出口相同 与普通 IP 检测结果一致 否 流量显示为来自 VPN
公网地址,与基准相同 你运营商的地址 是 真实地址暴露给了网页
公网 IPv6 地址,与基准相同 很长的十六进制地址 是 IPv6 线路绕过了隧道
完全没有候选地址 空 否 WebRTC 被禁用或被阻止,通话可能无法使用
中继地址 不是你运营商的 否 属于某个中继服务

有两点要注意。第一,一个私有地址并非在所有场合都无关紧要:在共用的办公网络里,它会透露一点网络布局,有些人不愿意分享。第二,始终拿自己记录的基准去比,不要因为一个数字看着陌生就轻信它。

测试真实通话,而不只是测试页面

测试页面显示的是“可以被读取的内容”,通话测试显示的是“实际发生的事情”。这一步多花五分钟,能发现另一类问题。

  • 双人测试。 开着 VPN,请朋友和你一起加入一个浏览器内的视频通话。通话后再检查一次测试页面:有些浏览器在通话期间会暴露不同的候选地址。
  • 通话中切换网络。 在 Wi-Fi 上开始通话,然后切换到移动数据。WebRTC 在切换期间可能重新协商线路,之后立即运行测试页面。
  • 音视频质量。 开着 VPN 时通话卡顿并不是泄漏,但说明通话走了隧道。延迟的解释见为什么使用 VPN 网速会变化。
  • 权限提示。 当网站请求摄像头或麦克风时,确认你认识这个网站。与向错误页面授权相比,WebRTC 泄漏的风险要小得多。

对远程办公的人来说,最稳妥的习惯是在重要客户通话之前快速测一遍,而不是在通话中才发现问题。

公网地址泄漏时应该调整什么

从干扰最小的选项开始,逐步往干扰最大的选项走。

  1. 重新连接 VPN 并重测。 有时收集地址发生在隧道完全建立之前。
  2. 更新浏览器。 新版本往往能更好地限制地址暴露。
  3. 在没有任何扩展的干净配置文件里重测。 如果泄漏消失,说明某个扩展是原因。
  4. 使用浏览器自带的隐私设置(如果有),例如上文提到的 Firefox 选项,用能阻止暴露的最窄形式。
  5. 使用专门的隐私扩展限制 WebRTC 的地址处理(Chromium 浏览器适用)。先检查它的权限和口碑,之后再重测。
  6. 完全关闭 WebRTC,仅限于你在该浏览器里完全不需要通话的情况。可以考虑另用一个浏览器开会。
  7. 使用覆盖整台设备的 VPN 应用,而不是浏览器插件,让隧道保护整个设备而不是单个浏览器。浏览器扩展与应用的对比解释了原因。使用 XPASS 时,就是免费的 VPNclient 应用,用 My Pass 页面上的信息登录,参见下载页面。

每次改动之后都要再测一遍。在列表证明有效之前,不要假定修复成功。

WebRTC 测试中的常见错误

  • VPN 还在连接时就测试。 等到完全连接。
  • 把每个私有地址都当成泄漏。 私有地址段无法从更广的互联网访问。
  • 忘了 IPv6。 两种类型的地址都要在列表里找。
  • 相信旧结果。 浏览器更新、新扩展、新网络都会改变情况。
  • 关闭了 WebRTC 却忘了。 然后周一早上会议打不开,没人记得为什么。
  • 安装搜索到的第一个扩展。 一个声称修复隐私、却要求读取所有页面权限的工具,风险比泄漏本身更大。
  • 以为 WebRTC 测试干净就等于完全隐私。 它只涉及一项功能。Cookie、账号和浏览器指纹仍然能识别你,Cover Your Tracks 展示了浏览器除了地址之外还暴露多少信息。

小结

WebRTC 泄漏测试,就是收集浏览器提供给网页的候选地址,并检查其中有没有公网地址与你开启 VPN 之前的地址相同。先记基准,在干净的窗口里测试,在 Chrome 和 Firefox 中逐行读取列表,把私有地址和 .local 条目与公网条目区别对待。如果发现真实泄漏,采用有效的最温和修复,重新测试,并且不要关闭超出必要的功能,以保证通话仍能使用。

当你想要一个 VPN 来做这些测试时,可以在价格页面按自己的节奏比较一次性付费的套餐。

常见问题

WebRTC 泄漏测试究竟显示什么?

它显示浏览器愿意交给网页、用于通话等实时连接的网络地址列表。关键是这份列表里有没有一个与 VPN 地址不同的公网地址。

结果里出现 192.168.x.x 这样的本地地址算泄漏吗?

本身不算。192.168.x.x 或 10.x.x.x 这类私有地址只在你自己的网络内部有意义。真正的泄漏是在开着 VPN 时,出现属于你网络运营商的公网地址。

应该彻底关闭 WebRTC 吗?

只有在你从不使用浏览器内通话或会议时才这样做。在 Firefox 中关闭,或在 Chrome 中借助扩展关闭,可能让视频通话和部分网页应用无法使用。限制地址暴露的较窄设置往往是更好的折中。

更新浏览器后需要重新测试吗?

需要。浏览器更新可能改变地址暴露的方式。大版本更新后重测一次,用不了两分钟。

关于作者

Bob Kanokphon Thongdee,XPASS VPN 创始人

Bob Kanokphon Thongdee

  • XPASS VPN 创始人
  • eSIMonline.asia 联合创始人
  • 7 年以上网络营销经验
  • Cojourney Visa 与 Cojourney Travel 创始人

短途出行或忙碌的一个月,需要 VPN?

XPASS 提供按天数计算的预付通行证。一次付款,不会自动续费。

查看通行证

继续阅读

VPN 安全

什么是 WebRTC 泄漏?

WebRTC 让浏览器可以进行通话和视频,但也可能泄露本应被 VPN 隐藏的 IP 地址。本文讲清楚它如何发生,以及该怎么处理。

阅读约 9 分钟

VPN 安全

什么是 IP 泄漏?IPv4 与 IPv6 泄漏详解

VPN 已连接,网站却可能仍然看到你的真实 IP 地址。本文说明 IPv4 与 IPv6 泄漏是怎么发生的、如何测试,以及该怎么处理。

阅读约 9 分钟

设备指南

如何测试浏览器 VPN 扩展是否泄漏

一套可重复的浏览器 VPN 扩展测试流程:先记基线,再做四项检查,记录所见,并在地址漏出时决定下一步。

阅读约 10 分钟

VPN 安全

VPN 浏览器扩展与 VPN 应用有什么区别?

浏览器 VPN 扩展与完整的 VPN 应用名字相近,保护的流量却不一样多。本文对比覆盖范围、泄漏、权限与速度,帮你选出合适的一种。

阅读约 9 分钟

故障排除

如何检查 VPN 是否正常工作

VPN 显示已连接,也可能没有真正发挥作用。用这些检查确认流量确实经过 VPN,并解决 IP 不变的情况。

阅读约 7 分钟