IP漏えいはWebRTCだけが原因ではありません。DNS解決、タイムゾーンや言語、IPv6、サードパーティスクリプトも実際のネットワーク出口を露出させる可能性があります。各経路の確認方法と、出口と環境を整合させる方が安定する理由を解説します。
IPアドレスは、ネットワーク上のデバイスを一意に識別し、互いを認識して通信するための情報です。一意であるからこそ、外部に取得されると、そのアドレスを手がかりに利用者と行動が結び付けられ、閲覧傾向、おおよその位置、利用しているネットワーク事業者などを推測される可能性があります。ここでいう漏えいは、必ずしもデバイスが侵害されたという意味ではなく、隠すつもりだったネットワーク出口が別の経路から見えてしまうことを指します。
よく知られているのはWebRTCです。しかし日常的に繰り返し問題になりやすいのは、DNS解決、タイムゾーンや言語といった補助的なシグナル、IPv6、ページ上のサードパーティスクリプトなど、より目立ちにくい経路です。対処方法はそれぞれ異なりますが、いずれもセルフチェックで発見できます。
まずIPアドレスそのものを理解する
IPアドレスは、ネットワークに接続されたデバイスに割り当てられる数値ラベルです。主な役割は、ホストまたはネットワークインターフェースを識別することと、ネットワーク上の位置を示すことの2つです。現在は2つのバージョンが使われています。IPv4は32ビットの2進数で、192.168.1.1のようなドット区切りの10進数で表記します。理論上は約43億個のアドレスがありますが、割り当ての偏りやプライベートアドレスの利用により、実際に利用できる数は大きく減ります。IPv6は128ビットで、コロン区切りの16進数で表記され、アドレス空間は約3.4×10³⁸あります。実用上、各デバイスに一意のアドレスを割り当てられる規模です。
アドレスのバージョンは後でも重要になります。IPv6を経由して想定した経路を迂回できるかどうかに関わるためです。
DNS解決も同じ経路を通っているか
DNSはドメイン名をアドレスに変換する仕組みです。よくある見落としは、通信本体はトンネルを通っているのに、DNSリクエストだけがローカルISPのリゾルバへ送られている状態です。この場合、ページに表示される出口は正しく見えても、DNSの記録から発信元が分かってしまいます。
セルフチェック：DNS漏えいテストページを開き、表示されたリゾルバがどのネットワークに属しているか確認します。ローカルISPが表示される、または想定した出口地域と明らかに合わないDNSサービスが表示される場合、DNSはトンネルを通っていません。開発者ツールのNetworkパネルを開いたままページを数回更新し、ローカル解決へ直接接続している痕跡がないか確認する方法もあります。
タイムゾーンや言語といった補助シグナル
この経路は見落とされやすい点です。ネットワーク設定ではなく、環境そのものが情報を持っているからです。出口の所在地がある国を示しているのに、システムのタイムゾーン、ブラウザUIの言語、日付形式が別の地域を示している場合、その継続的な不整合自体が弱いシグナルになります。単一のシグナルだけで断定できなくても、複数が重なると環境を関連付ける材料になります。
セルフチェック：出口IPの所在地と、デバイスのタイムゾーン、言語、日付形式、優先キーボード配列を見比べます。複数地域で運用する場合は、同じ端末で何度もタイムゾーンを変更するのではなく、各環境を内部的に整合した設定の組み合わせにする必要があります。
IPv6は特に見落としやすい経路
IPv6による漏えいは気付きにくいことがあります。トンネルやプロキシがIPv4だけを処理している場合、デバイスはIPv6で直接外部へ接続できるため、テストページにIPv6アドレスが1行表示されるだけで実際の位置が分かることがあります。多くの環境ではIPv6が標準で有効になっており、優先度も高いため、利用可能なら通信が自然にIPv6を選ぶ場合があります。
セルフチェック：テストページでIPv4とIPv6の両方を同時に確認します。IPv6にローカルISPのアドレスが表示され、IPv4にはプロキシ出口が表示されるなら、その経路は開いています。IPv6も同じトンネルに通すか、不要な環境では無効にします。
サードパーティスクリプトと拡張機能
アクセス解析コード、広告スクリプト、カスタマーサポート用コンポーネント、フォント、CDNリソースなどは、サイト本体とは別のネットワーク先へリクエストを送ることがあります。これらの通信が設定したプロキシルールに必ず従うとは限らず、フロントエンドから取得できる情報を伴う場合もあります。ブラウザ拡張機能も同様で、インストール数が増えるほど通信を発生させる箇所が増え、出所が不明なものは特に注意が必要です。
セルフチェック：同じページをプライベートウィンドウで開き、まず拡張機能なしでアクセスし、次に拡張機能を有効にしてアクセスして、テスト結果を比較します。開発者ツールのNetworkパネルでドメインごとに絞り込み、ローカルへ直接つながる通信や、ページ本体と関係のないサードパーティドメインがないか確認する方法もあります。
WebRTCも個別に確認する
WebRTCはリアルタイムの音声・映像通信向けに設計されており、ローカルネットワーク情報を取得することがあります。制限が緩いと、WebページがWebRTC経由でローカルアドレスや実際のアドレスを読み取れる場合があります。WebRTCはIP漏えいそのものの代名詞のように扱われがちですが、実際には複数ある経路の1つにすぎません。テストページでは通常、外部IPとWebRTCで露出したIPが併記されるため、両者が一致しない場合は確認が必要です。
項目ごとに無効化するより、出口と環境を整合させる
上記の経路は個別に設定をオフにすれば多くを閉じられますが、その方法で得られたクリーンな状態は不安定です。ネットワークの変更、ブラウザの更新、新しい拡張機能の導入などで、設定が気付かないうちに既定値へ戻る可能性があります。
より安定するのは逆の考え方です。まず、その環境がどの地域の利用者として見えるべきかを決め、そのうえで出口、DNS、タイムゾーン、言語、IPv6の状態、フィンガープリントパラメータを1つの整合した組み合わせとして設定します。テストの目的は、どのスイッチが切れていないか探すことではなく、各設定が互いに矛盾していないか確認することです。
アカウント数が増えると、この整合性を手作業で維持するのはほぼ不可能になります。PurpleMarkのような複数アカウント向け環境ツールでは、プロキシ設定、Cookie、ローカルストレージ、フィンガープリントパラメータを同じブラウザ環境に結び付けます。その環境を開けば同じ設定が適用されるため、1つのアカウント、1つの環境、1つの出口という関係を安定させやすくなり、設定ミスによる意図しない露出を減らせます。
ただし前提があります。ネットワーク出口をうまく隠しても、プラットフォームが定めるアカウントの本人性や数量に関するルールは変わりません。環境分離はアカウント同士の干渉を避けるためのものであり、アカウント構成自体は引き続きプラットフォームのルールに従う必要があります。
よくある質問
Webサイトはどうやって同じ人だと判断するのですか？ リクエスト元のIPだけでなく、Cookie、ブラウザフィンガープリント、WebRTC、DNS解決経路などを組み合わせて確認することがあるため、IPだけを変更しても十分とは限りません。
IPを変えれば安全ですか？ 必ずしもそうではありません。複数アカウントでフィンガープリント、タイムゾーン、言語、フォントの特徴が非常に似ていれば、プラットフォーム側で関連付けられる可能性があります。
どのくらいの頻度で確認すべきですか？ ネットワークやプロキシを変更したとき、新しいアカウント環境を追加したときに確認し、通常運用中も定期的に再確認します。
すべての経路をまとめて考える
IP漏えいは、誰かがデバイスへ侵入したことで起きるケースよりも、設定上の隙間から起きるケースの方が一般的です。トンネルがすべての通信を覆っていない、DNSが別経路を通っている、IPv6が直接接続している、タイムゾーンや言語が出口と合っていない、サードパーティスクリプトが追加のシグナルを露出している、といった状態です。どの経路から漏れているかを把握する方が、設定項目を丸暗記するより実用的です。そして、出口と環境を一貫した組み合わせにする方が、単一の機能を無効化するより堅牢です。
