whitelist-bypass ― ビデオ通話プラットフォームを利用してWebRTCトンネルを構築

whitelist-bypassは、承認済みドメインのリストのみを許可し、それ以外をすべてブロックするネットワークを標的として、商用ビデオ通話プラットフォーム経由でインターネットトラフィックをトンネリングするツールです。WebRTC経由のトンネリング自体は目新しいものではありません。今回筆者の目を引いたのは、このプロジェクトが「何に乗る」かという選択でした。

ホワイトリスト型の検閲は、ブロックリスト型とは性質が異なる問題です。ブロックリストの場合、それ以外のインターネットには到達可能なままなので、特に目立たないホスト上のプロキシを使えば大抵は外に出られます。

一方ホワイトリストはこれを反転させます。承認済みの宛先だけが名前解決・接続でき、それ以外はすべて失敗します。通過するためには、自分のトラフィックが「ブロック対象に見えない」だけでは足りず、承認済みの宛先「そのもの」でなければなりません。

whitelist-bypassの答えは、検閲側がすでに許可しているビデオ通話サービスにデータを送り込むというものです。検閲下のネットワーク上のデバイスがVK Call、Yandex Telemost、WB Streamのいずれかに一見普通の通話をかけると、自由なインターネット上のマシンがそれに応答し、本当に送りたいトラフィックはその通話の中に乗せて運ばれます。

この仕組みはすべて、そのプラットフォームのメディアサーバーが承認リストに載っているという前提の上に成り立っています。あるプラットフォームが許可されるかどうか、そしてその状態が続くかどうかは、ある瞬間におけるある一つのネットワークの事情にすぎません。ツール自身がそれをコントロールできるわけではないのです。

2種類のトンネル、そしてその理由

このプロジェクトは通話経由でデータを運ぶ方法を2種類用意しています。2つ目の方式が存在する理由は、1つ目が帯域制限を受けうるからです。

DCモードは、WebRTCのデータチャンネル――ブラウザがピアツーピアのファイル転送に使うのと同じプリミティブであるSCTPストリーム――を開き、そこにSOCKS5トンネルを通します。あなたのトラフィックはデータチャンネルのペイロードとなり、他の通話データと同様にプラットフォームのメディアサーバーによって中継されます。

ビデオモードは同じ役割を果たしますが、データチャンネルの代わりに、公開されたVP8のビデオトラックにデータをエンコードします。これが用意されている理由はリポジトリにも明記されています。一部のメディアサーバーはビデオを自由に通す一方でデータチャンネルにはレート制限をかけており、対応プラットフォームの少なくとも1つでは、そもそも配信者側のトラックがビデオでなければならないという事情があるためです。

つまりデータチャンネルが絞られたとき、トンネルはビデオ通話が絶対に手放せない唯一のストリームへと移動するわけです。両モードともトランスポート層より上のフレーミングと多重化の仕組みは共通しており、違いはどのストリームでバイト列を運ぶかだけです。

推奨される導入形態は両端ともヘッドレスで動作させるもので、Pion WebRTCスタックを用いた純粋なGo実装が、ブラウザを介さずプラットフォームのメディアサーバーと直接やり取りします。

リポジトリの中身は実際どうなっているか

筆者は現行のmainブランチ(コミット747f8f2、2026年9月3日時点)をクローンし、説明文ではなくソースコードそのものを読みました。このトンネルは実装が伴った本物のコードであり、READMEだけの約束ではありません。

relay/以下にある共有リレーは、SOCKS5プロキシ、データチャンネル・VP8双方のトンネル、コネクションの多重化機構、そして難読化機構を実装しています。各プラットフォーム向けには個別のヘッドレス「クリエイター」が用意されており、vk、telemost、wbstream、dionのそれぞれが独立したGoモジュールとして、ブラウザなしでプラットフォームのAPI経由で通話を作成・参加します。

難読化機構は意図的な設計です。通話の参加リンクから秘密鍵を導出してSHA-256でハッシュ化し、その鍵を使ってXChaCha20-Poly1305認証付き暗号化を行い、メッセージごとにランダムなノンスを用います。さらにキープアライブフレームにはパディングも施されています。

つまり通話内部のペイロードは、プラットフォーム自体のトランスポートセキュリティとは独立に、両端がすでに共有している情報――通話への参加に使うリンク――を鍵として暗号化されているわけです。ビデオトラックのタイミングを平滑化する処理は別のトランスポート層のコードであり、難読化機構そのものの一部ではありません。

マルチプラットフォーム対応も本格的です。検閲下側のクライアントである「ジョイナー」はAndroid、iOS、Linuxに対応し、自由なインターネット側の「クリエイター」はWindows、macOS、Linuxに対応します。Androidでは端末全体のVPNとして動作するため、すべてのトラフィックが通話を経由します。

iOSはもう少し複雑です。ソースツリーには2種類の形態が存在します。ローカルのSOCKS5エンドポイントを公開し、別アプリがそこに接続するプロキシアプリと、Appleの Network Extension機能を利用してシステム全体をルーティングするVPNアプリです。

v0.3.8リリースにビルド済みIPAとして同梱されているのはプロキシ版のみです。VPNアプリはソースコード上に存在し、ビルドターゲットも文書化されていますが、署名とその特権が必要になるため、利用したい場合は自分でビルド・署名する必要があります。

WebRTCトンネルの中での位置づけ

WebRTC経由でトンネルを運ぶという手法自体はすでに広く実践されています。Pion自身のエコシステム一覧にも、TorのSnowflake、weron、rtctunnel、WebRTCソケットプロキシなどが並んでおり、whitelist-bypassも同じリストに名を連ねています。したがって興味深いのはトランスポート方式そのものではなく、どのキャリアに乗せるかという選択です。

最も近い有名な親戚であるSnowflakeは、ボランティアのブラウザを一時的なWebRTCプロキシとして使い、Torに到達します。一方whitelist-bypassは特定の商用通話サービスを名指しし、それらが検閲者側から個別にホワイトリスト登録されていることに賭けています。

これはより鋭い賭けであると同時に、より脆いものでもあります。特定のプラットフォームが承認リストに載っているからこそうまく機能する一方で、そのプラットフォームがリストから外れた瞬間に機能しなくなります。ビデオトラックへのフォールバックも、一段下のレイヤーで同じ論理に従っています。安価なチャンネルが絞られたら、そのサービスが本来運ぶべき通話自体を壊さない限り制限できないストリームへと移るわけです。

Darknetは企業側の視点から、この種の秘匿トンネルという発想をこれまでも取り上げてきました。ProxyBlobはAzure Blob Storage経由でSOCKS5トンネルを運用し、クラウドのエンドポイントがあまりに平凡すぎてブロックされないだろうという賭けに出ていました。whitelist-bypassは、より厳格なフィルターに対して同じ構造的な手法を取っており、クラウドサービスの代わりに一般消費者向けプラットフォームを隠れ蓑にしています。

注意すべき主張

このプロジェクトは、ディープパケットインスペクション(DPI)から見るとこのトンネルは「通常のビデオ通話のように見える」と主張しています。これがこの手法の核心となる主張であり、同時に本稿では検証できない部分でもあります。

では実際に、通信内容としてビデオ通話のように見えるのでしょうか。それを確認するには、実際に検閲下にあるネットワーク、稼働中のDPI機器、そして長期にわたるトラフィック解析が必要であり、いずれもソースコードのレビューだけでは得られません。

慎重にならざるを得ない理由も存在します。実際のビデオ通話には、ビットレート、パケットのタイミング、動く映像に反応するコーデックのリズムといった特有のトラフィック形状があります。VP8トラックに大量のデータを押し込むトンネルは、その形状から逸脱してしまう圧力にさらされます。

このプロジェクトはVP8のペーシングを設定可能にし、キープアライブフレームにパディングを施すなど、まさにこの問題を意識した対策を用意しています。しかし、単純なプロトコルマッチングではなく統計的なトラフィック解析に耐えられるかどうかは経験的な問題であり、いたちごっこでもあります。これはコードを読むだけではわからない性質のものなので、「ビデオ通話のように見える」という主張は、プロジェクトの設計目標であって、実測結果ではないと捉えておくべきでしょう。

この設計からはさらに2つの小さな懸念点も生じます。まず、キャリアとなるプラットフォームがホワイトリストに留まり続けるかどうかにすべてが依存しており、その耐久性はあくまで政治的な事情次第だということです。また、難読化機構は参加リンクを鍵にしているため、セッションの安全性はそのリンクの配布方法に完全に依存します。つまりそのリンクを持つ者は誰でも鍵を手にしていることになります。

成熟度と出所

このリポジトリはMITライセンスで、スター数は約1,630、フォーク数は100件、そして活発に開発が続いています。リリースは17回に達し、直近(v0.3.8)は2026年7月、コミットは2026年9月まで続いており、6名のコントリビューターが1名を中心に開発を進めています。開始からわずか半年ほどのプロジェクトとしては、確かな勢いがあると言えます。

0.3.xというバージョン番号自体も、現状を正直に表しています。リリース成果物として配布されてはいるものの、まだ変化し続けているソフトウェアであり、安定版と呼べる段階には至っていません。

この「検閲対策」という目的には、実務上の帰結が一つ伴います。プロジェクトの公開窓口は企業のページではなくTelegramチャンネルであり、著者もGitHub上の匿名アカウント数名です。国家レベルのファイアウォールの向こう側にいるかもしれないユーザーを想定したツールとしては、これは特に驚くことではありません。

とはいえ、このリポジトリには名の知れた組織も、特定可能なメンテナーも、公開されたセキュリティ監査も存在しないということでもあります。実運用でこれを導入する者は、コードとビルドそのものを信頼することになるため、両方をよく読んでおくべきでしょう。

2026年9月6日、コミット747f8f2を対象にレビューを実施しました。ソースコードレベルの仕組み、ビルド面、リリース履歴、依存関係の選択については筆者自身が直接検証しましたが、実際の標的に対して稼働させたわけではなく、DPI耐性に関する主張はプロジェクト自身によるものであり、本稿で独立に確認したものではありません。

whitelist-bypassはこちらから入手できます: https://github.com/kulikov0/whitelist-bypass