ルーター・バイパスルーターでV2Rayコアを動かす方法｜透過プロキシと必要なハードウェア

1. 設置場所：メインルーターとバイパスルーターの役割

メインルーターは通常、インターネット接続、DHCPによるIPアドレス配布、NAT、ファイアウォールを担当します。ここでコアを動かせば、転送経路全体を制御しやすくなりますが、プロキシの更新、ルール設定ミス、リソース不足が発生すると、LAN全体に影響するおそれがあります。バイパスルーターは追加の中継機器です。まず一部の端末だけでゲートウェイとして使えば、試験範囲を限定できます。

この記事では、LANポート1つのバイパスルーターを例にします。メインルーターは192.168.10.1/24、バイパスルーターは192.168.10.2/24、テスト端末は192.168.10.100/24です。実際のネットワークに合わせてアドレスを変更し、バイパスルーターのアドレスはDHCPの動的割り当て範囲から除外してください。これらは設定例であり、機器の初期設定値ではありません。

テスト端末 192.168.10.100
  デフォルトゲートウェイ → バイパスルーター 192.168.10.2
                ├─ 直接接続のアウトバウンド → メインルーター 192.168.10.1 → インターネット
                └─ プロキシのアウトバウンド → メインルーター 192.168.10.1 → リモートノード

バイパスルーター自身のデフォルトゲートウェイ：192.168.10.1
メインルーター自身のデフォルトゲートウェイ：プロバイダー側の上位ルーター

2. コアの選び方：プロトコル、アーキテクチャ、設定形式を確認

XrayとV2Flyはそれぞれ単独で動作するプロキシコアであり、ルーターのOSではありません。v2rayN、v2rayNG、v2flyNGはクライアントのUIです。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。ルーターへの導入では、デスクトップクライアントではなく、対応するLinux用プログラム、設定ファイル、サービスの起動方法を確認してください。

• CPUアーキテクチャを確認：uname -mを実行し、ファームウェアのパッケージアーキテクチャ、ビット数、実行環境を照合します。機器の仕様に「ARM」とあるだけでプログラムを選ばないでください。
• ノードのプロトコルを確認：VMessまたはVLESS、トランスポート方式、TLSパラメーター、サーバー側の要件を個別に確認します。ノードがREALITYを使う場合は、該当する設定に対応していると明記されたXrayビルドを選んでください。2つのコアで設定項目をそのまま共用できるとは限りません。
• 設定形式とバージョンを確認：V2Flyはバージョンによって設定形式が異なり、Xrayの設定項目も更新されています。実際に機器へインストールしたバージョンに合わせて設定を確認し、別のコアのJSONを丸ごとコピーしないでください。
• サブスクリプションの処理を確認：サブスクリプションURLを指定するだけで、コアの設定が自動更新されるわけではありません。通常は管理パネルや管理スクリプトがサブスクリプションの解析、設定の生成、更新のスケジュール、サービスの再読み込みを担当します。コアだけで運用する場合は、これらの処理を別途用意してください。

3. 透過プロキシ：待ち受けポートだけでなくポリシールーティングも必要

明示的プロキシでは、アプリがHTTPまたはSOCKSの待ち受けポートに接続します。透過プロキシでは、ゲートウェイが転送経路上の接続を捕捉し、コアへ渡します。ポートを待ち受けるだけでは、LANのトラフィックを自動で取り込むことも、戻りの通信経路を確立することもできません。Linuxのファイアウォールルール、ポリシールーティング、コアのインバウンド設定を対応させる必要があります。

上記のポートとルーティングテーブル番号は設計例であり、管理画面の初期設定値ではありません。ルーティングテーブル番号100を使う前に、他のサービスが使用していないことも確認してください。透過インバウンドでは、使用するコアが必要とする透過ソケットのオプションを有効にし、ファイアウォールからトラフィックを渡す方法と一致させる必要があります。

firewall4を使うOpenWrt環境では通常、nftablesでルールを管理します。古い資料にあるiptablesコマンドがそのまま使えるとは限りません。TPROXYでは一般に、トラフィックにマークを付け、ip ruleで専用のルーティングテーブルを選択し、ローカルルートから透過ソケットへ転送します。マーク値とマスクは、マルチWANや既存のポリシールーティングサービスと重複しないようにしてください。

• ループバック、マルチキャスト、ブロードキャスト、LAN内の管理用ネットワーク、およびバイパスルーター自身が直接通信する必要のあるトラフィックは除外します。
• ノードサーバーのアドレスとコア自身のアウトバウンド通信を除外し、「プロキシ接続が再びプロキシに入る」ループを防ぎます。
• LANから転送されるトラフィックと、ルーター自身が発信するトラフィックを分けて処理します。PREROUTINGルールだけでは、ルーター自身の接続をすべて取り込めません。
• ソフトウェアまたはハードウェアのフローオフロードが想定したルール経路を迂回していないか確認します。検証中は該当するオフロードを無効にして比較してください。

4. ゲートウェイとDNS：まず1台の端末で変更してから範囲を広げる

バイパスルーターに共通の設定画面はありません。以下では一般的なOpenWrtのLuCIメニューを例にしますが、項目名はバージョンによって異なる場合があります。操作前に設定をエクスポートし、メインルーターの管理アドレスを控えてください。代替の管理経路を確保できていない状態で、管理IP、DHCP、ファイアウォールを同時に変更しないでください。

1. 管理用の固定アドレスを設定

   バイパスルーターで「ネットワーク」→「インターフェース」→「LAN」→「編集」→「基本設定」を開き、静的アドレスを192.168.10.2、ネットマスクを255.255.255.0に設定します。上位のIPv4ゲートウェイには192.168.10.1を入力してください。

2. DHCPサーバーは1台に限定

   アドレスの配布はメインルーターに任せます。バイパスルーターで「ネットワーク」→「インターフェース」→「LAN」→「編集」→「DHCPサーバー」→「一般設定」を開き、「このインターフェースを無視する」にチェックを入れてください。2台の機器が競合する設定を同時に配布するのを防げます。

3. 1台の端末だけゲートウェイを変更

   テスト端末のIPv4設定では、現在のアドレスとネットマスクを維持し、ゲートウェイだけを192.168.10.2に変更します。バイパスルーターでIPv4転送が有効になっていることと、対応するファイアウォールで必要な転送方向が許可されていることを確認してください。

4. DNSの経路を確認

   バイパスルーターでDNSサービスが利用できることを確認してから、テスト端末のDNSを192.168.10.2に設定します。UDP/TCPの53番ポート、上流DNSへの経路、プロキシの起動前にノードサーバーのドメイン名を解決できるかをそれぞれ確認してください。

5. 対象を広げて検証

   1台で安定動作したら、メインルーターもLuCIを使っている場合は、「ネットワーク」→「インターフェース」→「LAN」→「編集」→「DHCPサーバー」→「詳細設定」のDHCPオプションに3,192.168.10.2を設定できます。DNSも同時に配布する場合は6,192.168.10.2を設定し、その後、端末でリースを更新してください。

同一サブネットでLANポートが1つのバイパスルーターでは、経路が非対称になることがあります。端末からの直接接続トラフィックはバイパスルーターを経由しても、メインルーターからの戻り通信は端末へ直接届く場合があります。これにより、コネクショントラッキング、統計情報、ファイアウォールの判定に影響する可能性があります。転送トラフィックにソースNATを適用するかどうかは、ネットワーク構成に合わせて検証してください。ソースNATを使うと戻り経路を制御しやすくなりますが、元の端末アドレスは隠れるため、すべてのネットワークに適した方法とは限りません。

5. ハードウェア：LANポートの速度ではなく、想定する負荷で測定

ギガビットLANポートが示すのはリンク速度であり、暗号化プロキシも同じ速度で動作するとは限りません。CPUのシングルスレッド性能、プロトコルとトランスポートの組み合わせ、メモリ負荷、冷却性能、ノードの回線状況がスループットを左右します。小型ルーターではWi-Fi、コネクショントラッキング、ファイアウォール用のリソースも確保してください。バイパスルーターでは、NICドライバーと仮想化によるオーバーヘッドも確認が必要です。

同じ有線端末、同じノード、同じダウンロード先を使い、直接接続、端末クライアント経由、バイパスルーター経由の3パターンを順番に測定します。各パターンを3回繰り返し、スループット、遅延、CPU、メモリを記録してください。ノード自体の速度が大きく変動する場合、その差をすべてバイパスルーターの性能に起因すると判断することはできません。これは測定方法の説明であり、特定機種の性能を保証するものではありません。

6. トラブル対処の順序：アドレス、転送、インバウンド、アウトバウンドを順に確認

「バイパスルーターの管理画面が開ける」ことから分かるのは、LAN内のアドレスに到達できることだけです。インターネットへの転送やプロキシのアウトバウンドが正常とは限りません。まずバイパスルーターのデフォルトルートを確認し、次に透過プロキシのインバウンドにトラフィックが届いているかを調べます。最後に接続ログを見て、ルーティングルールがどのアウトバウンドを選択したか確認してください。デバッグログには接続先のドメイン名やアドレスが含まれる場合があります。調査後は通常のログレベルに戻し、ログローテーションを設定してください。

# 以下は読み取り専用の確認コマンドです。一部の軽量ファームウェアでは、先に必要なツールをインストールしてください。
ip -4 addr show
ip -4 route show
ip -4 rule show
ip -4 route show table 100
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset
free
df -h

ip -4 route show table 100が使えるのは、この記事の例と同じテーブル番号を採用している場合に限られます。管理サービスが別のルーティングテーブルを使っている場合は、実際の番号を確認してください。ssでポートとプロセスを確認できますが、待ち受け状態だけでは透過プロキシのルールが正しいか判断できません。nftの出力を確認するときは、既存のルールセットとマッチした件数に注目してください。「干渉を除外する」ためにファイアウォール全体を消去しないでください。

7. 本番運用と切り戻し：ゲートウェイ設定も保守対象に含める

バイパスルーターの安定運用には、設定ファイルだけでなく、起動順序と失敗時の処理も重要です。時刻未同期、DNSの準備未完了、ルールのダウンロード失敗などにより、起動時にサービスが正常動作しないことがあります。自動更新では、新しい設定を検証してから現在のファイルと置き換えてください。プロセスが存在することだけを、ネットワーク経路が正常である根拠にしないでください。

• 復元可能な設定を保存：ネットワーク、ファイアウォール、DNS、コアの設定を個別にバックアップし、使用中の待ち受けポート、マーク、ルーティングテーブル番号を記録します。
• コールドスタートを検証：再起動後にアドレスの割り当て、ノードのドメイン名解決、直接接続とプロキシ経由の両方を確認し、管理画面にも引き続きアクセスできることを確かめます。
• 管理アクセスの範囲を限定：管理画面とプロキシの待ち受けポートは必要なLAN内だけに公開し、認証のないプロキシポートをインターネットに公開しないでください。
• 切り戻し手順を決める：まず端末またはDHCPで配布するゲートウェイとDNSを元に戻し、その後、トラフィック取り込みルール、ポリシールーティング、サービスを解除します。コアだけを停止して取り込みルールを残すと、待ち受けていないポートへトラフィックが転送されるおそれがあります。

プロキシを使う端末が1～2台だけなら、端末のクライアントを使う方が管理しやすいのが一般的です。LAN全体のトラフィックをまとめて処理する必要がある場合は、1台での試験、DNSの検証、UDPとIPv6の確認、ネットワーク全体への展開の順に進めてください。各パラメーターの意味は用語集を、対象範囲とルーティングによる振り分けの違いは利用ガイドを参照してください。