FakeDNSは仮想アドレスにドメイン情報を対応付ける仕組みです。TUNで通信を取り込んだ後もドメインに基づいて振り分けたい場合に役立ちます。通信を高速化する機能でも、通常のDNS解決に置き換わるものでもありません。アドレスの返却から通信の取り込み、ドメインの復元、接続先の選択まで順を追って解説し、利用条件や設定の確認項目、元に戻す手順も紹介します。接続が正常に動作しており、DNSやルーティングの見直しを検討している方向けです。
FakeDNSがドメイン情報を保持する仕組み
通常のDNSでは、ドメイン名を接続先サーバーのIPアドレスに変換します。その後アプリが接続を開始すると、システムのネットワーク層からは通常、接続先のIPアドレスしか見えません。複数のドメインが同じIPアドレスを使っている場合、そのIPだけから元のアクセス先を特定するのは困難です。FakeDNSは応答方法を変え、まず仮想IPを割り当て、そのIPとドメインの対応をローカルに記録します。
たとえば、アプリが example.com を問い合わせると、FakeDNSはアドレスプールからIPアドレスを割り当てます。アプリがそのアドレスに接続すると、プロキシのコアが対応表から example.com を復元し、ドメインを使ってルーティングを判定します。このアドレスは端末内の処理で使う目印にすぎず、Webサーバーの新しいアドレスではありません。リモートノードの接続先として直接使うこともできません。
仮想アドレスプールと通常のDNS解決の違い
XrayのFakeDNS設定では、IPv4アドレスプールの例として 198.18.0.0/15 がよく使われます。この範囲は 198.18.0.0 から 198.19.255.255 までで、ネットワーク性能測定用に予約されたアドレス空間です。インターネット上の接続先として直接アクセスできるアドレスではありません。家庭内LANで使うプライベートアドレス帯とも異なります。
アドレスプールの範囲と、保持できる対応情報の数は別のものです。ネットワーク範囲に含まれるアドレス数と、現在のコアが保持する対応情報の数が同じとは限りません。容量や解放方法、再起動後も対応情報が残るかどうかは実装によって異なります。サンプル設定の容量を、すべてのクライアントの既定値だと考えないでください。
- 仮想応答：アプリにローカルで識別できる接続先の目印を先に返します。Webサイトの実IPアドレスをただちに取得する必要はありません。
- 通常の名前解決：最終的な接続先は実際のサービスである必要があります。ドメイン名を使ってリモートプロキシに接続する場合は、リモート側で名前解決できます。直接接続する場合は、通常ローカルで実際の名前解決が必要です。
- 暗号化DNS：DNS問い合わせの通信方式を保護する仕組みです。仮想IPを返すかどうかとは別の問題であり、互いに代替できません。
TUNモードでドメイン振り分けを行う仕組み
TUNは、ルーティング条件に合うIP通信を仮想ネットワークインターフェースに取り込みますが、アプリが問い合わせたドメイン名を自動的に保持するわけではありません。FakeDNSを使うと、コアが接続先の仮想IPからドメイン名を復元し、ドメインルールと照合できるようになります。システムのHTTPプロキシは使わないものの、TUNで通信を取り込めるアプリに特に有効です。
TUNと仮想アドレスの連携
- DNS応答
- 対応情報を扱えるコンポーネントが仮想IPを返す
- 通信の入口
- 仮想ネットワークインターフェースと関連するルート
- ドメイン名の取得元
- DNS問い合わせと接続先IPの対応情報
- 確認するポイント
- アドレスプール宛ての通信が同じ処理経路に戻るか
TUNで通信を取り込み、対応情報からドメインを復元します。両方が正しく動作して初めて一連の処理が成立します。
システムプロキシがドメイン名を渡す
- DNS応答
- 仮想アドレスが不要な場合もある
- 通信の入口
- アプリが使用するHTTPまたはSOCKSプロキシ
- ドメイン名の取得元
- プロキシリクエストに含まれる接続先のホスト名
- 確認するポイント
- アプリがドメイン名をプロキシに渡しているか
アプリからプロキシにドメイン名が渡されているなら、通常FakeDNSは必須ではありません。
ドメイン名を復元した後にどの出力先へ接続するかは、引き続きルーティングルールで決まります。FakeDNSがすべての通信を自動でプロキシに通すわけでも、直結用の許可リストを作るわけでもありません。ドメインルールやIPルール、その優先順位によって判定結果は変わります。IPの地理情報に基づいて振り分ける場合は、ルールが参照するアドレスが名前解決後の実際の接続先IPかどうかも確認してください。
FakeDNSの利用が向いているケース
まず、現在の接続でどの情報が失われているかを確認してから、利用するか判断します。実用上の目安は、アプリの通信を取り込めているのにコアのログには接続先IPしか表示されず、期待するドメインルールが適用されないこと、さらにアプリのDNS問い合わせも同じ処理経路に取り込めることです。この両方を満たす場合に、試す価値があります。
| 利用場面 | 推奨 | 優先して確認する項目 |
|---|---|---|
| TUNで通信を取り込み、主にドメインルールで振り分ける | 有効にして試す価値あり | DNS問い合わせと仮想アドレス宛ての接続をどちらも取り込めるか |
| ブラウザーがシステムプロキシを正常に使用している | 通常は現状のままでよい | プロキシリクエストにドメイン名が含まれているか |
| 業務用VPNと社内ドメインを併用している | 先に除外対象を計画する | 社内DNS、社内ネットワークのアドレス帯、ルートの優先順位 |
| アプリが実IPの保存や検証を必要とする | 通常の名前解決を優先 | 仮想アドレスによってアプリの判定が変わらないか |
| 接続先がIPアドレスで直接指定されている | 対応情報からドメイン名を補うことはできない | IPルールで接続を直接処理する |
FakeDNSを使うと、「実際に名前解決してから転送方法を決める」必要性を減らせる場合がありますが、ダウンロード速度やアクセス遅延の改善を保証するものではありません。アプリが独自に暗号化DNSを使っている場合、問い合わせがローカルの対応情報を扱うサービスを経由しないことがあります。通常のDNS問い合わせを取り込めていても、そのアプリには仮想IPではなく実IPが返される可能性があります。
有効にする前に処理経路を4項目確認
v2rayNのデスクトップ版では、まず「設定」で現在のTUN、DNS、ルーティングの各項目を確認します。具体的なサブメニューは使用中のバージョンによって異なります。Android版のv2rayNGはXrayコアを使用しますが、VPNの許可に成功しただけでは、FakeDNSの対応情報が機能しているとは限りません。どちらも先に現在の設定を記録し、一度に複数の項目を変更しないようにしてください。
- 現在の設定をバックアップする。DNSサーバー、ルーティングルール、使用中のコアを記録します。まずFakeDNSを無効にした状態でノードが利用できることを確認し、既存の接続障害を対応情報の問題と誤認しないようにします。
- DNSの入口を確認する。対象アプリの問い合わせがどのリゾルバーを通るか確認します。従来のDNSでは通常UDPまたはTCPの
53番ポートを使いますが、ブラウザー内蔵の暗号化DNSは、このポートを調べるだけでは判別できません。 - アドレスプールのルートを確認する。
198.18.0.0/15を使う場合は、該当するアドレス帯が社内ネットワークで使われていないこと、またルールによって物理ネットワークインターフェースへ迂回されていないことを確認します。特殊なネットワークでは実際にこの範囲を使用している場合があるため、競合する場合はそのまま使わないでください。 - ドメイン名の復元を確認する。現在のコアのインバウンド、スニッフィング、対応情報に関する設定を確認し、仮想IPからドメイン名を復元できることを確かめます。Xrayの
fakedns、ipPool、poolSizeなどはそれぞれ役割が異なります。対応情報を利用するインバウンド設定を無視して、アドレスプールだけを追加しないでください。
スニッフィングとFakeDNSは別の機能です。スニッフィングではHTTPのホスト名やTLSハンドシェイク情報からドメインを特定できる場合があります。一方、対応情報の復元には、事前に記録されたDNS問い合わせが必要です。通信の種類によって取得できる情報は異なるため、すべての暗号化通信でスニッフィングによりドメイン名を復元できるとは限りません。クライアントが設定を自動生成する場合、生成ファイルを手動で変更しても次回起動時に上書きされることがあります。
仮想IPとルール適用を確認する方法
テストでは、一般的なドメインを1つと直結が必要な社内ネットワークの接続先を1つだけ選びます。既存の接続を終了してから、再度名前解決してアクセスしてください。開いたままのページだけで判断しないでください。接続の再利用やDNSキャッシュによって、変更前の結果が使われ続けることがあります。
- 手順1：名前解決の結果を確認する。Windowsでは
nslookup example.comを実行できます。このツールの名前解決経路が実際にFakeDNSを通る場合、応答は設定したアドレスプールの範囲内になります。異なる結果でも機能が無効とは限りません。まず、ツールがアプリと異なる名前解決経路を使っていないか確認してください。 - 手順2：コアのログを確認する。ドメインに再アクセスし、ログで元のドメイン名、適用されたルール、出力先を確認します。ログレベルによって表示項目は異なります。必要な場合のみ一時的にログレベルを上げ、確認後に元へ戻してください。
- 手順3：直結先を確認する。社内ドメインやLAN上のサービスをテストし、誤ってプロキシ経由になっていないか確認します。「ドメイン名、名前解決の結果、適用された出力先、接続の成否」を記録し、一度に変更する設定は1つにします。
直結との競合と無効化後の復旧手順
よくある失敗は、アプリには仮想IPが返されたものの、接続が対応情報を認識できない経路を通ることです。たとえば、プロセスがTUNの対象外なのに、DNSだけは取り込み対象のシステムDNSを使っている場合や、企業VPNがアドレスプールの範囲を横取りしている場合があります。こうした問題はノードの速度不足ではないため、ノードを何度も切り替えても通常は解決しません。
有効にした後、特定の直結アプリだけ接続できない場合は？
まず、そのプロセスがTUNの対象外になっていないか確認します。直結が必要な場合は、実際のDNS応答を使わせ、接続も直結経路を通るようにしてください。DNSの除外と通信の除外はセットで設定します。プロセスだけを除外しながら、仮想アドレスを返し続けないようにしてください。
FakeDNSを無効にしてもタイムアウトするのはなぜ？
アプリやシステムに古い仮想IPがキャッシュされている可能性があります。DNS設定を元に戻した後、影響を受けるアプリを再起動してください。Windowsではコマンドプロンプトで ipconfig /flushdns を実行し、システムのDNSキャッシュを削除してから再接続します。ブラウザー独自のキャッシュや既存の長時間接続も、個別に再作成が必要な場合があります。
クライアントの再起動後、一部の接続が突然失敗した場合は？
「アプリには古いDNS結果が残っている一方で、コアの対応情報は再構築された」という状態になっていないか確認します。古い接続を終了し、関連するキャッシュを削除してから再度名前解決してください。実装によっては対応情報を永続化できますが、対応状況は使用中のバックエンドによって異なります。再起動前後で対応情報が必ず同じだとは限りません。
仮想IPが表示されたら、DNS漏えいがないと言える？
いいえ。その問い合わせで仮想IPが返されたことしか分かりません。他のアプリやレコードタイプ、ブラウザー独自の名前解決経路では結果が異なる可能性があります。システムのリゾルバー、アプリの暗号化DNS、IPv6のAAAA問い合わせをそれぞれ確認し、実際のルーティング状況も合わせて判断してください。
目的が対応情報の動作確認ではなく安定した接続であれば、説明しやすく元に戻せる設定を優先してください。システムプロキシでドメイン名が正しく渡されているなら、FakeDNSを追加する必要はありません。TUNでドメイン振り分けが必要な場合に限り、DNS、対応情報、ルーティング、出力先を1項目ずつ確認しましょう。原因を特定できない接続障害は、すべてのネットワーク設定を同時に変更せず、接続トラブルの確認手順に沿って調べてください。