v2rayNのDNSリーク検出方法と対策設定

DNSリークとは？ウェブ通信がプロキシ経由でも、名前解決は別経路の場合がある

ドメインにアクセスする前に、アプリは通常、対応するIPアドレスを取得します。DNSリークとは、本来指定したプロキシ経路を通すはずのドメイン検索が、利用中の回線事業者のDNSなど、想定外のリゾルバーに送られる状態です。ウェブの出口IPが変わっていても、DNSクエリが同じ経路を通ったとは限りません。

v2rayNはクライアントの管理画面です。実際の接続や名前解決の動作は、選択したコア、生成された設定、通信の入口にも左右されます。システムプロキシの設定が適用されるのは、その設定に従うアプリだけです。プログラムが独自にUDP DNSリクエストを送信したり、ブラウザーで独自のセキュアDNSを有効にしたりすると、別の名前解決経路が使われる場合があります。

ポート番号は通信の識別に役立ちますが、それだけで安全性を判断することはできません。DoHはHTTPS経由でDNSクエリを送信しますが、接続自体が直接通信なら、DNSサービスへのアクセスはプロキシを経由しない可能性があります。反対に、従来型DNSがプロキシトンネル内を流れる場合も、「53番ポート」だけを根拠にリークと判断できません。

DNSリークテスト：基準値を記録してプロキシ利用時と比較

検出ページでは通常、ブラウザーからランダムなサブドメインへリクエストを送り、権威DNS側で受信したクエリをもとに再帰リゾルバーの出口を表示します。結果が示すのは、今回のブラウザーテストで使われた名前解決経路であり、PC上のすべてのアプリの通信を監査したものではありません。アドレスバーにdnsleaktest.comと入力し、標準テストと拡張テストを比較できます。

1. 基準値を記録する

   直接通信が許可されているネットワークで、まずv2rayNのシステムプロキシとTUNを無効にします。ウェブの出口IP、検出されたリゾルバーのIPと事業者名を記録してください。テストでは実際にネットワークリクエストが発生するため、機密性が求められる環境で保護を安易に無効にしないでください。

2. ブラウザーを統一する

   同じブラウザーと同じ設定でテストします。Edgeの場合は「設定」→「プライバシー、検索、サービス」→「セキュリティ」を開き、「セキュア DNS を使用する」の設定を確認します。バージョンによって表記が異なる場合があるため、設定内で「セキュア DNS」を検索してください。現在の設定値を記録し、テスト中は独自の名前解決を無効にします。

3. プロキシを有効にする

   v2rayNのメイン画面で「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、接続先ノードが利用可能なことを確認します。まずはシステムプロキシだけを有効にしてください。変更の影響を切り分けられるよう、TUNやノード、ルーティングテンプレートを同時に切り替えないでください。

4. 再度テストする

   検出ページを開き直し、標準テストと拡張テストをそれぞれ実行します。各状態で2回ずつ繰り返し、時刻、出口IP、リゾルバー、ルーティングモードを記録してください。ページに特定のリゾルバーが表示されなくても、ほかのアプリがそのリゾルバーを使っていないとは限りません。

5. 経路を比較する

   プロキシを有効にしても基準値に記録した事業者のリゾルバーが表示される場合は、ブラウザーとシステムのDNS設定を確認します。パブリックDNSだけが表示された場合も、そのサービスが想定どおりか、接続が実際にプロキシ経由かを確認してください。

リモートDNSと直結DNSの役割

ここではv2rayN 7.xのデスクトップ画面を前提に説明します。一般的な設定場所は「設定」→「DNS設定」です。旧バージョンや異なるビルドでは、「設定」→「パラメーター設定」に関連項目がある場合もあります。使用中のメニューとコアを確認し、同じ名前の項目が見つからなくても、別のコア向けの設定をそのまま貼り付けないでください。

リモート名前解決には、設定画面でサポートされているDoHアドレス（例：https://dns.google/dns-query）を使用できます。直結名前解決には、ネットワーク環境に応じて到達可能なリゾルバー（例：223.5.5.5）を選べます。これらはサービスアドレスの例であり、すべてのネットワークで使える固定の正解ではありません。アドレスを入力した後、現在のコアがその形式に対応しているか、クエリがどのアウトバウンド経由で送信されるかも確認してください。

1. 現在の設定を保存します。リモートDNS、直結DNS、ルーティングテンプレート、コアの種類を記録します。カスタム設定は、項目ごとに元へ戻せるよう別途コピーを保存してください。
2. リモート名前解決を設定します。「設定」→「DNS設定」で、現在のコアに対応するリモートDNS項目を調整します。画面に名前解決通信のアウトバウンド選択がある場合は、プロキシ経由を選んでください。項目がない場合は、実際に生成される設定と関連するルーティングルールを確認します。
3. 必要な直結設定を残します。直接接続するドメインには直結DNSを使います。プロキシサーバーをドメイン名で指定している場合は、そのプロキシ自体に依存しない初期名前解決経路も必要です。そうでないと「プロキシに接続してからでないと、プロキシのアドレスを解決できない」という循環依存が発生する可能性があります。
4. 適用して再テストします。保存後、コアが正常に再読み込みされたことを確認します。自動で再読み込みされない場合は、接続を停止してから再起動してください。同じ検出ページで再テストし、直結するはずのサイトにも正常にアクセスできるか確認します。

TUNとFakeDNS：通信の取り込み範囲とアドレス変換を分けて考える

システムプロキシはブラウザーなどプロキシ設定に従うプログラムに適していますが、すべてのアプリを自動的にカバーするわけではありません。TUNは仮想ネットワークアダプターを介して、ルートに一致するIP通信を受け取ります。システムプロキシを使わないプログラムも処理したい場合に有効です。DNSまで取り込まれるかどうかは、DNSハイジャックルール、システムルート、IPv6、ほかのネットワークソフトにも左右されるため、TUNが有効かどうかだけでは判断できません。

FakeDNSは別の仕組みです。コアがドメインに対してプール内の合成IPアドレスを返し、後続の接続時にそのアドレスをドメインへ対応付けることで、ドメイン単位の振り分けを可能にします。Xrayでよく使われるIPv4 FakeDNSのアドレスプールは198.18.0.0/15です。合成IPを返すこと自体に暗号化の機能はなく、名前解決が自動的にリモートプロキシ経由になるわけでもありません。

• 対応状況を確認します。v2rayNで、選択中のコアと設定モードがFakeDNSに対応しているか確認してください。コアによって設定項目や実装が異なるため、Xrayのfakedns設定を別のコアにそのまま適用しないでください。
• DNSと接続の両方を取り込みます。合成アドレスを取得したアプリの後続通信も、同じ対応付けの仕組みに通す必要があります。DNSだけ変更して接続を取り込めていないと、名前解決はできてもウェブページを開けないことがあります。
• IPv6を確認します。IPv4 DNSやIPv4ルートだけを設定しても、IPv6経路までカバーされているとは限りません。AAAAクエリとIPv6接続をそれぞれ確認してください。IPv6を無効にすることを万能な解決策と考えないでください。
• 終了後にキャッシュを消去します。FakeDNSやTUNを無効にした後、Windowsターミナルでipconfig /flushdnsを実行し、ブラウザーを終了してから再起動します。ブラウザーやアプリ独自のキャッシュは、システムのキャッシュと一緒に消去されるとは限りません。

DNSタイムアウトや接続失敗：エラーから原因を切り分ける

エラーは前後のログと合わせて確認してください。コアのバージョンによって、ログのプレフィックスやドメイン、アドレスは異なります。以下はよくあるエラーの一部であり、ログ全体ではありません。短時間にノード、DNS、ルーティング、ブラウザー設定を同時に変更すると、原因を特定しにくくなります。

以下のコマンドで、システムの名前解決とSOCKSプロキシ経由の経路を切り分けます。例ではローカルSOCKSの待ち受けポートを127.0.0.1:10808としています。あらかじめ本体の設定画面または起動ログで実際のポートを確認してください。待ち受けアドレスはローカルに限定します。DNSの調査でプロキシポートをLAN全体に公開する必要はありません。

# システムのDNS設定を確認
ipconfig /all

# システムのデフォルトリゾルバーを確認。このコマンドはシステムのHTTPプロキシ設定には自動的に従いません
nslookup example.com

# SOCKS経由で接続先のホスト名を渡し、curlが接続先ドメインをローカルで先に解決するのを防ぐ
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

# 名前解決の設定を変更した後、WindowsのDNSキャッシュを消去
ipconfig /flushdns

--socks5-hostnameは接続先のホスト名をSOCKSプロキシ側に渡しますが、最終的な名前解決方法はコアの設定によって決まります。コマンドが成功しても、このリクエスト経路が動作したことを示すだけで、ブラウザーやほかのプログラムに迂回した名前解決がないことまでは証明できません。また、nslookupに表示されたローカルDNSアドレスを、ブラウザーでリークが発生した証拠とみなさないでください。

修正後の確認：テスト結果と利用状況をあわせて保存

DNSリーク対策のゴールは「検出ページに結果が一つだけ表示されること」ではありません。プロキシ経由にするクエリと接続が適切な経路を通り、必要な直接通信も維持されていることが重要です。拡張テストでは、同じDNSサービスの出口アドレスが複数表示されることがあります。表示数が変わっただけで障害とは限りません。

• ブラウザーで再テスト：記録したセキュアDNSの設定状態で2回テストし、基準値に記録した回線事業者のリゾルバーが意図せず再表示されないことを確認します。
• アプリで再テスト：普段使っているアプリのうち、システムプロキシに従うとは限らないものを一つ選んで個別に確認します。ブラウザーのテストに成功しても、そのアプリの通信が取り込まれている証拠にはなりません。
• 振り分けを再テスト：直接接続する想定のサイトと、プロキシ経由の想定のサイトにそれぞれアクセスし、ログでアウトバウンドの選択を確認します。一時的にログレベルを上げた場合は、調査後に元へ戻してください。アクセス情報を長期間記録し続けないようにしましょう。
• ネットワークを切り替えて再テスト：自宅のネットワークからスマートフォンのテザリングに切り替えて、もう一度テストします。新しいネットワークでDNS、IPv6、ルーティングが変わると、これまで表面化していなかった設定上の問題が現れることがあります。
• 元に戻せるよう記録を保存：v2rayNとコアのバージョン、プロキシモード、DNSサービスのアドレス、検出時刻を記録します。ログを共有する前に、サブスクリプションURL、認証情報、不要なアクセス先ドメインを削除してください。

ウェブサイトは問題なく開けるのに検出ページの地域がノードと異なる場合は、まずリゾルバーの識別情報と転送経路を確認してください。DNSを変更した後、すべてのノードに接続できなくなった場合は、元の設定に戻してノードのドメインを解決する初期経路を確認します。「ブラウザー、DNSのアウトバウンド、システム側の取り込み」の順に切り分けると、すべての機能を同時に有効にするより原因を特定しやすくなります。