WebRTCリークとは
WebRTCは、Google MeetやDiscordのようなサイトで、ビデオ通話、画面共有、端末どうしの直接のファイル転送を実現しているブラウザの技術です。2人を直接つなぐために、ブラウザは自分に届きうるアドレスをすべて洗い出さなければなりません。そこでSTUNサーバーにごく小さなリクエストを送ります。STUNサーバーは、そのリクエストがどのグローバルアドレスから来たかを返します。ブラウザは、ICE候補と呼ばれるこれらのアドレスを、Webページのスクリプトに渡します。
通話には便利でも、プライバシーの面では困ったことになります。この処理は、許可を求める画面も出さず、カメラやマイクも使わずに、どのページでも黙って始められるからです。STUNリクエストがVPNのトンネルの外を通ってパソコンから出ていくと、ページに伝わるのはVPNで表示されるアドレスではなく、プロバイダから割り当てられたアドレスです。これがWebRTCリークです。サイトには2つのアドレスが見え、その片方は隠そうとしていたアドレスです。
使い方
- ふだんネットを見るときと同じようにVPNやプロキシに接続してから、このページを開きます。
- 上の結果ボックスを待ちます。テストは自動で始まり、「テスト中」の行が1行の判定と短い説明に置き換わります。
- 「比較したアドレス」で、「あなたの接続(HTTP)」と「WebRTC経由のグローバルIP」を見比べます。「使用したSTUNサーバー」の行には、ブラウザに応答したサーバーが出ます。
- 「ICE候補」の表に目を通します。「種類」は候補の出どころ(
hostはあなたのデバイス、srflxはSTUNサーバーから見えたもの、relayはTURNサーバー)を示し、「区分」は、そのアドレスがグローバルか、ローカルネットワーク内か、キャリアのNATの内側か、.local名で隠されているかを示します。 - ブラウザの設定や拡張機能を変えたら、「もう一度テストする」を押します。VPN自体をオンやオフにした場合は、代わりにページごと読み込み直してください。HTTPのアドレスは、ページを読み込んだときに一度だけ取得しているためです。
一度VPNをオフにして試し、プロバイダから割り当てられたアドレスを控えておきましょう。トンネルを張ったあとは、そのアドレスが出てきてはいけません。
こんなときに
- 頼る前にVPNを見極める。トンネルを張った状態では、WebRTCのグローバルアドレスがHTTPのアドレスと一致するか、まったく出ないのが正常です。同じ種類なのに違うアドレスが出たら、対処が必要です。
- プロキシ拡張機能を確認する。ブラウザのプロキシ拡張機能は通常のページのリクエストを中継しますが、STUNリクエストはUDPなので、ブラウザにブロックさせない限りプロバイダからそのまま出ていくことがあります。
- IPv6の抜け穴を見つける。VPNの構成によっては、IPv4だけをトンネルに通し、IPv6には手を付けないものがあります。その場合、判定はWebRTCがIPv6アドレスも明かしていると伝えます。
- 管理対象ブラウザのポリシーを検証する。会社のノートPCでWebRTCを制限しているIT担当者は、テスト用のマシンでこのページを開き、ポリシーで許した範囲のものだけが候補の表に出ているかを確かめられます。
- 制限の厳しいネットワークでWebRTCアプリをデバッグする。表に
host候補はあってもsrflxがない場合、ポート3478でSTUNサーバーへ向かうUDPがおそらく遮断されています。そのネットワークで通話するには、TURNによる中継が必要になります。
テストの仕組み
- ブラウザはふだんの接続でこのページを読み込むので、当サイトのサーバーにはグローバルアドレスが1つ見えます。上の「あなたの接続(HTTP)」がそれです。
- ページは、誰にも発信しないWebRTC接続を作り、Cloudflareの公開STUNサーバー(
stun.cloudflare.com)に、見えているアドレスを問い合わせます。 - ブラウザが生成した候補をすべて一覧にし、そのうちグローバルなものをHTTPのアドレスと比べます。ここまでの手順はどれもあなたのブラウザ内で済ませ、当サイトへは何も送り返しません。
結果の読み方
- リークなし:WebRTCが報告するグローバルアドレスが接続のものと同じか、1つも出ない状態です。VPNを使っているなら、WebRTCもカバーされています。
- リーク:WebRTCが、同じ種類(IPv4とIPv4)で別のグローバルアドレスを報告しています。VPNをオンにしているなら、その2つ目のアドレスはほぼ間違いなくあなたの本来のアドレスです。
- 別のプロトコルが見えている:IPv6で接続しているのにWebRTCがIPv4アドレスも示している、またはその逆です。ふつうの家庭の回線なら、どちらもあなたのアドレスです。片方のプロトコルしかトンネルに通さないVPNでは、もう片方が漏れています。
- ローカルアドレスが見えている:
192.168.x.xや10.x.x.xのアドレスが出る場合、ブラウザが家庭内ネットワークでのデバイスのアドレスを共有しています。現在のChrome、Edge、Firefox、Safariは、初期設定でこれをランダムな.local名の陰に隠します。
WebRTCリークを止めるには
- ブラウザ拡張機能だけでなく、VPNのアプリを使う。システム全体にかかるVPNはSTUNの通信もトンネルに通しますが、プロキシ拡張機能は通さないことがよくあります。
- VPNのアプリや拡張機能にWebRTCリーク防止機能があれば、オンにします。
- Firefox:
about:configを開いてmedia.peerconnection.enabledをfalseにすると、WebRTCを完全にオフにできます。オンのままにしてVPNに任せる方法もあります。 - ChromeとEdge:切り替え用の標準の設定はありません。WebRTCのIP処理ポリシーを「disable non-proxied UDP」(プロキシを通らないUDPを無効化)にする、信頼できる拡張機能を使います。
- Brave:「設定」→「プライバシーとセキュリティ」→「WebRTC IP処理ポリシー」で、プロキシを通らないUDP通信を無効にする項目を選びます。
- Safari:初期設定でICE候補を制限しているため、リークはまれです。
どれかを変えたら、もう一度テストしてください。WebRTCをオフにするとブラウザ上の通話が使えなくなるので、機能を止めるよりVPN側を直すほうを優先しましょう。
このテストでわからないこと
問題なしという結果が当てはまるのはWebRTCだけです。DNSの問い合わせ、ブラウザのタイムゾーンや言語、フィンガープリントは別の経路です。タイムゾーンと言語の食い違いはトップページで、残りはフィンガープリントのテストで確認できます。DNSリークのテストは、専用のDNSサーバーが必要なので行っていません。できるふりはしたくないからです。
よくある質問
WebRTCリークとは何ですか?
Webサイトがブラウザのリアルタイム通信機能を使って、VPNやプロキシで隠しているはずのIPアドレスを知ってしまうことです。ページがSTUNサーバーに、どのアドレスが見えているかを問い合わせると、ブラウザはその答えをページのJavaScriptに渡します。
WebRTCリークが見つかったら、VPNが故障しているということですか?
そうとは限りません。しっかりしたVPNアプリの多くは、WebRTCの通信もトンネルに通します。リークが出る場合、たいていはVPNが通信の一部しか守っていない(ブラウザ拡張機能型のプロキシなど)か、IPv4はトンネルに通してもIPv6は通していないかのどちらかです。
WebRTCは無効にしたほうがいいですか?
ブラウザ上で通話をしない場合に限ります。Google Meet、Discord、Teamsなどのビデオ通話にはWebRTCが必要です。まずは、VPNに付いているWebRTC保護機能や、WebRTCが共有できるアドレスを制限するブラウザの設定を試すほうがよいでしょう。
テスト結果に.localで終わるアドレスが出るのはなぜですか?
最近のブラウザは、ローカルネットワーク上でのデバイスのアドレスを、mDNSで作った.localで終わるランダムな名前に置き換えます。プライバシーを守るための仕組みで、リークとは別物です。
このテストはIPアドレスを保存しますか?
いいえ。アドレスの突き合わせは、手元のブラウザだけで済ませます。当サイトのサーバーへのリクエストは、サーバーから見えるIPアドレスを取得する1回だけで、それも記録しません。
グローバルIPがまったく出てこないのは、どういうことですか?
ファイアウォール、ブラウザの設定、拡張機能、VPNのいずれかがSTUNリクエストを止めたためです。WebRTCのプライバシーという点では、これ以上ない結果です。
このテストが調べるのは、実行した時点での漏れ道1つだけです。結果はブラウザ、拡張機能、ネットワークによって決まり、そのどれかが変われば変わることがあります。VPNのセキュリティ監査ではありません。