WebRTCリークテスト

ブラウザーが複数のアドレスを知りうる理由

ウェブページの読み込みは単純なやり取りです。ブラウザーが尋ね、サーバーが答え、サーバーはあなたのネットワークについて一つのこと、つまりリクエストの送信元アドレスを知ります。ビデオ通話は仕組みが違います。2つのブラウザーが音声と映像を直接送り合おうとするため、それぞれが相手に、どこで自分に届くかを伝える必要があります。

これを担うのがWebRTCというブラウザーの機能です。通話の前に、使えそうなアドレスをすべて集めます。この段階をICE収集と呼びます。端末のネットワークインターフェースのアドレスを列挙し、STUNサーバーという公開の補助サーバーに一つだけ質問します。「私はどのアドレスから来ているように見えますか？」。それぞれの答えが「候補」になります。

どのウェブページでも、数行のJavaScriptでこの収集を始められます。通話も許可の確認も要らず、画面には何も表示されません。STUNへの質問がVPNのトンネルの外を通ったり、VPNが対象にしていないインターフェースを通ったりすると、候補の一覧にプロバイダーから割り当てられたアドレスが入ります。これがWebRTCリークです。

テストの内容

1. ページが読み込まれると、当サーバーがリクエストの送信元アドレスを記録し、それを持つネットワーク名を示します。これが枠01です。
2. ブラウザーが、どこにもつながらないWebRTC接続を開き、GoogleとCloudflareがそれぞれ運営する2つのSTUNサーバーに向けて、最大7秒間候補を集めます。
3. 候補を分類します。プライベートの範囲（10.x、172.16〜172.31、192.168.x）、キャリア共用のアドレス（100.64〜100.127）、リンクローカルアドレス、.local の名前はローカルとして分けます。残りが公開アドレスです。
4. 最大6つの公開アドレスを当サーバーに送り、それぞれが属するネットワークを返してもらいます。
5. 各公開アドレスを枠01と比べ、ラベルを付けます。

ラベルの読み方

一覧の下に、ローカルアドレスが見えているかどうかが表示されます。現在のブラウザーはそれを .local で終わるランダムな名前に置き換えるので、ウェブサイトには何も伝わりません。そのままの 192.168.x.x アドレスからもあなたにはたどり着けませんが、トラッカーが端末を見分けるのに使える情報が一つ増えます。

「公開アドレスなし」と「WebRTCはオフです」は、どちらもこの扉が閉じていることを意味します。ブラウザーが候補の収集を拒んだか、STUNの応答が返ってこなかったかのどちらかです。

漏れの塞ぎ方

VPNアプリで

「WebRTCリーク保護」「IPv6リーク保護」「キルスイッチ」といった項目を探し、3つともオンにしてください。プロバイダーがIPv6に対応していなければ、接続中はネットワークアダプターのIPv6を無効にしてください。ブラウザー拡張機能としてだけ提供されるVPNは、ページの通信を守ってもWebRTCは放置することがあるので、フル機能のアプリを選んでください。

Firefox

about:config を開き、media.peerconnection.ice.default_address_only を true にします。するとWebRTCはデフォルトの経路、つまりトンネルだけを使います。media.peerconnection.enabled を false にすると、WebRTCが完全に無効になります。

ChromeとEdge

組み込みのスイッチはありません。GoogleがWebRTC Network Limiterという拡張機能を公開しており、「Use my default public interface only」というオプションがあります。uBlock Origin拡張機能にも「Prevent WebRTC from leaking local IP addresses」という似た設定があります。

Brave

設定、プライバシーとセキュリティ、「WebRTC IP handling policy」で「Disable non-proxied UDP」を選びます。

変更するたびに、VPNに接続した状態でこのページを再読み込みしてください。目指すのは、公開アドレスの行がすべて「同じ」か「同じプロバイダー」になるか、公開アドレスがまったくない状態です。