プロキシがHTTP通信を処理していても、WebRTCはSTUN/ICEを使ってUDP経由で候補アドレスを交換します。本記事では、ローカルアドレスやプライベートアドレスが露出する条件と、ネットワーク出口とブラウザ環境を整合させる考え方を説明します。
プロキシを用意し、IP確認ページでも想定どおりの地域と通信事業者が表示されている。ネットワーク上の身元はきれいに整ったように見えます。ところが漏えいテストを開くと、WebRTCの欄が赤くなり、実際に利用している回線のアドレスが表示されることがあります。
すぐにプロキシを交換する必要はありません。多くの場合、問題はプロキシの品質ではなく、プロキシが管理できない通信にあります。
プロキシが扱うのはHTTP、WebRTCは別の経路を使う
プロキシはネットワーク層で動作します。ブラウザ拡張機能として実装されていても、システム全体のトンネルであっても、対象はHTTP/HTTPSリクエストであり、その通信をプロキシの出口から送ります。
WebRTCは別の仕組みです。ブラウザに組み込まれたリアルタイム通信機能で、音声・映像通話やP2P転送に適した経路を見つけるため、外部サーバーへSTUN問い合わせを能動的に送ることがあります。これは「そちらから見た私のアドレスは何か」を尋ねる処理で、結果はICE候補として整理されてWebページへ渡されます。これらの問い合わせはUDPを使い、HTTPトンネルとは独立した経路です。
そのため、Webページのリクエストはプロキシから出ている一方で、ブラウザがローカルアドレスを同時に知らせるという不一致が生じます。プロキシを設定すればネットワーク上の身元全体が自動的に整うと考えることが、この問題の最も一般的な出発点です。
漏れるのは公開IPだけではない
ICE候補には通常、2種類のアドレスが含まれます。1つは公開アドレスで、実際に利用している通信事業者側の出口です。もう1つはローカルアドレスで、たとえば192.168から始まるプライベートアドレスや、場合によっては仮想ネットワークアダプターのアドレスです。
プライベートネットワークのアドレスだけでは大きな意味はありません。ほとんどのPCが持っているからです。ただし十分に安定しているため、複数アカウントで候補アドレスが繰り返し重なると、プラットフォームが同一端末に関連付ける際の追加シグナルになることがあります。公開アドレスはさらに直接的で、実際の通信事業者やおおよその地域を示します。どこまで細かく判別できるかは相手側の実装次第ですが、実際のアドレスに近いほど関連付けは容易になります。
実際にWebサイトから読まれるのはどんな場合か
すべてのWebサイトが読み取るわけではありません。アドレス交換には、ページ側がRTCPeerConnectionオブジェクトを能動的に作成する必要があり、一般的なコンテンツページでは通常不要です。
実行する可能性があるのは、ビデオ会議、オンラインカスタマーサポート、一部のライブ配信ページなどリアルタイム通信を必要とするサイト、広告や不正対策を主要な収益・運用要素とするサイト、そしてリスク管理の仕組みが整ったプラットフォームなどです。こうした読み取りは画面上から見えない場所で行われ、収集後にどのように利用されるかが通知されるとは限りません。
Webサイトとは無関係なケースもあります。プロキシが再接続したりノードを切り替えたりする短い間に、ブラウザのSTUNリクエストがローカルネットワークへ流れることがあります。時間は短くても、1回記録されるには十分です。
よくある3つの失敗パターン
ブラウザ拡張型のプロキシは、通常HTTP/HTTPSリクエストだけを引き受けます。UDPは対象外で、画面上で「グローバル」を選んでもこの点は変わりません。
システム全体のプロキシは、端末全体の通信を覆うため一見すると完全に見えます。しかし候補アドレスの収集はローカルのネットワークインターフェースへ直接バインドし、システムのルーティングテーブルを回避できる場合があり、この部分でトンネルに漏れが残ります。
3つ目は技術だけの問題ではなく、判定側の運用変化です。リスク管理システムでは、WebRTCアドレスをアカウント関連付けの参考シグナルの1つとして扱う例が増えています。以前は測定されなかった、あるいは重視されなかったデータが、現在は判定に含まれることがあります。
重要なのは1つのスイッチを切ることではなく、出口の整合性
考え方はいくつかあります。業務上リアルタイム通信が一切不要なら、WebRTCを無効にするのが最も簡単です。ただし、ビデオ通話やオンラインカスタマーサポートなどの機能も使えなくなります。
機能を残す必要がある場合は、WebRTCレイヤーで返されるアドレスをプロキシ出口と一致させる方法が一般的です。より堅牢にするなら、STUNリクエストもプロキシ経由で転送し、インターフェースからローカルアドレスが露出しないようにします。P2Pやビデオ通話が必要な場合は、HTTP層だけでなくUDP通信全体をプロキシ経由にする必要があります。
陥りやすい誤解は、WebRTCだけを無効にすれば環境全体がきれいになるという考え方です。重要なのは、ネットワーク出口、DNS解決、IPの帰属とASN、タイムゾーンと言語、端末特性が全体として相互に整合していることです。どれか1つでも合わなければ異常シグナルになり得ます。WebRTCは、その中でも特に見落とされやすい要素の1つにすぎません。
確認方法は簡単です。ノードを切り替えた後と、本格的に利用する前にそれぞれ1回ずつ漏えいテストを行い、WebRTC欄にプロキシ出口、ローカルアドレス、実際の公開アドレスのどれが表示されるか確認します。通常のIP確認だけではこの項目は分かりません。
ブラウザエンジン層の環境分離では、環境ごとにWebRTCのアドレス方針を個別設定し、その環境に割り当てたネットワーク出口と組み合わせることができます。PurpleMarkが提供するのもこの種の機能です。複数環境が同じ出口を共有したり、各環境のアドレス方針が整合していなかったりすると、分離の意味は大きく低下します。
以上は技術的な仕組みの説明です。関連ツールは、各プラットフォームのルールと現地の法律を守って利用してください。
