セキュリティとプライバシー · Clash 技術ブログ

Clash から実際の IP が漏えいする可能性は？DNS、WebRTC、IPv6 の確認方法

テストページにローカルアドレスや異なる地域が表示されても、必ずしも漏えいとは限りません。まず出口 IP、DNS、WebRTC、IPv6 を個別に記録し、Clash を実際に迂回している項目だけを修正してください。

本文を読むブログへ戻る
  • DNS リーク
  • WebRTC
  • IPv6
  • プライバシー
目次
公開日
更新日時
読了時間の目安
約 9 分

まず「リークしているか」に答えるには、一つの緑色の表示ではなく、グローバル IP の出口を確認する

Clash を使用しても、すべてのアプリケーション、DNS、WebRTC、IPv6 が自動的に同じ出口を通るとは限りません。リークの有無を判断するには、プロキシを有効にする前後で、グローバル IPv4、IPv6、DNS サーバー、WebRTC 候補を個別に記録する必要があります。

192.168.x.x のようなプライベートアドレスが表示されても、実際のグローバル IP が公開されたとは限りません。対処が必要なのは、プロキシを有効にしてもローカル ISP のグローバルアドレスが表示される場合です。

同じものとして扱わないでください

検査項目確認できること異常と判断する状態
グローバル IPv4Web サイトから見える出口プロキシを有効にしても、明らかにローカル ISP の出口が表示される
グローバル IPv6IPv6 が同じ方法で処理されているかIPv4 はノードを通るが、IPv6 はローカルから直接送信される
DNS サーバーどのサービスが問い合わせを処理している可能性があるか設定と一致せず、ドメインが想定したルールを迂回する
WebRTC の候補アドレスブラウザがリアルタイム通信のために検出したアドレス想定外の実際のグローバル出口が表示される。192.168/10.x は、それ自体ではグローバル IP のリークではない

直接接続、システムプロキシ、TUN を一度ずつテストする

検査ページだけで結論を出すことはできず、変更前後の二つの結果を比較して初めて意味があります。同じブラウザ、同じネットワーク、同じ検査ページを使い、Clash のトラフィック処理方法だけを変更して、四項目の結果を並べて保存してください。

比較可能なテスト

  1. プロキシを完全に終了し、直接接続の状態を記録する

    IPv4、IPv6、DNS、WebRTC の四項目を保存し、緑色の結果一つだけをスクリーンショットにしないでください。

  2. システムプロキシを有効にする

    新しいプライベートウィンドウでもう一度検査し、ブラウザリクエストの出口が変わったことを確認します。

  3. 必要な場合は TUN を有効にする

    同じネットワークとノードで引き続きテストし、IPv6 と、システムプロキシを読み込まないアプリケーションを確認します。

  4. 毎回、接続ページを確認する

    検査対象のドメインが表示され、ルールと出口が一致して初めて、その結果を現在の Clash 設定と関連付けられます。

Chrome の DNS 結果だけが異なる場合は、セキュア DNS を確認する

Chrome では「設定 → プライバシーとセキュリティ → セキュリティ」からセキュア DNS を個別に有効にできます。Firefox の DNS over HTTPS はプライバシー設定にあります。ブラウザで個別の DoH を有効にすると、問い合わせがシステム DNS を経由しなくなる場合があり、Clash のシステムプロキシではその名前解決リクエストまで処理できるとは限りません。

ブラウザの DoH を短時間だけ無効にし、ブラウザを完全に終了して開き直します。DNS の結果が Clash で想定した入口へ戻れば、原因を特定できています。その後はブラウザで処理を続けるか、Mihomo へ統一するかを選択できます。重要なのは、三か所で同時にオーバーライドしないことです。

WebRTC に 192.168.x.x と表示された場合は、まずプライベートアドレスか確認する

WebRTC は音声、映像、ピアツーピア通信のために候補アドレスを収集します。現在のブラウザでは、ローカルアドレスを mDNS 名で隠すことも、プライベートネットワークを表示することもあります。これらの情報から LAN 環境を確認できますが、インターネットからコンピューターへ直接ルーティングできるわけではありません。

実際に対処が必要なのは、プロキシを有効にしてもローカル ISP のグローバル IPv4 または IPv6 が表示される場合です。WebRTC を完全に無効にすると Web 会議と画面共有が機能しなくなるため、ブラウザのアドレス制限機能を優先し、Zoom、Meet、Slack Huddle で機能を再検証してください。

IPv4 は正常でも IPv6 が直接接続になる場合は、処理するか無効にするかを判断する

システムプロキシは通常、アプリケーションから明示的に渡されたリクエストを処理しますが、すべての IPv6 接続を処理する保証はありません。TUN が IPv6 を処理するかどうかも、クライアントのバージョン、ルート、設定に依存します。まず業務で IPv6 が必要か確認してください。処理できない場合に一時的に IPv6 を無効にして比較するほうが、ルールの末尾へむやみに REJECT を追加するより、原因を判断しやすくなります。

トラブルシューティング用の例です。有効にする前に、クライアントが生成する設定で上書きされないことを確認してください
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip

# 若明确需要 IPv6，应改为让当前 TUN 与规则完整接管，
# 而不是长期依赖 ipv6: false。

一致しない項目だけを修正し、四つの欄を同じ地域にそろえることを目的にしない

DNS サーバーと出口ノードの地域が異なっていても、必ずしも異常ではありません。WebRTC にプライベートアドレスが表示されても、リークを意味するとは限りません。特定の項目に想定外のグローバル出口が残っていることを確認してから、その項目を対象に対処してください。

グローバル IPv4 が引き続きローカルの出口になる

ブラウザのリクエストがプロキシへ入っていません。システムプロキシ、拡張機能、ルールへの一致を確認してください。

IPv4 はノードを通り、IPv6 はローカルの出口を通る

TUN の IPv6 ルートを確認します。IPv6 が不要な場合は、OS 所定の方法で無効にして比較できます。

DNS だけが想定と異なる

ブラウザの DoH、システム DNS、Mihomo DNS のどれが実際に処理しているか確認します。

LAN のプライベートアドレスだけが表示される

実際のグローバル候補がほかにもないか先に確認し、プライベートアドレスだけでリークと判断しないでください。

参考資料