白名单绕过：通过视频通话平台建立 WebRTC 隧道
内容提要
whitelist-bypass 项目利用 WebRTC 将流量伪装成 VK、Yandex 等视频通话，穿透仅放行白名单的网络。它提供数据通道和 VP8 视频轨两种隧道模式，使用 XChaCha20 加密载荷，支持多平台无头运行。其抗 DPI 能力尚未经独立验证，且完全依赖平台持续留在白名单上。
延伸解读
白名单环境下的隧道逻辑
文章指出，白名单审查与黑名单封锁不同：只有被批准的地址能解析和连接，其他一律失败。因此流量必须“成为”被批准的地址，而不仅是伪装成不被封锁的对象。whitelist-bypass 将数据发往审查者已放行的视频通话服务，如 VK Call、Yandex Telemost 或 WB Stream，自由互联网一侧接听，真实流量藏于通话中。这要求平台媒体服务器在白名单上，但平台是否被允许是动态事实，工具无法控制。
两种隧道模式与回退设计
项目提供 DC 和 Video 两种模式。DC 模式打开 WebRTC 数据通道，基于 SCTP 流推送 SOCKS5 隧道；Video 模式将数据编码到 VP8 视频轨。后者存在是因为部分媒体服务器会限速数据通道却放行视频，且至少一个受支持平台要求发布者轨道为视频。两种模式共用分帧与复用逻辑，差别仅在于字节由哪条流承载。这种回退设计旨在应对数据通道被掐紧的情况。
加密与密钥来源
混淆器从通话加入链接派生密钥，经 SHA-256 哈希后，使用 XChaCha20-Poly1305 认证加密，每条消息随机 nonce，并对保活帧填充。这意味着通话内部载荷独立于平台传输安全进行加密，密钥来自两端共享的加入链接。因此，一次会话的安全性取决于链接的传播范围：谁拿到链接，谁就拥有密钥。文章提醒，这既是设计选择，也是安全边界。
抗 DPI 论断与部署风险
项目称隧道对 DPI 而言“看起来就是一次普通的视频通话”，但文章强调这未经独立验证。真实视频通话有码率、包时序等特征，在 VP8 轨推批量数据可能偏离该形态。项目提供可配置 VP8 节奏和填充保活帧，但能否扛住统计型流量分析仍是经验问题。此外，工具完全依赖承载平台持续留在白名单上，耐久度受政治事实影响；仓库无具名组织、无公开安全审计，部署需自行审读代码与构建。
Q&A
whitelist-bypass 是什么？它主要解决什么问题？
whitelist-bypass 是一个利用 WebRTC 将互联网流量通过商业视频通话平台（如 VK Call、Yandex Telemost、WB Stream）打隧道的工具，专门针对只放行白名单域名、其余全部封杀的审查环境。它让受审查网络中的设备发起一通看似普通的视频通话，将真实流量隐藏其中，从而穿透白名单限制。
whitelist-bypass 的 DC 模式和 Video 模式有什么区别？为什么需要两种模式？
DC 模式通过 WebRTC 数据通道（SCTP 流）承载 SOCKS5 隧道；Video 模式则将数据编码到 VP8 视频轨上。Video 模式的存在是因为有些媒体服务器会对数据通道限速，却对视频流放行，且在某些平台上发布者轨道必须是视频。当数据通道被限速时，隧道可迁移到视频流上。两种模式在传输层之上共用同一套分帧与复用逻辑。
whitelist-bypass 如何保证通话内部数据的安全？
它使用从通话加入链接派生的密钥（经 SHA-256 哈希），采用 XChaCha20-Poly1305 认证加密，每条消息使用随机 nonce，并对保活帧进行填充。这样通话内部的载荷独立于平台自身的传输安全进行加密，密钥来自两端本就共享的加入链接。
whitelist-bypass 支持哪些平台？部署方式是什么？
它支持多平台无头运行：受审查一侧的 joiner 客户端面向 Android、iOS 和 Linux；自由一侧的 creator 面向 Windows、macOS 和 Linux。在 Android 上以系统 VPN 形式运行，iOS 有代理应用和 VPN 应用两种形态（v0.3.8 仅代理应用提供预编译 IPA）。两端均以无头方式运行，基于纯 Go 和 Pion WebRTC 栈，直接与平台媒体服务器通信，无需浏览器。
whitelist-bypass 声称能抗 DPI，这个说法可靠吗？
项目称隧道对深度包检测（DPI）而言“看起来就是一次普通的视频通话”，但这是项目的设计目标，而非经独立验证的结论。真实视频通话有特征性的流量形态（码率、包时序、编解码器节奏），隧道在 VP8 轨中推批量数据可能偏离这种形态。项目提供了可配置的 VP8 节奏和带填充的保活帧来应对，但能否扛住统计型流量分析仍是经验问题，需要真实受审查网络和实时 DPI 设备验证。
使用 whitelist-bypass 有哪些主要风险和限制？
主要风险包括：完全依赖承载平台持续留在白名单上，一旦平台被移出名单即失效；混淆器密钥来自加入链接，会话安全性取决于链接的传播范围，谁拿到链接谁就有密钥；项目没有具名组织、可识别维护者或公开安全审计，部署需自行信任代码和构建。此外，抗 DPI 能力未经独立验证。
whitelist-bypass 与 Snowflake 等其他 WebRTC 隧道有何不同？
Snowflake 使用志愿者浏览器作为临时 WebRTC 代理连接 Tor，而 whitelist-bypass 指名指向商业视频通话服务（如 VK、Yandex），并押注这些平台会被审查者列入白名单。这是一个更锋利也更脆弱的赌注：它能工作恰恰因为具体平台在批准名单上，平台一旦被移出名单就立刻失效。
