DNS拡張モードは返すアドレスを決める

Mihomoのdns.enhanced-modeは、主に内蔵DNSの応答内容と、その後の接続をドメイン名に紐付ける方法を設定します。プロキシモードとは別の設定であり、すべての通信がプロキシ経由になるかどうかを決めるものではありません。Rule、Global、Directは別の設定階層です。TUNはシステムの通信を取り込む役割を担います。

まず押さえたい違いは、fake-ipでは通常、カーネルが割り当てた合成IPv4アドレスをアプリに返すのに対し、redir-hostでは上流DNSが解決した実際のアドレスを返すことです。どちらの方式も、DNSクエリが正しく取り込まれる必要があります。設定でDNSを有効にしただけでは、システムやブラウザーのクエリが自動的にカーネルへ送られるわけではありません。

比較項目 Fake-IP redir-host
アプリが受け取るIPv4アドレス 通常は合成アドレス 上流DNSが解決した実アドレス
ドメイン名と接続の紐付け 合成アドレスとの対応関係から復元 DNSの対応情報などに依存し、必要に応じてスニッフィングを併用
応答前に必要な処理 接続先の実アドレスを待たずに割り当て可能 通常は名前解決の結果が必要
よくある互換性の問題 アプリによるIPアドレスの検証、カーネルを経由しない通信 IPアドレスの共有によりドメインを一意に特定できない

Fake-IPの接続の仕組みと性能上の限界

合成アドレスは接続先サーバーのアドレスではない

一般的な設定では、Fake-IPのアドレス範囲に198.18.0.1/16を使用します。これはネットワーク性能測定用に予約された198.18.0.0/15の範囲内で、インターネット上で通常ルーティングできる接続先アドレスではなく、RFC 1918で定義されたプライベートアドレス帯でもありません。カーネルは割り当てたアドレスとリクエストされたドメイン名を対応付けます。

  1. アプリがドメイン名のAレコードを問い合わせ、そのクエリがMihomo DNSに届きます。
  2. カーネルがドメイン名に合成アドレスを割り当て、アプリに返します。
  3. アプリが合成アドレスへの接続を試みます。接続は、対応情報を保持しているカーネルを再び経由する必要があります。
  4. カーネルがドメイン名を復元してルールを照合し、選択されたDIRECTまたはプロキシの出口を通じて接続します。

合成アドレスは、対応するマッピングなしでは利用できません。アプリがそのアドレスをカーネルを経由しないプロセスに渡した場合や、TUNが該当アドレス宛ての通信を取り込めていない場合、接続に失敗することがあります。クライアントを終了した後もプログラムが198.18.x.xへ接続しようとする場合は、アプリやシステムに古い結果がキャッシュされている可能性があります。

DNS待ちを減らせても、すべての通信が速くなるわけではない

Fake-IPでは、実際に必要になるまで名前解決を遅らせられます。ドメインルールに一致し、使用するプロキシプロトコルがドメイン名の転送に対応している場合は、接続先の名前解決をリモート側で行えることがあります。DIRECTを選んだ場合は、カーネルが実アドレスを取得する必要があります。IPベースのルールでも名前解決が発生する場合があるため、実際の効果はルール構成に左右されます。

主に接続前のDNS待ち時間の一部を減らすもので、物理的な通信距離を縮めたり、プロキシサーバーの帯域を増やしたりするものではありません。ゲームの遅延、動画のスループット、パケット損失率は、引き続き出口、経路、プロトコルに左右されます。この記事では、実測による高速化率は示していません。名前解決段階の変化を、接続全体の性能向上と誤解しないためです。

redir-hostが適する条件

redir-hostでは、アプリは名前解決後の実アドレスを受け取り、カーネルは接続先のドメイン名を識別するためのDNS関連情報を管理します。実IPアドレスを前提とするアプリには従来のネットワーク動作に近い方式ですが、ドメイン名とアドレスの対応が一意とは限りません。複数のドメインが同じCDNアドレスを共有する場合も、同一ドメインから複数のアドレスが返る場合もあります。

  • まず試す価値があるケース：アプリが接続先IPを検証する、ほかのデバイスにアドレスを渡す、または複数のネットワークスタック間で名前解決結果を共有する必要がある場合。
  • 自動では解決できない問題：上流DNSが誤ったアドレスを返す、社内DNSに到達できない、UDPの出口が利用できない、または接続がカーネルに取り込まれていない場合。
  • 引き続き注意が必要なケース：アプリ独自の暗号化DNSにより、カーネルが通常のDNSクエリを認識できない場合。このとき、ドメインルールの照合に必要な情報が不足することがあります。

スニッフィングでは、一部のTLS、HTTP、QUIC通信からドメイン情報を補えることがありますが、すべてのプロトコルで利用可能なドメイン名を取得できるわけではありません。暗号化方式、クライアントの実装、スニッフィングの設定が結果に影響します。スニッフィングを有効にすれば、あらゆるドメイン振り分けの問題が解決するわけではありません。

fake-ip-filter：必要なドメインだけを除外

fake-ip-filterでは、合成アドレスを使用しないドメインを指定します。blacklistモードでは、一致したドメインは実アドレスで名前解決され、一致しないドメインには引き続きFake-IPを割り当てられます。Mihomoはほかのフィルターモードにも対応しているため、設定を確認する際はリスト名だけでなくfake-ip-filter-modeも確認してください。

以下はDNS設定の一例です。リッスンアドレスは127.0.0.1:1053で、ローカルホストからのみアクセスできます。これは完全なTUN設定ではなく、システムのDNSを自動で変更するものでもありません。既存の設定にdns:がある場合は、トップレベルのキーが重複しないよう項目を統合してください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - '+.home.arpa'
    - '+.lan'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

合成アドレスを除外しても、DIRECTにはならない

+.home.arpaは、そのドメインとすべてのサブドメインに一致します。ここでは家庭内ネットワークのドメイン処理例として使用しています。.lanは、一部のローカルネットワークで使われるサフィックスです。フィルターリストが変更するのはDNSの応答方式だけで、DIRECTルールを自動追加したり、クエリをルーターへ自動転送したりするものではありません。

そのため、社内ネットワークやLANへのアクセスには、通常、実アドレスを返すこと、適切な内部DNSに問い合わせること、到達可能な内部ネットワークの出口へ接続をルーティングすることの3つがそろう必要があります。最初の条件だけ満たしても、パブリックDNSからドメインが存在しないというエラーが返ることがあります。

LAN・社内ネットワークのDNS設定

家庭内ネットワークで192.168.50.53が内部DNSを提供し、デバイス名がnas.home.arpaだとします。前述のdns:の中に、以下の項目を追加できます。このアドレスはネットワーク構成を説明するための例です。使用する際は、現在のネットワークから実際に到達可能なDNSアドレスに置き換えてください。

  nameserver-policy:
    '+.home.arpa':
      - 192.168.50.53

既存のrules:にも、最終的なフォールバックルールより前にLAN向けルールを追加してください。以下の2行は、それぞれドメイン名と例示したサブネットを対象にしています。既存のサブスクリプションルールを上書きしたり、設定済みのポリシーグループを削除したりしないでください。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

最後の行は、設定にPROXYという名前のポリシーグループがすでにあることを前提としています。実際の名前は既存の設定に合わせてください。no-resolveは、このIPルールのためだけにドメイン名を積極的に解決するのを避ける指定です。もともと解決できない内部ドメインを利用可能にするものではありません。

企業VPNと.local名は分けて考える

  • 企業VPN：内部DNSへの経路が企業VPNを通ることを確認してください。TUNと企業VPNが同時にルーティングを制御する場合は、サブネットの競合、ルートの優先順位、クライアントが提供するバイパス設定を確認します。
  • 短いホスト名：nasのような名前の解決には、システムの検索ドメインが必要な場合があります。検索ドメインの不足をFake-IPの不具合と誤認しないよう、まず完全修飾名でテストしてください。
  • .local：mDNSでよく使われ、通常はUDP 5353とマルチキャストを利用します。通常のDNSフィルター項目を追加しても、mDNSが使えるようになるわけではありません。LAN内のデバイス検出方式とマルチキャストの経路を確認してください。
  • ネットワークの切り替え：会社や自宅のネットワークを離れると、内部DNSに到達できなくなる場合があります。ドメイン単位で振り分ける範囲を維持し、すべてのDNSクエリを内部サーバーに送らないようにしてください。

ゲームとTUNモードを確認する順序

通常のWebページにアクセスできてもゲームにログインできないからといって、Fake-IPとの互換性が原因とは限りません。ゲームでは、HTTPSによるログイン、対戦時のUDP、ボイスチャット、LAN内デバイスの検出など、複数の通信を使うことがあります。システムプロキシではこれらすべてをカバーできない場合があります。TUNならより多くのIP通信を取り込めますが、権限やルーティング、UDPの出口も必要です。

  1. 接続がカーネルに届いているか確認する。クライアントの接続一覧またはログを開いてからゲームを起動してください。該当する接続がまったく表示されない場合は、フィルターリストではなく、まず通信の取り込み方法を確認します。
  2. ログインと対戦を分けて確認する。ログインに失敗する場合は認証ドメインを記録してください。ルーム参加後に切断される場合は、UDP、出口のポリシー、NATの動作を確認します。原因となる通信経路はそれぞれ異なる可能性があります。
  3. 実アドレスが必要か確認する。特定のドメインに合成アドレスが割り当てられた後に失敗しているとログから分かる場合は、そのドメインだけをフィルターリストに追加し、出口などほかの条件を変えずに再テストしてください。
  4. 最後にモードを比較する。一時的にredir-hostへ切り替え、設定を再読み込みしてキャッシュを消去します。同じネットワーク、同じ出口で比較して初めて、モードの互換性を判断する手掛かりになります。

TUNを使う場合は、DNSハイジャック設定で実際のクエリを取り込めているか確認してください。一般的なDNSは53番ポートを使用しますが、ブラウザーのDoHはHTTPSの443番ポートを通ることがよくあります。53番ポートだけを制御しても、暗号化DNSをすべて捕捉できるわけではありません。テストが必要な場合は、ブラウザーのセキュアDNSを一時的にオフにし、元の設定を記録しておき、テスト後に必要に応じて戻してください。

動作確認と元に戻す手順

まずカーネルDNSを確認し、次にシステムからの接続を確認する

前述のローカル1053番ポートの例を使っている場合は、digをインストールしたmacOSまたはLinux環境で以下のコマンドを実行してください。1つ目は一般的なドメイン名に合成アドレスが返るか、2つ目は内部ドメイン名に適切なDNSから実アドレスが返るかを確認します。内部ドメイン名には、現在のネットワークに実在するレコードを指定してください。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

これらのコマンドは指定したポートへ直接問い合わせるため、カーネルDNSの応答は確認できますが、システムやブラウザーもそのDNSを使っていることまでは証明できません。次に実際のアプリから接続し、クライアントのログでドメイン名、接続先アドレス、一致したルール、出口を確認してください。直接問い合わせは正常なのにブラウザーの動作が異なる場合は、ブラウザーのDNS、システムキャッシュ、アプリのキャッシュを優先して確認します。

モード切り替え後は古い状態を消去する

  • 現在の設定をバックアップし、DNSモードまたはフィルター項目を一度に1つだけ変更します。
  • 設定を再読み込みします。クライアントにDNSキャッシュまたはFake-IPマッピングの消去機能がある場合は、画面の操作に従って実行してください。
  • Windowsではipconfig /flushdnsを実行して、システムのDNSキャッシュを消去できます。
  • macOSではsudo dscacheutil -flushcacheを実行し、続けてsudo killall -HUP mDNSResponderを実行します。これらの操作でブラウザー独自のキャッシュまで消去できるとは限りません。
  • 影響を受けたアプリを完全に終了して再起動し、古い接続やアドレスが比較結果に影響しないようにします。

普段からドメインルールで通信を振り分け、接続がすべてカーネルを経由する環境なら、まずはFake-IPを使う方法があります。一部の内部ネットワークやアプリで互換性の問題が起きた場合は、ドメイン単位で例外を追加し、適切なリゾルバーを設定してください。アプリが実IPを継続的に必要とする場合、例外の管理が難しい場合、または比較テストでモードの違いが原因と確認できた場合に、全体をredir-hostに切り替えることを検討します。

通信の取り込み経路をさらに確認するには、接続確認の手順をご覧ください。DNS、ルール、メンテナンス設定を切り分けるには、DNS設定の解説をご参照ください。確認すべきなのは、クエリの送信先、返された内容、そして最終的に接続を処理した出口です。