Clash DNSリーク検出方法:fake-ipモードとリーク防止設定の実践

▶DNSリークとは何か、なぜ発生するのか

プロキシソフトの中核的な処理は二段階に分かれる:まずドメイン名をIPに解析し、その後そのIP宛の通信をトンネルに送り込む。ルールによる振り分け(たとえばドメイン名でマッチさせて中国本土サイトは直接接続、海外サイトはプロキシ経由にするなど)は、Clash自身が解析を完了しその結果に基づいてルーティングすることを前提としている。DNSクエリがClashを経由せず、システムのネットワークカードから直接ローカルの通信事業者DNSや、プロキシを通さない解析サーバーへ送られてしまうと、監視側は完全なドメインアクセス履歴を入手できてしまう——これがDNSリークである。ウェブページの表示自体には影響しないため見落とされやすいが、プライバシーと振り分けの正確性の両方にとって深刻な問題となる。

よくあるリークの原因は特別なものではなく、大きく以下のカテゴリーに集約される:

ブラウザに内蔵の安全なDNS(DoH)機能が有効になっており、システムの解析サーバーを迂回して指定の暗号化DNSプロバイダーへ直接接続するため、Clashの制御範囲から完全に外れてしまう。
仮想マシン、コンテナ、一部のサンドボックス環境は独立したネットワークスタックとresolv.confを使用しており、ホストのプロキシ設定を通らない。
TUNモードは有効になっているがDNSハイジャックの設定が不十分な場合、53番ポートのUDPリクエストが仮想ネットワークカードを迂回して直接外部に送信される。
システムがIPv6のネットワーク出口を同時に保持している一方、ClashのdnsセクションはIPv4クエリのみを処理している場合、IPv6の解析はネイティブ経路を通ってしまう。
ルールセット内で一部のドメインにno-resolveが指定されている場合、本来は解析をスキップしてIP帯のみをマッチさせる意図だが、設定順序が誤っているとそのドメインの解析リクエストがシステムから先に送信されてしまう。

▶DNSリーク検出の再現可能な手順

検出に追加のソフトウェアは不要で、4つのステップに分かれており、どのプラットフォームでも実行できる:

まず「クリーン」な結果を記録する。 プロキシとVPNを完全に無効にし、コマンドラインツールで任意のドメインを解析し、返された解析サーバーのアドレスを記録する。これがあなたの通信事業者のネイティブDNS出口である。
Clashを有効にした状態で同じクエリを繰り返す。 コマンドラインでnslookupやdigを使って同じドメインを解析し、2回目に返された解析サーバーのアドレスが1回目と完全に一致していれば、そのクエリはClashを経由せず、システムのネイティブ経路を直接通ったことを意味する。
パケットキャプチャツールでポートの行き先を確認する。 tcpdumpやWiresharkで53番ポート(および853番ポート、DoTが使用する)のトラフィックを取得し、これらのパケットがどのネットワークカードから送信されているかを観察する。TUNネットワークカードやローカルループバックアドレス(Clashの監視アドレス)を通っていれば安全だが、物理ネットワークカードから外部DNSのIPへ直接接続していればリークである。
Clash自身のDNSログを確認する。 ログレベルをdebugに変更するか、コントロールパネルの接続記録を直接確認し、対象ドメインの解析リクエストが確実にClashのログに記録されているかを確認する。記録されていない場合、そのクエリは処理されていないことになる。

ブラウザレベルではもっと直感的な確認方法もある:複数ノード検出に対応したオンラインDNSリークテストページを開き、プロキシ有効前後で返される解析ノードの所属地を比較する。プロキシを有効にした後も所属地が自分のローカル通信事業者のある都市のまま表示されている場合、リークが発生している可能性が高い。

ブラウザに搭載された「セキュアDNS」のスイッチは最も見落とされがちな抜け穴である。Chrome、Edge、FirefoxはいずれもデフォルトでDoHを有効にし、固定のプロバイダーを指定する場合があり、システムのプロキシ設定が正しくても、ブラウザは独自の暗号化経路を優先して迂回してしまう。検出を行う前に、ブラウザのセキュアDNS設定が「システムに従う」になっているか、あるいは無効化されているかを確認しておくこと。

▶fake-ipとredir-host:2つの拡張モードの本質的な違い

Clashのdnsセクションでは、enhanced-modeがドメイン解析結果とルールルーティングの連携方法を決定し、これはリーク防止設定における最も重要な項目である。

fake-ipモード

Clashはアプリケーションからのドメイン解析リクエストを受け取ると、実際のパブリックネットワークへの問い合わせを行わず、あらかじめ確保された仮想アドレスプール(通常は198.18.0.0/16のような実際のネットワークには出現しない帯域)から「フェイクIP」を割り当ててアプリケーションに返す。アプリケーションがこのフェイクIPで接続を開始すると、Clashはトンネル構築の瞬間に初めてフェイクIPから対応するドメインを逆引きし、ルールに従って直接接続かプロキシノード経由かを決定し、この時点で初めて実際の解析を行う。この全過程において、システムレベルで観測できる解析結果は常に仮想アドレスであり、実際の宛先ドメインに対応するパブリックIPは露出しない。またシステムのDNS出口に依存する必要もないため、TUNモードの透過プロキシシナリオに自然に適合する。

redir-hostモード

Clashは上流のDNSサーバーに対して直接実際の解析を行い、実際のIPを取得してアプリケーションに返すとともに、このクエリを記録し、以降このIPに対応する接続はルール表に従って転送される。このモードの問題は2点ある:1つは、実際の解析結果がアプリケーションにキャッシュされたり、システムレベルの他のプロセスに捕捉されたりした場合、理論上情報が露出する可能性が残ること。2つ目は、CDNを大量に使用し1つのドメインが複数の動的IPに対応するサイトの場合、IP帯によるルールマッチングでは判定を誤りやすく、振り分けが不正確になることである。redir-hostは旧バージョンのクライアントや仮想ネットワークカードに対応しない展開シナリオに適しており、新規の設定では基本的に優先すべきではない。

結論は明快である:TUNモードが使えるシナリオでは統一してfake-ipを選択すべきで、リーク防止と振り分けの正確性の両方がより確実に保証される。旧来のルールセットとの互換性が明確に必要な場合や、解析結果をデバッグする場合に限り、一時的にredir-hostへ切り替える。

▶dnsセクションの設定を項目ごとに調整し、リーク経路を塞ぐ

モードの選択が確定した後、以下のdnsセクションはそのまま照らし合わせて確認できるチェックリストであり、各項目が具体的なリークリスクポイントに対応している:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  ipv6: false

enable / listen——まずDNSサービスが実際に有効化され、指定のポートで監視されているかを確認する。クライアントのGUIでこのスイッチを手動で有効化していない場合、設定ファイルに記述しても反映されない。
enhanced-mode: fake-ip——前節の結論に従って固定的に選択し、fake-ip-rangeには実際のパブリックアドレスと衝突しないプライベート帯を使用する。
fake-ip-filter——LAN内デバイスや内部ネットワークサービスなどのドメインはフェイクIPの割り当て対象から除外する必要がある。そうしないとLAN内での直接接続に失敗する。ここでの除外はリークを引き起こさない、そもそも内部ネットワークへのアクセスだからである。
default-nameserver——下のnameserverとfallbackに記載されているDoH/DoTのドメイン自体を解析するために専用で使用され、必ずベアIPを指定する必要がある。そうしないと「暗号化DNSのドメインを解析するのにDNSが必要」というデッドロックが発生する。
nameserver——上流の解析には暗号化プロトコル(DoHまたはDoT)を使用し、この経路自体がネットワーク中間で平文記録されることを避ける。同時にこれらのクエリはデフォルトでClashを経由して処理され、システムネットワークを直接通ることはない。
nameserver-policy——特定のドメイングループに専用の上流を指定する。一般的な手法として、中国本土のドメインはローカル解析で高速化し、海外のドメインは暗号化された上流を使用し、速度とプライバシーの両方に配慮する。
fallback / fallback-filter——デフォルトの上流が返す結果が汚染または信頼できないと判定された場合、自動でバックアップの解析サーバーに切り替える。geoip-code: CNは返された結果が想定地域に収まっているかを判定するために使用される。
ipv6——システムやルーターがIPv6の出口を保持し続けており、ここで対応する処理がされていない場合、IPv6のドメイン解析はfake-ipを迂回してネイティブ経路を直接通ってしまい、最も見落とされやすいリークポイントとなる。IPv6ルールを専用に設定していない場合は、直接無効化することを推奨する。

TUNモードでもリークが検出される場合は、まずシステムのネットワークアダプター一覧でClashが作成した仮想ネットワークカードが、システムによって優先度最高のデフォルトルートインターフェースとして正しく設定されているかを確認する。一部のシステムはマルチネットワークカード環境で仮想ネットワークカードの優先度を自動的に下げることがあり、その結果DNSクエリが別のカードを選んで直接外部に出てしまう。

▶システムレベルとブラウザレベルの追加チェック

設定ファイルの調整が済んだ後も、dnsセクションには含まれないがリークの原因となりうるシステムレベルの設定がいくつかあり、一つずつ確認する価値がある:

ブラウザのセキュアDNSスイッチは統一して「システムに従う」に設定し、固定のDoHプロバイダーを個別に指定しない。指定するとブラウザのトラフィックがClashのDNS制御ロジックを迂回してしまう。
OSのネットワークアダプターのDNS設定はできるだけ空欄または自動のままにし、通信事業者のDNSアドレスを「バックアップ」として手動入力しない。バックアップアドレスは一部のシステムのポリシー下で優先的に採用されることがある。
ルーターや家庭用ゲートウェイでDNSハイジャック機能が有効になっている場合、デバイスが暗号化DNSリクエストを送信する前に傍受・置き換えられる可能性がある。この場合はクライアント側で暗号化プロトコル(DoH/DoT)が確実に確立されており、平文クエリにダウングレードされていないかを確認する必要がある。
複数ユーザーまたは複数ネットワークのプロファイルを切り替える際は、第2節の検出手順を再度実行し、1つの設定がすべてのネットワーク環境で同じ挙動を示すと決して思い込まないこと——公共Wi-Fi、企業ネットワーク、モバイルデータネットワークではDNSハイジャックのポリシーが全く異なる場合がある。

以上のチェックを一通り終えれば、DNSリクエストの完全な経路がプロキシトンネルに収まっていることをほぼ確認できる。リーク防止設定は一度きりの作業ではなく、デバイスの変更、ネットワークの変更、クライアントバージョンのアップグレードのたびに第2節の4つの手順で再検証する価値がある。コストは低く、ルールによる振り分けが「効いているように見えて実際には漏れている」状況を事前に発見できる。