WebRTC・DNS・IPv6の漏えいテスト：結果の読み方

IP 確認ページを開いて、アドレスが想定した出口に変わっているのを見ると、設定がすべて反映されたと思いがちです。しかし、それはそのウェブリクエストがこのアドレスを使ったことを示すだけです。ドメイン名解決、WebRTC 通信、IPv6 リクエストは、必ずしも同じ経路を通るとは限りません。

IP または DNS リークが発生しているかを判断する鍵は、「ページにいくつのアドレスが表示されるか」ではなく、情報やトラフィックが保護を意図した経路の外に出ていないかです。 内部アドレス、パブリック DNS、出口と異なる地域名が表示されても、それだけでリークと結論づけることはできません。

この記事は、自分のデバイス、ブラウザ、ネットワーク設定をチェックするためのものです。検出結果は今回観測可能な環境を示すものであり、デバイス上のすべてのアプリケーションのプライバシーを保証するものではありません。

まず、どのトラフィックを保護したいかを決めましょう

テストを始める前に、簡単な質問に答えてください。設定しているのはブラウザのプロキシですか、システムのプロキシですか、それともネットワークルートを引き受ける VPN ですか？

それぞれの適用範囲は異なる可能性があります。ブラウザ拡張機能は必ずしも他のアプリケーションを処理しません。システムプロキシも、すべてのプロトコルがプロキシ設定に従うとは限りません。VPN が IPv6、DNS、分割トンネリングの対象トラフィックをカバーするかどうかも、実装と設定によって異なります。

特定のアプリケーションを意図的にダイレクト接続させている場合、元の出口を使うことは必ずしも障害ではありません。しかし、「すべての外向きトラフィックを指定の出口に通す」ことを想定している場合は、同じ現象でもさらに調査が必要です。

まずベースラインを残すことをお勧めします。対象の設定を有効化する前のパブリック IPv4、IPv6、および DNS 検出で確認できるリゾルバです。ベースラインは前後比較に使用し、公開する必要はありません。特に企業ネットワークでは、内部アドレスや設定のスクリーンショットを安易に公開すべきではありません。

WebRTC：まず候補アドレスを区別し、その後出口の露出を判断しましょう

WebRTC は、ブラウザがリアルタイムの音声・ビデオ・データ通信を行うためのものです。接続を確立するために、利用可能なネットワーク経路、つまり ICE 候補を収集します。

MDN の候補タイプの説明では、host、srflx、prflx、relay などのタイプが区別されています。一般ユーザーにとって最も重要なのは、ローカルインターフェース情報、アドレス変換を通じて観測された情報、および中継サーバーのアドレスを区別することです。候補がウェブページに公開されるかどうかは、ブラウザの WebRTC プライバシーポリシーにも影響されます。

WebRTC が元のネットワークアドレスを露出させることは想像上の話ではありません。RFC 8828では、スプリット VPN、複数ネットワークインターフェース、アプリケーションプロキシなどの状況での IP 情報露出問題が議論されています。ただし、ブラウザの実装、権限、ネットワークポリシーが実際の動作に影響するため、古いブラウザでのテスト結果をすべてのデバイスにそのまま当てはめることはできません。

WebRTC漏えいテストにおいて、想定外のパブリックアドレスが表示された場合は、まずベースラインと比較し、それがどのネットワークに属するかを確認してください。「2つ目のアドレスが表示された」というだけで結論を出したり、「候補が収集されなかった」ことを絶対的な安全と同一視したりしないでください。通信がブロックされたりテストが完了しなかった場合も、空の結果になることがあります。

DNS：通信事業者のリゾルバが表示される場合、何を意味するのか？

ブラウザがドメインにアクセスする前には、通常そのドメインに対応するアドレスを取得する必要があります。DNSリークは、この手順が想定どおりの解決ポリシーに従って実行されたか、またクエリ情報に触れるべきでない当事者が触れる可能性があったかに注目します。

一般的なDNSリークテストでは、ブラウザが一連のテスト用ドメインを要求し、権威DNS側からクエリの送信元を観察します。ページに表示されるのは通常、再帰解決チェーンにおける出口であり、デバイスのDNS設定を直接読み取ったものではありません。

つまり、DNSアドレスが1つ検出されたとしても、即座に「ローカルのDNSサーバーがそれである」と断定することはできません。再帰転送、パブリックリゾルバサービス、Anycast展開によって、結果はシステム設定画面よりも複雑になる可能性があります。

特に国名だけを見ないでください。DNS出口のデータベース上の位置はWeb出口とは異なり、それだけではリークを証明するのに十分ではありません。リゾルバの運営者、サービスのルーティング方法、および設定目標に合致しているかをさらに確認する必要があります。

VPNが指定する解決経路のみを使用することを想定しているのに、テストで元のネットワーク事業者の解決出口が継続的に観察される場合は、調査が必要なシグナルです。特定のパブリックDNSを自ら設定した場合、それが検出されること自体は必ずしも異常ではありません。

DNS漏えいテストを使用して前後を比較できます。複数のリゾルバが現れた場合は、ブラウザの「セキュアDNS」、オペレーティングシステムのDNS、VPNのDNS、および分割設定の間に上書きや併用関係がないかを優先的に確認してください。

DoHを有効にすればリークしないのか？

DoHはDNSクエリの転送暗号化の問題を解決するものであり、すべてのルーティングと信頼の問題を自動的に解決するわけではありません。Cloudflareの説明では、DNSクエリをHTTPSでカプセル化する方法が紹介されていますが、「転送が暗号化されている」ことは「クエリが必ず指定したVPNを経由する」ことと同義ではありません。

解決サービスは依然としてクエリを処理します。一部の展開ではEDNS Client Subnetを使用し、再帰クエリでクライアントのネットワークプレフィックス情報を渡す場合があります。このメカニズムとプライバシーへの影響はRFC 7871に記載されています。通常のDNSテストでこの項目の結果が明示されていない場合、ECSを確認済みと想定しないでください。

IPv6：IPv4の出口が正しくても、もう一方のアドレス体系も正しいとは限らない

多くのネットワークではIPv4とIPv6の両方が提供されています。プロキシやVPNがIPv4のみを処理し、デバイスが元のネットワーク経由でIPv6を直接使用できる場合、IPv6対応のターゲットサービスは別の出口経路を観測する可能性があります。

ただし、「IPv4とIPv6のアドレスが異なる」こと自体は正常な現象です。それらは異なるアドレス体系に属しており、保護が機能しているかどうかをアドレスの文字列の類似性で判断することはできません。

比較すべきは、両プロトコルのネットワーク帰属、実際のルーティングが想定どおりか、そしてIPv6が依然として元のネットワークを指しているかどうかです。IPv6一時アドレス自体の変化も、自動的にリークが発生したことを示すものではありません。

ブラウザー環境チェックで、利用可能なIPv4とIPv6の情報をそれぞれ確認してください。IPv6テストが完了していない場合は「未確認」としかマークできません。これは「IPv6が使用不可であることを確認した」という結論とは異なります。

再現可能な調査手順

1. 同じデバイス、同じブラウザで前後比較を行う

対象の設定を有効にする前の出口情報を記録し、設定を有効にしてから再検出してください。テスト中にWi-Fi、ブラウザのプロキシ、DNSを同時に変更しないでください。変更すると、どのステップが変化の原因かを判断することが困難になります。

2. Web、WebRTC、DNS、IPv6を個別に確認する

4つの結果を分けて記録してください。Webで観測されたパブリック出口、WebRTC候補、DNSクエリの送信元、IPv6の到達性と出口です。いずれか1つの項目の緑色のステータスをもって、他の項目の代わりとしないでください。

3. 異常経路に基づいて設定を特定する

WebRTCが元のネットワークのパブリックアドレスを公開している場合は、プロキシのカバレッジ、WebRTCポリシー、VPNが分割トンネリングを採用しているかどうかを確認してください。DNSが想定と異なる場合は、ブラウザとシステムの解決設定、およびVPN切断後のDNS復旧動作を確認してください。IPv6が依然として元のネットワークを経由する場合は、VPNのIPv6サポートと関連ルーティングを確認してください。

関連するオプションを一度に1つだけ変更し、再テストしてください。長期的な業務上の問題に対処する必要がある場合は、時刻、設定状態、結果の要約を保存しておくことが、単に「赤い警告」のスクリーンショットを1枚残すよりも通常は問題の切り分けに役立ちます。

4. 再接続後の挙動を確認する

ネットワークの再接続、デバイスのスリープからの復帰、VPNの再接続は、いずれも経路を変更する可能性があります。条件が許せば、これらの通常の使用シナリオの後にもう一度確認してください。1回のテストで合格しても、それはその時点で観測された挙動が想定どおりだったことを示すのみであり、その後の安定性の検証の代わりにはなりません。

最初からすべての機能を無効にすることは推奨されない

WebRTCを直接無効にすると、ブラウザでの通話や会議に影響する可能性があります。IPv6を直接オフにすると、設定上の問題を覆い隠す可能性もあります。これらを行うかどうかは、検出ページの表示行数を減らすためだけではなく、実際のニーズと許容できる機能損失に基づいて判断すべきです。

より確実な方法は、まず保護範囲を明確にし、それから対応するルーティング、解決、またはブラウザ設定を修正することです。企業のデバイスでは管理者のポリシーに従うべきであり、定められたネットワークおよびセキュリティ設定を自己判断で迂回してはいけません。

シークレットウィンドウでこれらのリークを防げるのか？

シークレットモードをネットワークトンネルとして扱うことはできません。シークレットモードは主に閲覧履歴やCookieなどのローカルセッションデータの処理方法を変更するものであり、DNS、WebRTC、IPv6ルーティングを自動的に引き継ぐものではありません。

元のIPアドレスが検出できない場合、完全に匿名であると言えるのでしょうか？

いいえ。IP経路はプライバシーの一部に過ぎません。アカウントログイン、Cookie、ブラウザフィンガープリント、そして自発的に送信した情報によって、サービスが訪問を識別または関連付ける可能性があります。

この一連のチェックを完了した後、合理的な結論は次のとおりです：「現在の設定とテスト条件下で、観測されたネットワーク経路は期待どおりです。」 これは、適用範囲のない「ゼロリーク、完全匿名」という表現よりも正確であり、今後の利用にも役立ちます。

トラフィック分割シナリオ：同じデバイスで4つの異なる結果が出た場合の解釈

ドメインごとのトラフィック分割を設定している場合や、VPNとローカル直接接続を同時に有効にしている場合を想定します。ある検出で、HTTP出口がプロキシノードAのアドレスを示し、DNS検出が再帰サーバーBのアドレスを示し、WebRTC候補に元のネットワークのパブリックIP CとTURNアドレスDが現れ、IPv6は依然としてキャリア回線を使用しているとします。このような結果は「4項目すべてリーク」と誤解されがちですが、実際にはそれぞれの経路が異なるだけかもしれません。重要なのはIPの数ではなく、これらの経路が期待と一致しているかどうかです。

この例では、WebページのHTTPトラフィックのみをプロキシ経由にしたい場合、出口Aは設定と一致する可能性があります。DNSが直接接続かどうかは別途確認する必要があります。Webページが読み取れるWebRTC候補に元のネットワークのパブリックIP Cが現れた場合、そのページが今回のテストでCを知ることができたことを示しており、実際にメディア接続がそれを使用するまで待つ必要はありません。これが要件に合わないリークかどうかは、そのページに対してこのアドレスを隠したいかどうかによります。

mDNS候補は特に区別する必要があります。ブラウザは通常、ランダムに生成された.local名を使用してローカルネットワークインターフェースを表し、実際のLAN情報の直接公開を避けます。WebRTC検出ページで「2f8c…local」のようなエントリを見た場合、それはローカル候補のプライバシー処理として理解すべきであり、パブリックIPやホスト名ではありません。これをリークの証拠とするのはよくある誤解です。同時に元のネットワークのパブリックアドレスが存在し、そのアプリケーションが本来トンネルで保護されるべきである場合のみ、重点的に確認すべき露出シグナルとなります。

IPv6も別途記録する必要があります。IPv4の出口はプロキシAを経由しているが、IPv6は依然としてキャリアの直接リンクを使用している場合、デュアルスタック対応のターゲットサイトは、同時または優先的にIPv6経由でキャリアのアドレスを観測する可能性があります。これは必ずしもプロキシ設定の誤りによるものではなく、CIDRベースのトラフィック分割やIPv4のみをプロキシするクライアントの多くは、デフォルトでIPv6ルーティングを引き継ぎません。この場合、すぐに「IPv6リーク」と結論付けるのではなく、まずVPNまたはプロキシがIPv6をカバーすると主張しているかどうかを確認し、次にローカルにIPv6デフォルトルートがトンネルを指しているかどうかを確認します。

DNS再帰サーバーの違いは、ASNとRDAP情報を用いて補助的に判断できます。Bのアドレスがあなたが積極的に指定したパブリック解決サービスのものであれば、HTTP出口と異なっていても正常です。元のネットワークキャリアのものであり、本来は解決トラフィックをトンネルに入れたい場合は、調査すべき異常です。Anycast展開の解決サービスは地域によって異なるノードを表示する可能性があるため、地理位置情報の変化だけでDNSが直接接続になったと判断してはいけません。運営者名、ASNの帰属、およびテストドメインが権威側で期待外のクエリソースを観測していないかに注目すべきです。

このような複数の出口が共存する状況に遭遇したら、最初に機能を無効にするのではなく、「期待」を書き出すことです。どのアプリケーションをプロキシ経由にし、どれを直接接続にするか、DNSは誰が処理するか、IPv6はトンネルでカバーするか直接接続を許可するか、WebRTCはVPN接続時にローカル候補の収集を許可するか。一度測定した後、ベースラインと比較します。ある項目が期待と異なる場合は、具体的な設定に戻って項目ごとに調整します。一度に1つの変数だけを変更し、例えば最初にDNSを変更して再テストすることで、どのルールが差異を引き起こしたかを特定できます。

反復測定と切断回復：検出結果を再検証に耐えられるものにする

一度の検出が合格したとしても、それはその時点の環境が期待どおりだったことを示すだけです。VPNの再接続、システムのスリープ解除、ブラウザの権限変更により、経路が変わる可能性があります。通常の使用シナリオ後に反復測定することをお勧めします。VPNを切断して再接続、スリープから復帰、Wi-Fiとモバイルネットワークを切り替えた後、それぞれHTTP出口、DNSソース、WebRTC候補、IPv6状態を確認します。これら4つの結果の安定性は、1回の全項目合格よりも参考になります。

各測定では1つの変数のみを変更します。例えば今日はWebRTC関連の設定のみを変更し、DNSとVPNの設定はそのままにします。明日はIPv6のみを変更し、4項目すべてを再テストします。ブラウザの「セキュアDNS」、プロキシのトラフィック分割、システムのIPv6スイッチを同時に調整すると、調子が良かったり悪かったりして、どの変更が原因かを追跡するのが難しくなります。時間、設定状態、結果の要約を記録することは、赤い警告のスクリーンショットよりも長期的なメンテナンスに役立ちます。

ブラウザの権限はWebRTC候補に直接影響します。サイトがマイクやカメラの権限を持っていない場合、ブラウザはローカルインターフェース候補を収集しない可能性があります。音声・ビデオを許可すると、候補収集の範囲が拡大する可能性があります。したがって、権限付与前後でWebRTCを個別にテストし、候補リストの変化を観察する必要があります。権限が付与されていないときにページに候補がないからといって、WebRTC露出経路が存在しないと考えるのは、「未測定」を「保護済み」と見なす誤りです。同様に、シークレットウィンドウはネットワークルーティングを変更しないため、リーク防止策として使用できません。

IPv6は要件に応じて明確に処理する必要があります。完全なデュアルスタック保護が必要な場合は、IPv6をサポートするトンネルを選択して設定し、実際のルーティングとファイアウォールを確認します。製品がIPv4のみをサポートする場合は、IPv6に対してどのようなブロックまたはバイパスポリシーがあるかを確認します。デフォルトルートを1つ追加するだけでは、すべてのアプリケーションと切断状態が保護されるとは限りません。グローバルにIPv6を無効にすると互換性に影響する可能性があるため、まずクライアントの能力を理解し、復元可能な設定を保持した上で、正常時、再接続時、切断時を個別に検証する必要があります。

切断回復の検証には「キルスイッチ」ポリシーを含めるべきです。あるVPNが切断時にすべての発信トラフィックをブロックすると主張している場合、ネットワーク切断時にDNSクエリも同時に失敗するかどうかをテストし、元のネットワークのリゾルバにフォールバックしないことを確認します。一部の実装はIPv4 TCPのみを切断し、IPv6やDNSは元の回線を使用し続けることを許可するため、この「部分的な保護」は観測ウィンドウを残します。切断イベントを個別にトリガーし、HTTP、DNS、IPv6リクエストの動作を観察することで確認できます。

検出結果の「ミス」は「安全」を意味しません。IPv6がネットワークの非対応により接続できないと表示される場合、それは「未確認」とマークすべきであり、「IPv6リークがないと確認済み」と解釈してはなりません。経路は、テストが送信され、結果が期待と一致した場合にのみ、今回の検証に合格したと言えます。各測定では、ブラウザのバージョン、プロキシモード、VPNプロトコル、ネットワーク環境などのテスト条件を記載し、後で再現できるようにする必要があります。

より複雑な環境では、CGNAT が公共出口と内部アドレスの対応関係を変えることがあります。その場合は グローバルIPアドレスの確認方法とCGNATの見分け方 を参照して NAT 階層を把握してください。また、一部のセキュリティ検出ツールは正常な現象を VPN やプロキシの特徴として誤検知することがあるため、VPNを使っていないのにプロキシ判定される原因と確認方法 を参考にツールの出力をさらに判断するとよいでしょう。これらの資料を組み合わせることで、アドレスタイプや検出ロジックによる誤判定を減らせます。

最終的には、調査結果を検収記録としてまとめます。想定経路が明確か、各トラフィックが通常時・再接続時・切断時の3つの状態で期待どおりか、異常項目が具体的な設定まで特定されているか、を確認します。そうして得られる結論——「現在の条件とテスト範囲内で、観測されたネットワーク経路は想定どおりです」——は、一度きりの緑のチェックマークよりもはるかに価値があります。