WebRTC リーク

WebRTC リークは、VPN、プロキシ、またはプライバシー設定によって隠蔽されると予想されていたネットワーク アドレス情報がブラウザによって公開されたときに発生します。 最もわかりやすい例は、使用する予定だった VPN またはプロキシ IP の代わりに、ISP のパブリック IP が表示されることです。

WebRTC 自体は有害な機能ではありません。 ビデオ通話、音声チャット、画面共有、ブラウザーでのリアルタイム データをサポートします。 プライバシーの問題は、動作するネットワーク パスを探す方法に起因します。

簡単に言えば、WebRTC リークとは、ブラウザがリアルタイム接続の準備中に予期しないアドレスを明らかにすることを意味します。

WebRTC リークとは何ですか?

リークという言葉には文脈が必要です。 Web サイトでは通常、ページの読み込みに使用されるパブリック IP が表示されます。 WebRTC テストでも同じアドレスが表示される場合があります。 両方の結果が選択した VPN またはプロキシを指している場合は、リークがまったくない可能性があります。

問題は、WebRTC が予想されるルートの外側のアドレスを明らかにしたときに始まります。 通常の IP チェックで VPN IP が表示され、WebRTC の結果でホーム ISP IP が見つかる場合があります。 最初のテストで見逃された、公開された IPv6 アドレスが見つかる場合もあります。

私はリークチェッカーのすべてのラインを失敗とは扱いません。 現在の設定で隠蔽されるはずだったアドレスを探します。

IP暴露が漏洩となる場合

通常の ISP アドレスがロンドンにあるとします。 ニューヨークのプロキシに接続します。 標準の IP チェッカーにニューヨークのプロキシが表示されるようになりました。 その部分は期待どおりに機能します。

次に、WebRTC テストを実行します。 ニューヨークの住所も表示されている場合、ネットワーク信号は一致しています。 元のロンドンの ISP アドレスも表示されている場合は、ブラウザーが予期しないパスを公開していることになります。

同じロジックが VPN にも当てはまります。 IPv6にも適用されます。 別の IPv6 アドレスが依然として元のネットワークを指している場合、保護された IPv4 ルートはあまり役に立ちません。

WebRTC にネットワーク アドレスが必要な理由

リアルタイム通信には 2 つのエンドポイント間のパスが必要です。 その道は直接的なものかもしれません。 NAT デバイスを通過する可能性があります。 直接接続できない場合は中継器が必要になる場合があります。

WebRTC は可能なルートを収集するので、機能するルートを選択できます。 これにより、通話の開始が速くなり、遅延が抑えられます。 これは、Web アプリケーションが通常のページ リクエストよりもネットワークについてさらに多くのことを学習できることも意味します。

このプロセスは、カメラやマイクへのアクセスとは別のものです。 ページではピア接続またはデータ チャネルを作成し、接続候補の収集を開始できます。 メディア デバイスにアクセスするには、関連するブラウザ許可が必要です。

WebRTC リークはどのようにして起こるのでしょうか?

プロセスは RTCPeerConnection で始まります。 Web アプリケーションは、リアルタイム接続が必要なときにこのオブジェクトを作成します。 次にブラウザは、通常 ICE と呼ばれる対話型接続確立を使用して、可能な接続候補を収集します。

これらの候補者は、接続がどのように機能するかを説明します。 Web アプリケーションは候補情報を読み取り、シグナリング システムを通じてリモート側と共有できます。

VPN またはプロキシの背後にあるはずの ISP アドレスがブラウザーに含まれている場合、アプリケーションはそれを認識する可能性があります。 これは、スプリット トンネリング、追加のネットワーク インターフェイス、保護されていない IPv6 ルート、または WebRTC が予想されるパスの外に接続できるブラウザ プロキシによって発生する可能性があります。

ICE候補者集結

フローには 5 つのステップがあります。

1. ページは RTCPeerConnection を作成します。
2. ICE エージェントは、利用可能な接続パスを確認します。
3. ブラウザは、ホスト、STUN 由来、または TURN リレーの候補を収集します。
4. アプリケーションは、表示が許可されている候補者を受け取ります。
5. ICE は候補ペアをテストし、動作するパスを選択します。

ICEはサーバーではありません。 これは、接続オプションを見つけてテストするために使用されるプロセスです。 STUN と TURN は、さまざまな方法でそのプロセスをサポートします。

ホスト、STUN、TURN の候補者

各候補タイプにより、接続の異なる部分が明らかになります。

TURN リレーは、直接エンドポイント アドレスをリモート ピアから遠ざけることができます。 また、別のサーバーもパスに追加されます。 これにより、遅延、帯域幅コスト、リレーへの運用依存度が増加する可能性があります。

VPN またはプロキシが予期しないパスを公開する場合

VPN とプロキシを同じツールとして扱うべきではありません。 フルトンネル VPN は、広範なデバイス トラフィックをルーティングし、ファイアウォール ルールを使用してトンネル外部のトラフィックを停止できます。 スプリットトンネル VPN では、選択したトラフィックが別のルートを使用できるようになります。

ブラウザ プロキシは、多くの場合、1 つのブラウザまたはプロファイルの Web リクエストを処理します。 すべての WebRTC パスを制御できるわけではありません。 SOCKS5 は UDP をサポートできますが、実際の WebRTC ルーティングは依然としてブラウザーとその構成に依存します。

プロキシ、VPN、およびブラウザの検出防止 はさまざまなレイヤーを制御します。 プロキシは、選択されたトラフィックをルーティングします。 VPN は、より広範囲の暗号化トンネルを管理できます。 アンチディテクトブラウザは、ブラウザのプロファイルとブラウザ側のシグナルを管理します。 一方が自動的に他方を置き換えるわけではありません。

WebRTC はどのような情報を公開できるのでしょうか?

ほとんどのテスト ページには複数のフィールドが表示されます。 特にローカル アドレスとパブリック アドレスが一緒に表示される場合、ラベルは憂慮すべきものに見えることがあります。 それぞれのタイプを独自に判断するのに役立ちます。

パブリックIPアドレス

パブリック IP はインターネット上で認識されます。 これは、ISP、ASN、広範囲の場所、および使用されているネットワークの種類を示すことができます。

VPN またはプロキシがアクティブな場合、最も重要な警告は、ベースライン ISP パブリック IP の出現です。 これは、IPv4 アドレス、IPv6 アドレス、またはその両方です。

IPアドレス は、通常、それ自体では正確なホーム アドレスを明らかにしません。 まだまだ役立つネットワーク情報です。 また、予想される出口 IP によって示される場所およびプロバイダーと競合する可能性もあります。

ローカルIPアドレスとmDNS名

ローカル アドレスは、多くの場合、192.168 や 10 などの範囲で始まります。 これらのアドレスは、多くのプライベート ネットワーク全体で再利用されます。 1 つのローカル IP は、通常、パブリック ISP アドレスほど明らかにされません。

だからといって地域情報が無意味になるわけではありません。 ネットワークレイアウトの一部が明らかになる可能性があります。 ローカル インターフェイスの安定した組み合わせにより、セッションが比較されるときに別の信号が追加される場合もあります。

最近のブラウザでは、ランダムな .local mDNS 名の背後にローカル ホスト アドレスが隠蔽されることがよくあります。 その名前が表示されても、ISP のパブリック IP が漏洩したことを意味するものではありません。 これは、ブラウザがローカル アドレスの直接公開を回避していることを意味します。 また、考えられる WebRTC 信号をすべて削除するわけではありません。

IPv6 と複数のネットワーク インターフェイス

多くの人は IPv4 をチェックしてそこで終わります。 それはわかりやすいですね。 IPv4 は、依然としてほとんどのユーザーが認識しているアドレスです。

IPv6 には独自のチェックが必要です。 VPN は IPv4 を正しく処理することができますが、別の構成では IPv6 が表示されたままになります。 Wi-Fi、イーサネット、仮想アダプター、および VPN インターフェイスでも、いくつかの候補を作成できます。

結果はブラウザ、オペレーティング システム、ネットワーク、プライバシー ポリシーによって異なります。 使用しているセットアップのライブ テストでは、一般的なブラウザのリスト以上のことがわかります。

WebRTC リークをテストする方法

クリーンなテストはベースラインから始まります。 これがないと、複数のアドレスが表示され、どれが元の接続に属しているかを知る信頼できる方法がなくなる可能性があります。

段階的な WebRTC リーク テスト

1. VPN またはプロキシを切断します。
2. 現在のパブリック IPv4 アドレスと IPv6 アドレスを記録します。
3. テストページを閉じます。
4. VPN またはプロキシに接続するか、確認したいブラウザー プロファイルを起動します。
5. 通常の IP チェッカーを使用して、予想される終了 IP を確認します。
6. WebRTC 固有のチェッカーを開きます。
7. パブリック、ローカル、mDNS、IPv6、およびリレーの結果をベースラインと比較します。
8. 関連する設定を変更し、元の ISP アドレスが表示されるかどうかを再度テストします。

ブラウザのコントロールは時間の経過とともに変化します。 安全と思われる設定の古いリストよりも、慎重な WebRTC リーク テスト が重要です。

テスト結果の見方

MoreLogin の BrowserLeaks テストでは、同じプロファイル内の IP、WebRTC、タイムゾーン、言語、Canvas、WebGL、フォントを確認しました。

それは 1 つの構成に対する 1 つのテストでした。 すべてのブラウザーのバージョン、デバイス、プロキシ、またはプロファイルに対する約束として読み取るべきではありません。

1 つのグリーン結果が永続的な保証ではない理由

緑色の結果は安心感を与えます。 私はまだ、それを期限切れのない証明書として扱うつもりはありません。

ブラウザまたはネットワークに影響を与える可能性のある変更を行った後、再度テストしてください。

• ブラウザのアップデート
• 新しい VPN サーバーまたはプロキシ
• 拡張子の変更
• 新しいネットワーク
• IPv6が有効になっている
• 新しいブラウザプロファイル
• 別の WebRTC ポリシー

リーク テストは、1 つのブラウザ、ネットワーク、構成のスナップショットです。 有益な決定を下すにはそれだけで十分です。 プライバシーを永久に保証するものではありません。

WebRTC リークを防止または修正する方法

すべてのブラウザーとすべてのワークフローに適合する単一の修正方法はありません。 正しい選択は、WebRTC 機能を利用可能な状態にしておく必要があるかどうかによって決まります。

テスト済みの漏洩保護機能を備えた VPN を使用する

システムレベルの VPN は、ルーティングとファイアウォール ルールを通じて WebRTC トラフィックを保護できます。 スプリット トンネリングがアクティブかどうかを確認します。 IPv6も確認してください。 次に、アプリの接続ステータスを信頼する代わりにテストを実行します。

VPN ブランドは、実際に使用するデバイスやブラウザで観察された結果ほど重要ではありません。

プロキシ以外のトラフィックを制限するか、リレーのみの WebRTC を使用する

もう 1 つのオプションは、WebRTC がプロキシの外部のパスを使用するのを停止することです。 一部のコントロールは非プロキシ UDP をブロックします。 他のものは、構成されたプロキシをトラフィックに強制的に通過させます。

UDP がそのルートを使用できない場合、WebRTC は TCP または TURN にフォールバックする可能性があります。 失敗することもあります。 結果は実装によって異なります。

リレー専用 WebRTC は TURN 候補を使用します。 リアルタイム通信を維持しながら、直接の候補者をリモート ピアから遠ざけることができます。 トレードオフとして、遅延が増加し、中継トラフィックが増加し、TURN の可用性への依存が強くなります。

ブラウザの設定を変更するか拡張機能を使用する

Firefox には、WebRTC を制限または無効にすることができる高度な設定が用意されています。 Chromium ベースのブラウザは、拡張機能、エンタープライズ ポリシー、またはブラウザ レベルのネットワーク制御に依存することがよくあります。

拡張機能が役に立ちます。 彼らにもケアが必要です。 ブラウザを更新すると、古い拡張機能が機能しなくなる可能性があります。 広範な許可を要求する場合があります。 また、ブラウザのバージョンによって動作が異なる場合もあります。

使用する場合は、保守されているソースを選択し、結果を再度テストしてください。 ツールバーのアイコンは証拠ではありません。 ネットワークの結果は次のとおりです。

プロファイルごとの WebRTC コントロールを使用する

複数のプロファイルが異なるプロキシまたはネットワークの場所を使用している場合、グローバル設定は扱いにくくなります。 各プロファイルには、明確なプロキシ割り当てと、タスクに適した WebRTC ポリシーが必要です。

プロキシが接続しているだけでは、プロファイルの準備ができているわけではありません。 MoreLogin でプロキシを設定します したら、表示される IP を確認し、別の WebRTC チェックを実行します。

MoreLogin ブラウザ プロファイル API ドキュメント には、プロファイルごとの WebRTC オプションとしてプライバシー、置換、本物、無効、転送がリストされています。 すべてのモードがホスト、STUN、TURN、UDP、IPv4、および IPv6 の候補をどのように処理するかについては完全には説明されていません。

モード ラベルだけでは十分ではありません。 現在の製品バージョンで選択した動作を確認します。

WebRTC を無効にする必要がありますか?

WebRTC を無効にすると、このアドレス漏洩パスが閉じられる可能性があります。 これは、通常のブラウザ機能に影響を与える可能性が最も高いオプションでもあります。

WebRTC を無効にすることで妨げられること

RTCPeerConnection が利用できない場合、ページはその API を使用して同じ接続候補を収集できません。 これにより、WebRTC ベースの IP 漏洩を防ぐことができます。

DNS リークを阻止することはできません。 ブラウザの指紋は隠されません。 Cookie やアカウント データは削除されません。

動作を停止する可能性のあるもの

サイトでは、WebRTC に依存する次のような機能が失われる可能性があります。

• ブラウザビデオ通話
• ボイスチャット
• 画面共有
• ピアツーピアファイル転送
• リアルタイム サポートおよびコラボレーション ウィジェット

サービスによっては別のルートを提供する場合があります。 他のものは失敗したり、品質が低下したりする可能性があります。

無効化、制限、中継

プロファイルでリアルタイム通信が必要ない場合は、WebRTC を無効にします。 機能を利用可能な状態に維持する必要があり、ネットワーク パスを確認できる場合は、制限または中継します。

WebRTC リーク vs. DNS リーク

WebRTC と DNS のリークは、どちらもプライバシーの設定を弱める可能性があるため、混同されやすいです。 彼らはさまざまな情報を公開します。

両方が同時に起こる可能性があります。 一方を修復しても、もう一方がなくなったことは証明されません。

WebRTC リークと分離されたブラウザ プロファイル

ネットワーク ID とブラウザ ID は異なる層にあります。 この区別は、プロファイルが長期間にわたって再利用される場合に重要になります。

プロキシまたは VPN はネットワーク ルートを制御します。 WebRTC ポリシーは、接続候補を公開または中継する方法を制御します。 ブラウザ プロファイルには、Cookie、ローカル ストレージ、ブラウザ設定、その他の信号が保持されます。

WebRTC 情報は、ブラウザのバージョン、タイムゾーン、フォント、Canvas 出力、WebGL の動作と並んで、より広範な ブラウザ フィンガープリント の一部となる可能性があります。

各プロファイルのネットワーク信号の一貫性を保つ

プロファイルを使用する前に、一致する必要がある部分を確認してください。

• 予想されるプロキシまたは VPN パブリック IP
• WebRTC パブリック IP
• IPv6 の露出
• ローカル IP または mDNS の動作
• タイムゾーンと地理的位置
• ブラウザ言語

一貫性によってプロファイルが非表示になるわけではありません。 これにより、回避可能な不一致が減少し、問題の診断が容易になります。

重要な作業の前にプロファイルを確認する

通常の IP チェックが正しいと思われる場合は、停止したくなります。 数日後に漏れを見つけるとイライラするし、解くのが難しくなります。

MoreLogin では、マルチアカウント ブラウザ プロファイル により、プロキシ設定、WebRTC 構成、Cookie、ストレージ、その他のブラウザ信号が 1 つの再利用可能な環境に保持されます。 これにより、設定の確認が容易になります。 結果は、選択した設定、ネットワーク、プロキシによって異なります。

新しいプロファイルを使用する前にテストしてください。 プロキシ、ブラウザのバージョン、または WebRTC ポリシーが変更された場合は、再度テストしてください。

重要なポイント

• WebRTC リークは、予期しないネットワーク アドレスの漏洩であり、テストでの IP の出現ではありません。
• ICE は、ホスト、STUN 由来、および TURN リレー候補を収集する場合があります。
• 有用なテストでは、ベースライン ISP IP を VPN、プロキシ、またはプロファイルの結果と比較します。
• WebRTC の無効化、制限、プロキシ、およびリレー専用には、プライバシーと互換性に関するさまざまなトレードオフがあります。

WebRTC リークに関するよくある質問

WebRTC は常に実際の IPアドレス を漏洩しますか?

いいえ。 結果は、ブラウザ、ネットワーク、VPN またはプロキシ ルート、IPv6 構成、および WebRTC ポリシーによって異なります。 正しくルーティングされた設定では、VPN またはプロキシ IP のみが表示される場合があります。 リレーのみのセットアップでは、TURN アドレスが表示される場合があります。

WebRTC は VPN またはプロキシをバイパスできますか?

ブラウザが別のネットワーク パスの使用を許可されている場合、追加のアドレスが公開される可能性があります。 スプリット トンネリング、保護されていない IPv6 ルート、または WebRTC トラフィックを制御しないブラウザ プロキシが、この結果に寄与する可能性があります。

ローカルの IPアドレスは WebRTC リークですか?

それはローカルネットワークの情報漏洩です。 通常、これは ISP のパブリック IP を明らかにするほど直接的ではありません。 その情報としての価値は、アドレス、その安定性、存在する他のインターフェイス、および情報の組み合わせ方法によって異なります。

WebRTC テストにおける .local アドレスは何を意味しますか?

ランダムな .local アドレスは通常、mDNS ホスト名です。 最近のブラウザは、ローカル ホスト IP が直接表示されることを避けるためにこれを使用します。 ISPのパブリックIPが漏洩したわけではありません。

Web サイトはカメラの許可なしで WebRTC をチェックできますか?

ページはピア接続またはデータ チャネルを作成し、ICE 候補の収集をトリガーできます。 カメラとマイクへのアクセスには、引き続き関連するメディアの許可が必要です。

WebRTC を無効にすると Web サイトが壊れますか?

ビデオ通話、音声チャット、画面共有、ファイル転送、その他のリアルタイム機能に影響を与える可能性があります。 一部のサイトではフォールバックが提供されている場合があります。 他のものは機能を失ったり、品質が低下したりする可能性があります。

WebRTC リークをテストする頻度はどれくらいですか?

ブラウザ、VPN、プロキシ、拡張機能、ネットワーク、IPv6 設定、ブラウザ プロファイル、または WebRTC ポリシーを変更した後にテストします。 簡単な再テストで、明確な警告なしに変更されたルートを見つけることができます。

WebRTC とプロキシ設定を整理しておく

WebRTC 保護は、プロファイル設定全体の一部として扱われる場合に最も効果的に機能します。 プロキシ、可視 IP、IPv6 ルート、タイムゾーン、言語、および WebRTC ポリシーは、すべて意味をなすものでなければなりません。

MoreLogin を無料でお試しください を使用して、再利用可能なブラウザ プロファイルを作成し、ネットワークとブラウザの設定を個別に構成し、使用前に各環境を確認します。