所以你VPN泄露的原因是WebRTC？

–不应该怪罪WebRTC，而你们所谓的VPN才是元凶

作者：Philipp Hancke（原文链接）

翻译：刘通

原标题：So your VPN is leaking because of Chrome’s WebRTC…

我们已经多次报道了“WebRTC泄露你IP地址”的相关问题。这个话题在博客中一次又一次的出现，每次都会带来巨大的震撼和恐慌。最近这种情况再次发生，所以本文时对这个所谓问题的观察更新。

最近voidsec的一篇名为VPN泄露的文章，重点指出了一百多个VPN服务中有十九个通过WebRTC泄露IP地址。虽然文章中关于WebRTC的一些细节并不完全正确，但是其中得到的结果仍然令人感兴趣。本质上就是一个人一个接一个地测试每个VPN服务，然后记录下它们的表现。这并不是一个让人感兴趣的研究，但像这样的详尽研究通常会发现一些有趣的结果。

Google WebRTC负责人Justin Uberti之处了一件有趣的事情：很多被列为易受攻击的服务都有名义上的“代理”。其中很多是Chrome扩展程序。安装其中的一些扩展程序仅仅是改变了代理设置。那么，让我们来看看WebRTC和代理。

测试SOCKS代理

测试WebRTC在SOCKS代理后的表现最简单的办法是什么呢？如果你安装了ssh并且主机使用它进行测试非常容易：

1ssh -D localhost:3128 your-host

上述指令在端口3128上运行本地SOCKS代理。更改你的Chrome或系统代理设置以使用它。现在运行提供的测试网站。

这显示了我登记的主机IP地址以及我的实际公共IP地址。这是非常令人惊讶的，我还以为这个问题我很久以前就解决了。

RTCWeb IP处理

WebRTC IP处理草案中解释了WebRTC引起的问题，允许网页列举IP地址作为ICE过程的一部分，并指定了代表性和隐私之间不同权衡的多种模式。模式4是最严格的。它在代理设置时阻止UDP：

模式4：强制代理：这与模式3相同，但所有WebRTC媒体流量都通过代理（如果已配置）强制进行。 如果代理不支持UDP（就像所有HTTP和大多数SOCKS [RFC1928]代理一样），或者WebRTC实现不支持UDP代理，则UDP的使用将被禁用，并且TCP将用于发送和 通过代理接收媒体。 除了与通过代理服务器发送所有WebRTC媒体相关的任何性能考虑外，使用TCP将导致媒体质量下降。https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-06#section-5.2

如何让Chrome使用代理？

再读一遍草案，Chrome的行为与此处指定的相同，模式4不是默认模式，所以不应指望它自动路由到代理。

那么是否有Chrome API让它的行为与模式4中指定的一样？事实上有这项：

https://developer.chrome.com/extensions/privacy#property-network

它有一个名为disable_non_proxied_udp的模式。 自2016年1月发布Chrome 48以来，该API已经可用。

Chrome网络限制器扩展（Network Limiter Extension）

切换到此模式进行测试的最简单方法是使用WebRTC团队在2015年底发布的Network Limiter扩展。在选项中选择：

然后再次进入测试网站。 它将不再显示来自WebRTC的本地IP地址：

不发生泄漏的情况了！至少只有公共IP地址会泄漏。

Firefox浏览器呢？

在Firefox中有不同的设置。扩展可以更改这些设置的about:config值，或者用户可以轻松地自行完成此操作：

# media.peerconnection.ice.default_address_only – 将此设置为true从本质上提供模式2

# media.peerconnection.ice.no_host – 设置此项及default_address_only提供模式3

# media.peerconnection.ice.proxy_only – 将其设置为true会强制改为模式4，且禁用UDP

确保你的VPN提供商使用浏览器的隐私设置

如果那些易受攻击的“VPN”提供商实际上使用Chrome提供的隐私选项，那么这种泄露有可能就会避免。

如果你是其中一个被列为易受攻击的扩展程序的开发人员，请务必使用可用的API。请注意，由此可能导致更多媒体流量通过你的代理服务器。如果你遇到这种情况的话，请不要在你的营销材料中将其错误地归咎于WebRTC。