WebRTCリークテスト

このテストでわかること

ブラウザーでリアルタイム通信を行うWebRTCは、通常のWeb要求と違う経路を選ぶ場合があります。通話を始めずに候補を観測し、意図した経路か確認できます。プライベートIPやmDNS名は事業者の公開IPとは違います。TURNのrelay候補は中継サーバーのもので、利用者の直接の出口とは別に読む必要があります。

テストの手順

1. 接続状態を固定し、確かな情報があれば想定VPN IPを入力します。ブラウザー、プロファイル、補助サーバーを記録します。
2. 候補収集を実行します。任意でブラウザーのHTTPS IP確認を加え、その経路と比べられます。
3. 候補の種類、IP系統、公開範囲、比較状態を読みます。エラーや収集未完了を見落とさないでください。

測定の仕組み

ICEは接続確立に使う候補の仕組みです。まずSTUN/TURNなしで、次に設定したサーバーを使い、host、srflx、prflx、relayを取得します。 STUNは外から見える接続アドレスを調べ、TURNは中継を提供します。

データチャネルで開始するためカメラやマイクを要求しません。候補はブラウザー内に留まり、STUN/TURNと任意のIP確認先には接続元IPが見えます。

結果の読み方

公開IPが想定と一致

入力したVPN IPまたは適切なHTTPS測定と一致しています。この観測の整合性を示す結果です。

想定外の公開IP

別経路の可能性があります。系統と候補種類を確認してから、VPN外の出口か調べます。

非公開・中継・情報不足

ローカル名とrelayは別の情報です。失敗や空の収集はHTTPSが成功しても判定不能です。

変更前後の比較

1. 同じ端末とブラウザーで候補種類、系統、STUN/TURN設定、想定アドレスを保存します。
2. VPN経路またはWebRTCの関連設定を1つ変え、同じサーバーで収集します。
3. 公開候補を同じ系統と種類で比較します。想定出口は別途変更を確認できた場合だけ更新してください。

テストの限界

• 公開候補がなくても、すべてのWebRTC接続で望ましくない経路がないとは証明できません。
• 想定IPや有効な比較測定がなければ、公開候補を自動的に漏えいと呼べません。

必要に応じた対処

候補が想定外の事業者経路

アプリの経路とVPNのIP系統への対応を確認し、同じ補助サーバーで再試行します。

候補収集が不完全

ブラウザーの制限、ファイアウォール、サーバーの状態を確認し、不足中は判定不能を維持します。

よくある質問

出典と技術資料

• MDN · RTCIceCandidate.type