白名单绕过：通过视频通话平台建立 WebRTC 隧道

本文来自：Darknet
原文：https://www.darknet.org.uk/2026/09/whitelist-bypass-webrtc-tunnels-through-video-calling-platforms/

whitelist-bypass（白名单绕过）把互联网流量通过商业视频通话平台打隧道，针对的是那种只放行一份核准域名名单、其余全部封杀的互联网环境。用 WebRTC 打隧道并不新鲜。真正让我注意的是，这个项目选择骑在谁背上。

项目地址：https://github.com/kulikov0/whitelist-bypass

白名单审查和黑名单封锁是两类不同的问题。黑名单之下，互联网的其余部分仍可访问，所以在某个不起眼的主机上挂个代理，通常就能出去。

白名单把这件事反过来。只有被批准的地址能解析、能连接；其他一律失败。想穿过去，你的流量必须”成为”某个被批准的地址，而不只是看起来不像被封锁的对象。

whitelist-bypass 的答案是：把你的数据发给审查者已经放行的视频通话服务。受审查网络里的设备发起一通看起来完全普通的电话——打给 VK Call、Yandex Telemost 或 WB Stream；自由互联网一侧的机器接听，你真正想要的流量就藏在这通电话里。

这一切都建立在一点上：该平台的媒体服务器在白名单上。某个平台是否被允许、又能否持续被允许，是”某个网络在某个时刻”的事实。这个工具控制不了。

两条隧道，以及为什么要有两条

项目提供两种在通话中承载数据的方式，第二种的存在，是因为第一种可能被限速。

DC 模式打开一条 WebRTC 数据通道：一条 SCTP 流，也就是浏览器做点对点文件传输时用的同一种原语，并在上面推一条 SOCKS5 隧道。你的流量变成数据通道的载荷，由平台的媒体服务器像转发其他通话数据一样转发。

Video 模式做同样的事，但把数据编码到一条对外发布的 VP8 视频轨上。它存在的原因，仓库里写得很清楚：有些媒体服务器会给数据通道限速，却对视频一路放行；而在至少一个受支持的平台上，发布者的轨道必须是视频。

所以当数据通道被掐紧时，隧道就迁移到视频通话离不开的那条流里。两种模式在传输层之上共用同一套分帧与复用逻辑，唯一的差别只是字节由哪条流承载。

推荐的部署方式在两端都以无头（headless）方式运行：纯 Go，基于 Pion WebRTC 栈，直接与平台的媒体服务器通信，不引入浏览器。

仓库里实际有什么

我克隆了当前的 main 分支（提交 747f8f2，2026 年 9 月 3 日），读的是源码，而不是对它的描述。这个隧道是真实的代码，不是 README 上的承诺。

relay/ 下的共享中继实现了 SOCKS5 代理、数据通道隧道与 VP8 隧道、一个连接复用器和一个混淆器。各个平台由各自独立的无头创建器处理（vk、telemost、wbstream 和 dion），每个都是自己的 Go 模块，无需浏览器即可通过平台 API 创建或加入通话。

混淆器是一个刻意的设计选择。它从通话的加入链接派生出密钥，用 SHA-256 哈希，再以该密钥配合 XChaCha20-Poly1305 认证加密和每条消息随机的 nonce；它还会对保活帧做填充。

也就是说，通话内部的载荷独立于平台自身的传输安全进行加密，密钥来自两端本就共享的东西：用来加入通话的那个链接。视频轨时序的平滑处理属于另一套传输代码，不属于混淆器。

它确实是多平台的。joiner 也就是受审查一侧的客户端，面向 Android、iOS 和 Linux；creator 自由一侧面向 Windows、macOS 和 Linux。在 Android 上它以系统 VPN 的形式运行，因此所有流量都走这通电话。

iOS 更复杂一些。源码树里带有两个形态：一个代理应用，暴露本地 SOCKS5 端点供其他应用指向；一个 VPN 应用，使用苹果的 Network Extension 能力做系统级路由。

v0.3.8 版本里只有代理构建以预编译 IPA 的形式发布。VPN 应用在源码里，构建目标也有文档说明，但它需要签名和相应能力，所以想要的话得自己构建并签名。

构建文档提示

如果你从源码构建，不要完全照着 README 的构建表走。表里写 Android 应用用 ./build-app.sh；这个脚本不在仓库里。实际存在的脚本是 build-android.sh、build-joiner-app.sh、build-go.sh、build-headless.sh 等等。预编译的 Android、iOS 和桌面二进制在 Releases 页面，不受影响；出现偏差的是从源码构建的说明与代码。

它在 WebRTC 隧道谱系中的位置

用 WebRTC 承载隧道早已是老路。Pion 自家的生态列表里就有 Tor 的 Snowflake、weron、rtctunnel 和一个 WebRTC socket proxy，whitelist-bypass 也在同一份名单上。所以有意思的部分不是传输方式，而是它骑的载体。

Snowflake 是最知名的近亲，它用志愿者浏览器充当临时 WebRTC 代理去连 Tor。whitelist-bypass 则指名指向商业通话服务，并押注它们会被审查者逐个列入白名单。

这是一个更锋利的赌注，也更脆弱。它能工作，恰恰因为某个具体平台在批准名单上；那个平台一旦被移出名单，它立刻失效。视频轨回退是同一条逻辑下沉一层：当便宜的通道被掐紧，你就转到那个”服务若想限速就会弄坏自己存在的意义——通话”的流上。

Darknet 以前从企业侧报道过隐蔽隧道这个思路。ProxyBlob 把 SOCKS5 隧道跑在 Azure Blob Storage 上，赌的是云端点太普通以至于不会被封。whitelist-bypass 面对更严的过滤器做了同样的结构性动作，只不过掩护物从云服务换成了消费级平台。

需要谨慎对待的那句论断

项目称，对深度包检测（DPI）而言，这条隧道”看起来就是一次普通的视频通话”。这是那句承重的论断，也是本文无法验证的一句。

那么它在线上真的看起来像视频通话吗？要确认这点，需要真实的受审查网络、实时的 DPI 设备，以及持续的流量分析，这些都不是读一遍源码能给你的。

确实有理由保持谨慎。真实的视频通话有特征性的流量形态：码率、包时序，以及编解码器对运动画面做出反应的那种节奏。一条在 VP8 轨里推批量数据的隧道，面临着偏离这种形态的压力。

项目确实提供了可配置的 VP8 节奏（pacing）和带填充的保活帧，这些控制项显然是冲着这个问题去的。但结果能否扛住统计型流量分析，而不只是简单的协议特征匹配，这是一个经验问题，也是一场军备竞赛。它不是能从代码里读出来的属性，所以我会把”看起来像视频通话”当作项目的设计目标，而不是实测结论。

由此还有两条较小的提醒。它完全依赖承载平台持续留在白名单上，所以它的耐久度只等于那个政治事实的耐久度。另外，混淆器的密钥来自加入链接，所以一次会话的安全性只等于那个链接的传播范围：谁拿到链接，谁就有密钥。

成熟度与来源

仓库采用 MIT 许可，约 1630 个 star、100 个 fork，且开发活跃：十七个版本，最新的 v0.3.8 发布于 2026 年 7 月，提交一直延续到 9 月，六位贡献者、由一人主导。对一个刚满六个月的项目来说，这是真实的势头。

0.3.x 版本线对自己的定位也很诚实，这是通过发布产物交付、且仍在变化的软件，不是已经定型的正式版。

反审查的用途带来一个实际后果：项目的公开联系方式是一个 Telegram 频道，而不是公司页面；作者身份是几个化名的 GitHub 账号。对于一个用户可能身处某国防火墙另一侧的工具来说，这并不奇怪。

但这也意味着，仓库没有指向任何具名组织、没有可识别的维护者、也没有公开的安全审计。任何真要在实际环境部署它的人，都是在信任这份代码和这次构建，两者都该自己读一遍。

本文于 2026 年 9 月 6 日针对提交 747f8f2 复核。我直接验证了源码层面的机制、构建面、发布历史和依赖选择；我没有对真实目标运行过它，它关于抗 DPI 的说法是项目自己的，本文未做独立确认。