プロキシを使っていて、「接続済みなのに、チェックサイトに元のネットワーク情報が表示されるのはなぜ？」と疑問に思ったことはありませんか。そんなときは、次の2点を確認してみましょう。
• DNSリーク：ドメイン名の問い合わせは、どこに送信されているか？
• WebRTCリーク：ブラウザから、どのIPアドレスが見えているか？
この2つは個別にテストする必要があり、対処法も異なります。この記事では、ToDetect編集部が確認すべきポイントとチェック方法を解説します。
1. DNSリークとWebRTCリークの違いとは？
| 比較項目 | DNSリーク | WebRTCリーク |
|---|---|---|
| 関連する機能 | Webサイトのドメイン名をIPアドレスに変換する機能 | ブラウザでのリアルタイムの音声・映像・データ通信 |
| 主な問題 | ドメイン名の問い合わせが意図しないDNSサービスに送信される | 隠したいIPアドレスが外部に公開される |
| 確認するポイント | どのサービスがDNSクエリを処理しているか | 接続元ネットワークのグローバルIPアドレスが表示されるか |
| 主な確認箇所 | システムのDNS、ブラウザのセキュアDNS、プロキシやVPNの設定 | ブラウザのWebRTCポリシー、ネットワークのルーティング設定 |
DNSリーク：Web通信はプロキシ経由でも、名前解決は別経路の場合がある
Webサイトを開く前に、通常は端末がドメイン名に対応するIPアドレスを調べます。この処理を担うのがDNSです。
すべてのリクエストをプロキシ経由にしたつもりでも、ドメイン名の問い合わせが接続元のインターネットプロバイダーのDNSサーバーに送られていれば、DNSリークが起きている可能性があります。
ただし、それによってプロバイダーがHTTPSページの本文やパスワード、閲覧履歴のすべてを見られるようになるわけではありません。DNSクエリからわかる情報と、Webページの内容は別のものです。詳しくは、DNSLeakTestによるDNSリークの解説をご覧ください。
WebRTCリーク：別の接続経路のIPアドレスがブラウザから見えることがある
WebRTCは、ブラウザでの音声通話やビデオ通話、リアルタイムのデータ転送に使われる技術です。接続を確立する際に、STUNなどの仕組みを使って利用可能なグローバルIPアドレスを取得することがあります。
その通信が想定したプロキシを経由していないと、通常のWebアクセスではプロキシの出口IPが表示されていても、Webページ側が接続元ネットワークのグローバルIPアドレスを取得できる場合があります。詳しくは、MDNのWebRTCプロトコル解説をご覧ください。
2. DNSリークを確認する方法
DNSリークという言葉は知っていても、確認方法まではわからない方も多いでしょう。技術に詳しければさまざまな方法で検証できますが、専門知識がなくても問題ありません。オンラインの DNSリークチェックツール を使えば、手軽に確認できます。
DNSリークをテストできるサイトはいくつかあり、ToDetectもそのひとつです。
ToDetectは、ブラウザフィンガープリントを確認できるツールです。IPアドレスの信頼性チェック、IPリスク分析、DNSリークテスト、WebRTCリークチェックなどの機能を備え、ネットワークやブラウザの情報を確認できます。
• ToDetectの公式サイトを開き、DNSリークチェックツールを選びます。
• ツールのページを開くと、DNSリークテストが自動で実行されます。
3. WebRTCリークを確認する方法
ToDetectのWebRTCリークテストを開きます。通常のWeb接続で使われるIPアドレスと、WebRTC経由で検出されたローカルIPアドレス・グローバルIPアドレスを確認しましょう。
プロキシに接続する前に記録したグローバルIPアドレスと、テスト結果を比較します。
| テスト結果 | 結果の見方 |
|---|---|
| 接続前のグローバルIPアドレスが表示される | リークを示す明確な兆候です。原因を調べる必要があります |
| 想定したVPNやプロキシの出口IPのみが表示される | 今回のテストでは、接続元ネットワークのグローバルIPアドレスの露出は確認されていません |
192.168.x.xなどのローカルIPアドレスが表示される | ローカルネットワークの情報は見えていますが、グローバルIPアドレスの露出とは異なります |
.localで終わる名前が表示される | 通常はブラウザがローカルIPアドレスを隠す仕組みによるもので、これだけでリークとは判断できません |
| IPアドレスが検出されない | 保護機能が働いている場合もあれば、機能やテストがブロックされている場合もあります |
4. リークが見つかったときの対処法
DNSリーク：DNS設定とリクエストの経路を確認する
次の項目を順番に確認しましょう。
• VPNの設定：DNSリーク保護が有効になっているか、スプリットトンネリングのルールが意図した設定になっているかを確認します。
• プロキシの設定：アプリが端末側ではなく、プロキシ側でドメイン名を解決する機能に対応しているかを確認します。
• ブラウザのセキュアDNS：ブラウザ独自のDNSサービスが指定されていないかを確認します。
• 変更後に再テスト：接続し直して、想定したサービスがDNSクエリを処理しているかを確認します。
パブリックDNSに切り替えるだけで、リークが解消するとは限りません。また、DNSを暗号化しても、そのクエリが必ずプロキシを経由するわけではありません。
WebRTCリーク：ブラウザのポリシーとプロキシの対象範囲を確認する
まず、WebRTCの通信もプロキシを経由しているかを確認します。Web通信だけをプロキシ経由にする設定では、ブラウザのすべての通信をカバーできない場合があります。
ブラウザで通話をしない場合は、WebRTCの制限や無効化も選択肢になります。例えばFirefoxでは、about:configを開き、media.peerconnection.enabledをfalseに設定できます。ただし、WebRTCを使う通話などの機能に影響するため、必要になったらtrueに戻してください。
5. 固定住宅IPを使っていてもテストは必要？
必要です。固定住宅IPは、利用する出口IPの種類を示すものです。システムのDNSクエリ、ブラウザのWebRTC通信、ほかのアプリが、すべて同じ出口を使うことを保証するものではありません。
接続設定が完了したら、次の3点を確認しましょう。
• 出口IPの確認：Web通信が想定したプロキシを経由しているかを確認します。
• DNSの確認：ドメイン名の問い合わせが、意図した設定どおりに処理されているかを確認します。
• WebRTCの確認：隠したいグローバルIPアドレスが公開されていないかを確認します。
ブラウザを変えたときや、プロキシ設定を変更したとき、別のネットワークに切り替えたときも、再テストしておくとよいでしょう。
6. よくある質問
DNSリークがなければ、WebRTCも安全ですか？
そうとは限りません。DNSテストはドメイン名の問い合わせを処理するサービスを確認し、WebRTCテストはブラウザが公開するIPアドレスを確認します。チェックする対象が異なるため、両方のテストを行いましょう。
WebRTCテストでIPアドレスが表示されたら、必ず問題がありますか？
表示されたアドレスによります。想定したプロキシやVPNの出口IPであれば、通常は接続元ネットワークのグローバルIPアドレスが漏れていることにはなりません。
接続前に記録した元のグローバルIPアドレスが表示された場合は、原因を調べる必要があります。一方、192.168.x.xなどのローカルIPアドレスは別の種類の情報であり、グローバルIPアドレスの露出と混同しないようにしましょう。
シークレットモードでリークを防げますか？
シークレットモードだけでは防げません。主な役割は、利用終了後に端末へ残る閲覧履歴などのデータを減らすことです。DNSやWebRTCの通信を自動的にプロキシ経由にする機能ではありません。
7. まとめ
DNSリークは、ドメイン名の問い合わせが想定した経路を通っているかどうかに関わる問題です。一方、WebRTCリークは、隠したいIPアドレスがブラウザから見えてしまう問題です。確認方法がわからない場合は、ToDetectのオンラインテストを利用してみてください。
