ルーター・バイパスルーターへのXray/V2Ray導入ガイド：構成選びと設定のポイント

1. 構成を選ぶ：メインルーターかバイパスルーターか

XrayとV2Rayはプロキシカーネルであり、ルーターOSそのものではありません。カーネルの実行に加え、OS側でパケット転送、ファイアウォールによる通信制御、サービス管理を行う必要があります。ファームウェアの管理画面で設定を生成できても、画面の選択肢、ルールファイル、実際に動作するカーネルのバージョンが対応しているか確認してください。「起動中」と表示されているだけでは判断できません。

ノードの要件に合わせてカーネルを選びます。XrayとV2Flyが開発するV2Rayでは、プロトコル、トランスポート、設定項目に違いがあります。特にREALITYなど特定の機能を含む設定を、非対応のカーネルでそのまま使わないでください。v2rayNはデスクトップクライアント、v2rayNGとv2flyNGはAndroidクライアントです。ノードの動作確認には使えますが、ルーター上のパケット転送サービスではありません。

2. アドレス設計：ゲートウェイ、DNS、戻り経路を個別に確認

以下は説明用の固定アドレス例で、すべてのネットワークに共通する初期値ではありません。導入前に実際のサブネット、DHCPアドレスプール、既存端末を確認し、アドレスの重複を避けてください。バイパスルーターのアドレスは固定し、動的割り当て範囲から除外するか、メインルーターで固定リースを設定します。

同一セグメント上にあるシングルNICのバイパスルーターでは、直接接続する通信がバイパスルーターからメインルーターへ転送され、メインルーターから端末へ直接戻る非対称経路が発生することがあります。ファイアウォールのコネクション追跡を踏まえ、制御された送信元NATを使うか、経路が対称になるようトポロジーを調整してください。ICMPリダイレクトによって端末がバイパスルーターを迂回していないかも確認します。あらゆる問題に「NATを有効にする」だけで対処できるわけではありません。

3. 透過プロキシ：カーネルの待ち受けだけでは通信を制御できない

明示プロキシでは、アプリ側からHTTPまたはSOCKSのプロキシポートへ接続します。一方、透過プロキシではゲートウェイが条件に合う通信を捕捉し、宛先情報をルーティング判断に利用できる状態でカーネルへ渡します。SOCKSのインバウンドを設定しただけでは、端末のゲートウェイをバイパスルーターに変更しても、通常のアプリ通信が自動的にそのインバウンドへ流れることはありません。

1. まずアウトバウンドを確認：同じノードをクライアントで使い、基本的な接続が可能か確認します。次にルーターの時刻、証明書検証、サーバードメインの名前解決、接続ログを確認してください。デスクトップで使えても、ルーターのネットワーク条件が同じとは限りません。
2. 次にインバウンドを確認：待ち受けアドレス、プロトコル、ポートを確認し、ファイアウォールの通信が明示プロキシ用ポートではなく、正しい透過プロキシ用インバウンドに渡されていることを確かめます。
3. 最後に通信を捕捉：まずテスト端末の送信元アドレスだけを対象にし、範囲を段階的に広げます。TPROXYには対応するポリシールーティングが必要です。ルーティング設定を伴わないファイアウォールルールだけでは、通信が途切れることがあります。
4. プロキシのループを防止：カーネル自身が確立するアウトバウンド接続を、再度プロキシの対象にしないでください。専用マーク、プロセス識別、宛先アドレスの除外などを使います。具体的な方法は導入構成に合わせて選んでください。

LAN内の管理用アドレス、ブロードキャスト、マルチキャスト、その他直接接続が必要なネットワークは、ファイアウォールでの捕捉とカーネルのルーティングの両方で考慮します。ノードサーバーのIPを除外するルールでは、ドメインの名前解決結果が変わる可能性にも注意してください。nftablesベースのファイアウォール環境で、古いiptablesスクリプトをそのまま重ねて実行しないでください。二重の捕捉やルールの順序ミスは、原因の特定を難しくします。

4. DNSの振り分け：ポート、ルール、起動時の名前解決を一貫させる

DNSの振り分けは、端末からの問い合わせ、ルーター内での転送、上流DNSでの名前解決の3段階で構成されます。端末のDNSをバイパスルーターに指定しても、その設定に従う問い合わせしか制御できません。アプリ内蔵の暗号化DNSは、通常の53番ポートを捕捉しただけでは自動的に指定したリゾルバーへ切り替わらないため、ブラウザーやアプリの設定も個別に確認してください。

• 待ち受けポート：通常のDNSサービスではUDP/TCPの53番ポートを使います。システムの名前解決サービスが53番ポートを使用中なら、別のDNSコンポーネントをローカルの5353番ポートで待ち受けさせ、前者から転送する方法があります。これらは構成例のポート番号です。実際の待ち受け設定に合わせてください。
• ドメインごとの振り分け：直接接続するドメインとプロキシ経由にするドメインに適切な上流DNSを割り当て、上流への通信が意図したアウトバウンドを通ることを確認します。上流アドレスをパブリックDNSに変えただけでは、問い合わせがプロキシ経由になったとは証明できません。
• 起動時の名前解決：ノードサーバーのアドレスがドメイン名の場合、先に利用可能な名前解決経路が必要です。まだ確立していないプロキシ接続だけにノードの名前解決を依存させないでください。
• ループを防止：ローカルDNSからカーネルへ転送した問い合わせを、カーネルが同じローカルの入口へ送り返さないようにします。各転送先のアドレス、ポート、アウトバウンドタグを確認してください。
• ドメインとIPアドレスの照合：domainStrategyは、ルーティング判断時にドメイン名を解決するか、またそのタイミングを決める設定です。システム上のすべてのDNS問い合わせを捕捉する設定ではありません。値と動作は使用するカーネルのバージョンに合わせて確認してください。

geositeやgeoipなどのルールリソースを使う場合は、リソースファイルと設定内の参照先が一致していること、更新が正常に完了していることも確認します。スニッフィングは一部の接続でドメイン情報の補完に役立ちますが、すべての通信を識別できるわけではなく、DNS経路の設計に代わるものでもありません。振り分けのテストでは、ドメインのルール一致ログと実際のアウトバウンドタグを両方確認してください。

# digをインストールしたテスト端末で実行。ドメイン名は接続テスト用
dig @192.168.10.2 example.com A
dig @192.168.10.2 example.com AAAA
dig @192.168.10.2 example.com A +tcp

この3つの問い合わせで、IPv4レコード、IPv6レコード、TCP経由のDNSをそれぞれ確認できます。応答が返ってきても、DNSサービスが応答したことしか分かりません。どの上流へ問い合わせ、どの経路を通ったかを確認するには、ルーターのログや対象を絞ったパケットキャプチャも必要です。DNS設定の変更後は、端末とルーターのキャッシュを消去して、古い応答が変更内容を隠さないようにします。

5. 導入手順：まず1台で検証し、その後DHCPで配布

ルーターの設定は、デスクトップからエクスポートしたファイルをそのままコピーすればよいわけではありません。待ち受けアドレス、ファイルパス、ユーザー権限、リソースファイルの配置、透過プロキシ用インバウンドが異なります。サブスクリプションURLも、そのまま起動できるカーネル設定とは限りません。インポートの可否やアウトバウンドの生成方法は、管理機能の実装によって異なります。

1. 現在の状態を記録：ネットワーク、DHCP、ファイアウォールの設定をバックアップし、メインルーターの管理アドレスを記録します。元のゲートウェイを使って、テスト端末からドメインを解決できること、WebサイトとLAN内の端末にアクセスできることを確認してください。
2. 実行環境を確認：CPUアーキテクチャに合ったカーネルを選び、システム時刻、書き込み可能なストレージ、サービスの権限を確認します。ルールリソースや接続数はメモリー使用量に影響するため、インストールパッケージのサイズだけで実行要件を判断しないでください。
3. カーネルを単独で起動：まず設定の構文と起動ログを確認し、その後ノードへの接続を検証します。設定の検証コマンドはディストリビューションのバージョンによって異なることがあるため、付属のヘルプを先に確認してください。
4. テスト対象を限定：192.168.10.100だけにゲートウェイとDNSを設定し、この送信元アドレスの通信のみを捕捉します。直接接続するサイト、プロキシ経由のサイト、LAN内サービスをそれぞれテストしてください。
5. 障害時の動作を決める：ノードが利用できない場合に通信を遮断するのか、特定の通信は直接接続させるのかを明確にします。DNS障害、カーネル停止、端末再起動もテストし、正常時だけで判断しないでください。
6. 最後に対象端末を拡大：動作が安定してからDHCPを変更します。OpenWrtのLuCI画面では通常、「ネットワーク」→「インターフェース」→「LAN」→「DHCPサーバー」で配布設定を確認できます。項目名はバージョンによって異なります。既存の端末で新しい設定を使うには、リースを再取得する必要があります。

6. 動作確認とトラブル対処：出口のIPだけでなく経路を確認

出口IPの変化から分かるのは、特定のリクエストがある経路を通ったことだけです。DNS、UDP、IPv6、すべてのアプリ通信が正しく振り分けられている証拠にはなりません。正常時と障害時の両方を記録し、端末、ゲートウェイ、DNS、カーネルのアウトバウンドを分けて確認してください。

# Linuxルーターで実行。確認に必要な権限が必要です
ip -4 route
ip -6 route
ip rule show
ss -lntup

上記のコマンドでは、IPv4ルート、IPv6ルート、ポリシールーティングのルール、待ち受けポートを確認できます。最小構成のシステムでは、該当ツールを別途インストールする場合があります。アドレス設計と照らし合わせて確認し、出力にポートが表示されたというだけで導入完了と判断しないでください。ログにサブスクリプションURL、認証情報、端末識別情報が含まれる場合は、共有前に削除してください。