NT-03.1DNS漏洩とは何か、プロキシ接続中でも起こる理由
DNS漏洩とは、通信自体はプロキシを経由しているにもかかわらず、ドメイン名からIPへの解決リクエストがプロキシを通らず、端末本来のDNSサーバー(通常は契約プロバイダやルーターが割り当てたアドレス)へ直接送られてしまう状態を指します。これは、ページの内容自体はプロキシ経由で転送されていても、どのドメインにアクセスしたかという情報がローカルネットワーク上に露出していることを意味し、さらに解決結果の不一致により接続が不安定になったり改ざんされたりする原因にもなります。
この現象が起きる根本的な原因は、大きく2つの層に分けられます。1つ目はシステムプロキシモードで、OSはアプリケーション層のHTTP/HTTPS転送しか代替せず、DNSリクエストは独立したUDP53番ポートを経由します。クライアント側がこの通信経路を専用に処理していない場合、リクエストはプロキシを迂回して直接送信されます。2つ目は、クライアントがDNSを代替していても、dns設定のnameserverがローカルまたは契約プロバイダのアドレスを指していれば、解決結果は依然としてローカルネットワークの影響を受けるという点です。「ドメインリクエストがプロキシを通るか」とは別に確認すべき事項になります。
ClashとClash Meta(mihomo)コアはいずれも設定ファイル内に独立したdnsセクションを持ち、enhanced-modeによって解決リクエストの処理方式を決定します。このフィールドの挙動を理解することが、漏洩の調査と修正の前提になります。
NT-03.2検証手順:設定変更の前に問題を切り分ける
設定を変更する前に、再現可能な手順で実際に漏洩が起きているかを確認し、感覚だけでパラメータを調整するのを避けましょう。以下の手順はどのプラットフォームのクライアントでも共通で使えます。
- プロキシを切断した状態で、端末が使用しているDNS出口アドレスを一度記録します(システムのネットワーク設定から現在のアダプターが使用するDNSサーバーを確認できます)。
- プロキシを接続し、ポリシーグループが利用可能なノードを選択していることを確認したうえで、クライアントのログパネルを開き、
DNSやresolveといったキーワードでフィルタして解決リクエストの出力を観察します。 - リクエスト元情報を表示してくれる検証用ページにアクセスし、2回分の結果を比較します。プロキシ接続前後で返される解決サーバーのアドレスが一致しているかを確認してください。プロキシ接続後も端末の契約プロバイダのDNS出口が表示される場合は漏洩が発生しています。
- クライアントの接続パネル(Connections)で現在アクティブな接続の宛先アドレスを確認し、解決されたIPが想定しているプロキシのアドレス帯に収まっているか、ローカルネットワークから直接到達可能なアドレスに解決されていないかをチェックします。
- TUNモードに切り替えて同じ手順を繰り返し、システムプロキシモードでの結果と比較して、漏洩が特定の代替方式でのみ発生していないかを判断します。
プロキシ接続の前後で解決リクエストの出口アドレスが変わらない場合、そのリクエストはdns設定の処理ロジックを経由していないことを意味します。enhanced-modeやシステム側のDNS設定が他のプログラムに上書きされていないか確認してください。
NT-03.3enhanced-modeの2つの値と動作の違い
dns設定の中核となるフィールドはenhanced-modeで、ドメイン解決を統一処理にどう組み込むかを決定します。よく使われる値はfake-ipとredir-hostです。
| モード | 解決の挙動 | 適した用途 |
|---|---|---|
fake-ip | クライアントが仮想アドレス帯内の偽IPを返し、実際の解決は接続確立時にドメインマッチングルールに沿って処理される | デフォルト推奨、TUNモードとルール分岐との組み合わせで互換性が最も高い |
redir-host | 上流の nameserver に直接問い合わせて実際のIPを取得し、アプリケーションへ返す | 返されるIPを厳密に検証するアプリなど、偽IPが使えない場合の互換オプション |
実用的なdns設定例は以下の通りです。ポイントは、端末が元々使っていた解決サーバーをそのまま使うのではなく、nameserverを暗号化通信に対応したアドレスへ切り替えることです。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.market.xiaomi.com"
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.4.4:853
このうちnameserverはメインの解決リストで、DoH(DNS over HTTPS)またはDoT(DNS over TLS)プロトコルのアドレスに統一するのがおすすめです。これにより解決リクエスト自体も暗号化され、ローカルネットワークで平文のまま傍受されなくなります。fallbackリストはメインのnameserverが改ざんされた結果と判定した際に使用されるもので、同様に暗号化プロトコルのアドレスを使うことをおすすめします。
NT-03.4fake-ip-filterの設定不備によるLAN内アクセスの不具合
fake-ipを有効にすると、よくある副作用としてLAN内のデバイス名解決(ルーター管理画面、NAS、プリンターなど)も偽IPに置き換えられ、アクセスできなくなることがあります。fake-ip-filterフィールドは、どのドメインを偽IP解決の対象外として実際の解決結果をそのまま使うかを指定するためのものです。
dns:
fake-ip-filter:
- "*.lan"
- "*.local"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
ここで+.接頭辞はそのドメインおよびすべてのサブドメインにマッチし、*はワイルドカードとしてマッチします。特定のLAN内デバイスや、正確な出口IPが必要なサービス(社内システムなど)がプロキシ有効化後にアクセスできなくなった場合は、まずそのドメインをこのフィルタリストに追加すべきか確認してください。fake-ip自体を無効化するのは最後の手段です。
enhanced-modeを直接redir-hostに変更すれば偽IPによる互換性の問題は回避できますが、ドメインベースのルール分岐能力が弱まり、SNIやIP帯マッチングに依存する一部のポリシーグループルールが無効になる可能性があります。互換性の問題に遭遇したら、まずはfake-ip-filterの追加を試し、モード全体の切り替えは避けてください。
NT-03.5システムプロキシモードとTUNモードでの差異調査
システムプロキシモードは、アプリケーションが自らシステムプロキシ設定を読み取る通信部分のみを代替します。一部のコマンドラインツール、UDP通信の一部、システムプロキシ設定に従わないプログラムのDNSリクエストは、クライアントを完全に迂回する可能性があります。このタイプの漏洩はdns設定の調整だけでは解決できず、TUNモードを有効にして仮想ネットワークアダプターにネットワーク層でDNSクエリを含む全通信を統一的に代替させる必要があります。
TUNモードを有効にした後も、「通信は代替できているのに解決が代替できていない」という中途半端な状態を避けるため、以下の2点を確認してください。
tun設定内のdns-hijackフィールドが有効になっているか(よく使われる値は0.0.0.0:53やany:53)を確認します。これはネットワーク層で53番ポートへのDNSリクエストをすべて捕捉し、内蔵DNSサービスへ引き渡す役割を担います。- WindowsとmacOSでは、元のアダプターのDNS設定がシステムに残っていると、一部のプログラムがシステムの解決キャッシュを優先的に使ってしまうことがあります。TUNモードの有効化を確認した後、一度端末のDNSキャッシュをクリアしてから再テストすることをおすすめします。
TUNモードの具体的な有効化手順とプラットフォームごとの差異については、サイト内の仮想ネットワークアダプターによる通信代替に関する専門記事を参照してください。ここでは詳細を繰り返しません。dns-hijackとenhanced-modeの設定が完了したら、本稿の第2部の検証手順を繰り返し、プロキシ接続前後の解決出口アドレスが一致しなくなった時点で、一連の検証が完了したことになります。
NT-03.6設定変更後の確認事項
dns設定の変更は影響範囲が広い操作なので、設定ミスによる接続異常を減らすために、以下の順序で確認することをおすすめします。
- まずテスト環境や予備の設定ファイルで変更を試し、問題がないことを確認したうえで普段使いのプロファイルに反映します。使用中のサブスクリプション設定を直接上書きしないようにしてください。
nameserverアドレスの形式が正しいか一つひとつ確認します(DoHアドレスは完全なURLである必要があり、DoTアドレスにはtls://接頭辞とポート番号が必要です)。- 本稿の第2部の検証手順を再度実行し、解決出口アドレスの変化を記録します。
- 一定期間通常利用を続け、LAN内デバイスへのアクセスや社内サービスなどが影響を受けていないことを確認します。
DNS漏洩の調査は、本質的には「ドメイン解決」という段階までプロキシ経路に組み込まれているかを確認する作業であり、単なる通信転送だけでは不十分です。enhanced-mode、nameserver、fake-ip-filterの3項目を一つずつ突き合わせて確認すれば、ほとんどの漏洩問題は設定レベルで解決できます。