ルーター・バイパスルーターでV2Rayコアを動かす方法｜ハードウェア選び、透過プロキシ、DNS振り分け

1. ハードウェア選び：アーキテクチャを確認し、使えるメモリを見積もる

V2Rayはプロジェクトやツール群で広く使われる名称です。導入時には、実際に動かすのがV2Flyのv2ray-coreかXray-coreかを確認しましょう。v2rayNはデスクトップ向けGUIクライアント、v2rayNGとv2flyNGはAndroid向けクライアントです。ルーターではコアを直接動かすため、これらのGUIクライアントをインストールする必要はありません。また、クライアントのインストーラーをルーター用の実行ファイルとして使うこともできません。

CPUアーキテクチャによって実行できるプログラムが異なります。よく使われるのはx86_64、aarch64、32ビットARM、MIPSです。MIPSではビッグエンディアンかリトルエンディアンかも確認してください。CPUが64ビット対応でも、ファームウェアのユーザー空間が64ビットとは限りません。パッケージ選びでは、ファームウェアのパッケージソースに記載されたアーキテクチャと、コアのリリース情報を確認しましょう。導入前に端末で以下の情報を調べてください。

uname -m
cat /etc/openwrt_release
free -m
df -h

/etc/openwrt_releaseはOpenWrt専用です。一般的なLinuxでは/etc/os-releaseを確認してください。見るべきなのは搭載メモリの総量だけではなく、実際に使えるメモリと書き込み可能なストレージ容量です。ルールデータ、DNSキャッシュ、接続数、ログによってリソース使用量は増えます。コアが起動しても、高負荷時に安定するとは限りません。

• CPU：コア数が同じでも、プロキシのスループットが同じとは限りません。単一コアの負荷が上限に近づいていないか確認し、プロキシ通信と通常の転送を分けて見ましょう。
• ストレージ：コア、geosite／geoipデータ、更新時の一時ファイルを保存できる容量があるか確認してください。容量の小さいフラッシュストレージに、頻繁に出力されるデバッグログを長期間保存するのは避けましょう。
• ネットワークポート：1ポートの機器でもバイパスルーターを構成できますが、ネットワーク設計がより重要になります。2ポートなら入口と出口を分けやすくなりますが、ポリシールーティングの誤りが自動的に解決するわけではありません。
• システム：必要なカーネルモジュールやパッケージがファームウェアで提供されているか確認してください。ユーザー空間のプログラムがあっても、TPROXYやTUNが利用できるとは限りません。

2. コア選び：ノード設定とファームウェアの対応状況を確認

まずノードに必要な機能を確認し、次にファームウェアで安定して管理できるコアを選びます。プロトコル、セキュリティ機能、伝送方式はそれぞれ別の要素です。VLESS自体に通信内容の暗号化機能はなく、REALITYは関連するセキュリティ機構、WebSocketは伝送方式です。サブスクリプションに「V2Ray」と書かれているだけで、2種類のコアですべての設定項目を相互利用できると判断しないでください。

サブスクリプションは通常、ノード情報を取得するためのもので、そのまま起動できる完全なゲートウェイ設定とは限りません。共有リンクやBase64形式のノード一覧は、対応する管理ツールで読み込み、受信設定、送信設定、ルーティング、DNS設定を生成する必要があります。コアを直接動かす場合は、対応する形式の設定ファイルを用意してください。サービス名、ファイルの保存先、更新方法はファームウェアのパッケージによって異なるため、推測で設定しないようにしましょう。

3. メインルーターとバイパスルーター：機器の名称より通信経路が重要

メインルーターは通常、PPPoE接続、DHCP、NAT、ファイアウォールを担います。ここでプロキシコアも動かせば、統一された転送経路で通信を処理できます。一方、バイパスルーターは通常インターネット接続を直接確立しないため、対象端末の通信が実際に経由するよう設定する必要があります。同じLANに機器を接続しただけでは、ほかの端末の通信は自動的にバイパスルーターへ流れません。

例として、メインルーターを192.168.10.1、バイパスルーターを192.168.10.2、テスト端末を192.168.10.100とします。テスト端末のデフォルトゲートウェイは192.168.10.2、バイパスルーターのデフォルトゲートウェイは192.168.10.1に設定します。これはIPv4の構成例です。実際のネットワークに合わせてアドレスを変更し、バイパスルーターのアドレスが、重複して割り当てられる可能性のあるDHCPアドレスプールに含まれないようにしてください。

1. バイパスルーターには固定アドレスを設定するか、DHCP固定割り当てを利用し、再起動後もアドレスが変わらないようにします。
2. テスト端末のゲートウェイを手動で設定し、DNSにはクエリを処理させる予定のローカルリゾルバーを指定します。
3. バイパスルーターでIP転送が有効になっていること、必要な転送がファイアウォールで許可されていること、戻り通信が正しく処理されることを確認します。
4. 通常接続とプロキシ接続の両方をテストしてから、DHCPで配布するゲートウェイ設定を変更してください。DHCPサーバーを2つ同時に有効にして、アドレス割り当てが競合しないようにしましょう。

4. 透過プロキシ方式：REDIRECT、TPROXY、TUNの選び方

透過プロキシは、ゲートウェイが接続を取り込む方式であり、ノードのプロトコルではありません。明示的なSOCKSプロキシでは、アプリがプロキシのポートへ接続します。透過プロキシでは、ファイアウォール、ポリシールーティング、仮想ネットワークインターフェースを使って通信をコアに渡します。問題を2つ同時に切り分けずに済むよう、まず明示的なプロキシ接続を確認してから透過処理を設定しましょう。

TPROXYを例にすると、まずファイアウォールで対象通信にマークを付け、その接続を透過受信に渡します。ポリシールーティングでは、マーク付きのパケットをローカルの処理経路へ送ります。どれか1つでも欠けると、「ルールのカウンターは増えるのに接続ログが出ない」ことがあります。透過受信ポートは12345などを使用できます。アプリのテストに使う10808とは役割が異なり、ポート番号を変更するだけでは通信を取り込めません。

• 最初に除外：ルーターの管理用アドレス、必要なLAN内の宛先、ノードサーバーのアドレス、コア自身が開始する接続を除外し、プロキシのループを防ぎます。
• 通信経路を区別：端末から転送される通信とルーター自身が発生させる通信では、入口となるチェーンが異なります。端末の通信を取り込めても、サブスクリプションの更新通信が同じ経路を通るとは限りません。
• バックエンドを確認：OpenWrt 22.03以降では、firewall4とnftablesの組み合わせが標準的です。古いファームウェアではfirewall3とiptablesが使われることがあり、ルールを機械的に混在させることはできません。
• 管理経路を確保：ルールは繰り返し読み込んでも重複せず、明確な解除手段がある状態にしてください。リモートで変更する前に、別の管理接続を確保しましょう。

UDP通信の取り込みに成功しても、すべてのUDPアプリが使えるとは限りません。ノードの送信側、サーバー、中継ネットワークが対象の通信に対応している必要があります。ウェブ閲覧はできても通話やゲームが失敗する場合は、UDPのログとルールを個別に確認してください。ハードウェアオフロードによってソフトウェア側のルールを通る経路が変わることもあります。診断時は一度オフロードを無効にし、ルールのカウンターと接続状況を比較しましょう。

5. DNS振り分け：名前解決の経路と接続の経路を連携

DNS振り分けでは、少なくとも3つの経路を考える必要があります。端末が問い合わせを送る先、ローカルリゾルバーが選ぶ上流サーバー、そして上流サーバーへ問い合わせる際に使う通信経路です。バイパスルーターのDNSアドレスを指定するだけで解決するのは最初の段階です。上流への問い合わせが適切でない経路を通ると、誤った結果が返ったり、タイムアウトが続いたりすることがあります。

よくある構成では、ルーター上のdnsmasqをDHCP、LAN内の名前解決、キャッシュに使い、ルールに応じて一部の問い合わせを専用のリゾルバー入口やコアのDNSへ転送します。コアのdns設定を有効にしても、LAN向けのDNSサービスポートが自動で開くわけではありません。実際に利用する受信設定やDNS転送の仕組みも設定してください。

1. 上流の経路を1つにする：端末 → dnsmasq → 指定したリゾルバー入口 → 上流サーバー。同じ種類の問い合わせをdnsmasqとコアのDNS間で相互転送しないようにします。
2. ローカルの名前解決を維持：LAN内のホスト名や内部ドメインは、該当するレコードを把握しているリゾルバーに問い合わせます。すべての問い合わせをパブリックDNSへ送るのは避けてください。
3. ノードのドメイン名解決を考慮：プロキシ接続を確立する前に、ノードサーバーのドメイン名を解決する必要がある場合があります。この名前解決を、まだ確立されていないプロキシ接続に依存させないでください。
4. IPv6を確認：DHCPv6、ルーター広告、AAAAレコードの問い合わせ先を確認し、IPv6の接続ポリシーと名前解決の結果が一致するようにします。

dnsmasqがLAN側でポート53を待ち受けているとします。別のリゾルバー入口は、対応状況を確認したうえで127.0.0.1:5353にバインドし、dnsmasqから対象の問い合わせを転送できます。5353はmDNSにもよく使われるため、使用前にポートの競合を確認してください。同じアドレスとポートを複数のサービスで共有することはできません。外部向けの入口を公開する場合は、WAN側から利用されないようファイアウォールで接続元を制限し、オープンリゾルバー化を防いでください。

ドメインベースのルーティングとIPベースのルーティングは分けて考える必要があります。透過接続がコアに届いた時点で、分かるのは宛先IPだけの場合があります。対応プロトコルではスニッフィングによってドメイン名を取得できますが、すべての通信で利用できるわけではありません。geositeはドメイン分類、geoipはIPアドレス分類に使い、どちらも対応するデータファイルが必要です。ルーティングルールは通常、記載順に評価されます。domainStrategyはルーティング時にIPルール用のドメイン名解決を行うかどうかを指定するもので、端末のDNS設定を置き換えるものではありません。

6. 導入後の確認：1台から始め、対象を段階的に拡大

設定の確認では、「コアが動作する」「ノードに接続できる」「端末の通信が取り込まれる」「DNSの結果が想定どおり」の4点を分けて検証します。一度の作業でファームウェアの更新、コアの入れ替え、ゲートウェイの変更、新しいルールの読み込みを同時に行うと、ログから原因を特定しにくくなります。

1. バックアップ：ネットワーク、ファイアウォール、DHCP、コアの設定を保存し、メインルーターの管理用アドレスと通常接続へ戻す方法を記録します。
2. 設定をテスト：Xrayでは以下のコマンドで設定を検証できます。V2Flyのコマンドライン引数は、現在のバージョンのヘルプ出力を確認し、Xrayのコマンドをそのまま流用しないでください。
3. 明示的なプロキシをテスト：テスト用アプリだけをSOCKSの入口に接続し、ノードへの接続、時刻、証明書の設定が正しいことを確認します。
4. 透過処理をテスト：テスト端末だけを対象にし、ファイアウォールのカウンター、コアのアクセスログ、実際の通信出口を確認します。TCPと、必要なUDPアプリをそれぞれテストしてください。
5. 継続して状態を確認：アイドル時、ダウンロード時、複数端末でアクセスしたときの空きメモリ、CPU、温度、エラーログを確認してから、対象端末を増やします。

# 設定ファイルのパスはこの記事の例です。実際のインストール先に合わせて変更してください
xray run -test -config /etc/xray/config.json

# 以下のコマンドは、必要なツールがインストールされたLinux環境で実行します
ip route
ip -6 route
ip rule
ss -lnptu
nft list ruleset

# DNS問い合わせの例：実際にDNSを処理する機器のアドレスに変更してください
nslookup example.com 192.168.10.2

一部の軽量ファームウェアでは、ssなどの診断ツールを別途インストールする必要があります。コマンドが見つからなくても、サービスの障害とは限りません。ログを共有する前に、サブスクリプションのURL、認証情報、ノードの接続情報を隠してください。問題の特定のために詳細ログを一時的に有効にした場合は、確認後にログレベルを下げ、ストレージへの書き込みやアクセス記録の露出を防ぎましょう。