ルーターと旁路ルーターでV2Rayコアを直接動かす：OpenWrt導入の要点とトラフィック制御

まずメインルーターか旁路ルーターかを判断する

ルーターでV2Rayを動かす際の要点は、実行ファイルをコピーすることではなく、LAN機器のデフォルトゲートウェイ、DNS、ファイアウォールを誰が担当するかを決めることです。メインルーター構成では、1台のOpenWrtが接続、NAT、DHCP、DNS、透過プロキシをまとめて担います。経路は短い一方、設定ミスが家庭内ネットワーク全体に影響します。旁路ルーター構成では既存のメインルーターを残し、指定した機器だけゲートウェイとDNSをOpenWrtへ向けます。変更範囲が小さく、初回検証に向いています。

旁路ルーターだからといって、自動的に「経路外で監視できる」わけではありません。端末のデフォルトゲートウェイが元のメインルーターのままで、OpenWrtが実際の転送経路に入っていなければ、制御対象のパケットは見えません。最も明確な方法は、テスト端末で旁路ルーターのアドレスを手動設定することです。たとえばメインルーターが192.168.1.1、旁路ルーターが192.168.1.2なら、テスト端末のゲートウェイとDNSをともに192.168.1.2へ設定します。検証後は、メインルーターのDHCPで機器ごとに配布できます。

ハードウェア、システム、ディレクトリの準備

コアはルーターのCPUアーキテクチャに一致している必要があります。代表的なアーキテクチャにはarm64、armv7、mips、x86_64があります。機器のブランドだけで判断しないでください。ubus call system boardでシステム情報を確認し、uname -mでカーネルが報告するアーキテクチャを確かめます。ファイルのアップロード後にnot foundと表示される場合、実際にファイルが存在していても、まずアーキテクチャと動的リンクの依存関係を確認します。

プログラム、設定、実行データは分けて管理するのがおすすめです。実行ファイルは/usr/bin/v2ray、メイン設定は/etc/v2ray/config.jsonに置き、ログは必要に応じてシステムログまたは容量に余裕のある永続ディレクトリへ出力します。容量の限られたフラッシュへ詳細なアクセスログを継続的に書き込まないでください。トラブルシューティング時だけログレベルを上げ、安定後はwarningまたはerrorに戻します。

設定ファイル、サービス、起動順序

設定はまずコア内蔵のテストコマンドで検証し、その後サービスマネージャーから起動します。V2Ray 5系のビルドによってコマンド引数が少し異なる場合がありますが、一般的な確認方法はv2ray test -c /etc/v2ray/config.jsonです。現在のビルドがこの引数を認識しない場合は、先にv2ray helpを実行して実際のコマンドを確認してください。構文エラーのままサービスを繰り返し再起動しないでください。

透過プロキシのインバウンドには通常dokodemo-doorを使用し、LANから転送されたTCPとUDPを待ち受けます。以下ではインバウンドの重要部分だけを示します。アウトバウンドのサーバーアドレス、ユーザー識別子、トランスポート層、TLSパラメータは実際のノードに合わせて設定してください。例示のポート12345は、ファイアウォールルールとも一致させる必要があります。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

1. アーキテクチャを確認

   端末でuname -mを実行し、アーキテクチャに一致するV2Rayコアをダウンロードします。OpenWrtに十分な永続ストレージと使用可能メモリがあることも確認してください。

2. ファイルを配置

   プログラムを/usr/bin/v2rayに、設定を/etc/v2ray/config.jsonに置き、続けてchmod 755 /usr/bin/v2rayを実行します。

3. 設定を確認

   まず設定テストコマンドを実行し、次にフォアグラウンドで一度起動してログを確認します。ノードのアウトバウンド接続が成功したことを確認してから、起動時サービスと異常時の再起動ポリシーを設定します。

4. 転送を許可

   OpenWrtの「ネットワーク」→「ファイアウォール」でLANゾーンの転送を確認します。旁路ルーターでは、カーネルの転送パラメータが有効になっていることも確認してください。

5. 1台で試す

   テスト用パソコン1台だけのゲートウェイとDNSを旁路ルーターのアドレスに変更し、ウェブページ、動画、ソフトウェアのダウンロード、UDPを必要とするアプリを個別に検証します。

6. 段階的に移行

   安定して動作してから、「ネットワーク」→「インターフェース」→「LAN」→「DHCPサーバー」でゲートウェイとDNSの配布を調整します。一度に全機器へ影響を与えないようにしてください。

REDIRECTとTPROXYによる2つの制御方式

REDIRECTは、ルーターを通過するTCP接続を本機の待受ポートへリダイレクトする方式です。理解しやすく、ウェブ閲覧や一般的なTCPアプリの初期検証に適していますが、UDPの透過プロキシを完全には処理できません。家庭内機器でリアルタイム通信、一部のDNS通信、UDP依存アプリを扱う場合、最終的には通常TPROXYが必要です。

TPROXYは元の宛先アドレスを直接書き換えず、パケットにマークを付け、ポリシールーティングでマーク済みの通信を本機の透過プロキシポートへ送ります。典型的な組み合わせは、ファイアウォールマーク0x1、ポリシールーティングテーブル100、待受ポート12345です。V2Rayのアウトバウンドソケットにも独立したマークを設定し、制御チェーンから除外する必要があります。そうしないと、コアが発信した接続が再び自身へ入り、ループが発生します。

OpenWrt 23.05以降のシリーズでは、標準でfw4とnftablesが使われます。古い解説にあるiptablesコマンドをnftablesのルールへそのまま混在させると、コマンドは成功してもパケットが想定したチェーンに入らないことがあります。導入時は「ネットワーク」→「ファイアウォール」で現在のバックエンドを確認し、nft list rulesetで実際に読み込まれた結果を確認してください。

ポリシールーティングの基本関係は以下のとおりです。コマンドはマークとルーティングテーブルの対応を示すためのものです。実運用ではインターフェース再接続後も復元できるスクリプトに組み込み、同名のルールがすでに存在しないか確認してください。

ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ip rule show
ip route show table 100

• ルーター自身のLANアドレス、ループバックアドレス、マルチキャストアドレス、予約アドレスを除外し、管理画面やLANサービスがプロキシへ送られないようにします。
• プロキシサーバーの実IPを除外します。除外しないとプロキシトンネルの確立に使う接続が再び透過プロキシルールに一致します。
• まずprerouting経路でLANから転送される通信を制御し、最初からルーターの全output通信を制御しないでください。
• IPv4とIPv6は別々の経路です。IPv6の振り分けを設定していない場合は、直接接続を維持するか、関連する経路をLANへ配布しないかを明確に決めてください。

DNSは通信経路と一緒に設計する

透過プロキシが動作しても、DNSが正しいとは限りません。端末がメインルーターや通信事業者のDNSへ直接問い合わせ続けると、ドメインの振り分けと実際の接続経路が一致しない場合があります。旁路ルーターの検証で、ゲートウェイは192.168.1.2に変更したのにDNSが192.168.1.1のままという状態は、最も一般的な部分的制御です。

V2Ray設定のdnsオブジェクトは、コア内部の名前解決や関連するルーティング処理に使われます。ただし、設定に記述しただけでLAN向けDNSサービスになるわけではありません。LAN内機器に利用させるには、DNSインバウンドを用意するか、dnsmasqからローカルポートへルール転送します。この記事の例では、dnsmasqがLANの53ポートを待ち受け、コアで処理する必要がある問い合わせを127.0.0.1:1053へ転送します。

1. 入口を統一

   dnsmasqのLAN向けUDP/TCP53待受を維持し、端末のDNSにはOpenWrtのLANアドレスを統一して指定します。機器が旁路ルーターを迂回して問い合わせないようにしてください。

2. 転送を設定

   V2RayにローカルDNSインバウンドを設定します。たとえば127.0.0.1:1053で待ち受け、他の名前解決サービスがこのポートを使用していないことを確認します。

3. 経路を分ける

   ローカルドメインとLANホスト名は引き続きdnsmasqで処理し、プロキシ経由の名前解決が必要な問い合わせだけをコアへ転送します。家庭内機器の名前解決が機能しなくなるのを防げます。

4. ループを遮断

   ファイアウォールルールで、ルーターから上流DNSへ向かう接続を除外します。53ポートの問い合わせが透過プロキシルールに繰り返し捕捉されるのを防ぎます。

5. 項目ごとに検証

   まずルーター上で名前解決を実行し、次にテスト端末から同じドメインを問い合わせます。最後に、コアのログとnftablesのカウンターが同時に変化しているか確認します。

よくある障害は経路を区切って調べる

ルーターの透過プロキシには、端末、ゲートウェイ、ファイアウォール、ポリシールーティング、V2Rayインバウンド、V2Rayアウトバウンド、DNSなど複数の要素があります。最も効果的な切り分けは、ノードを頻繁に変更することではなく、端末からアウトバウンドまでを順に確認することです。まず端末からOpenWrtの管理アドレスへアクセスできるか、次にデフォルトゲートウェイとDNSを確認し、その後12345が待ち受けているか、ルールカウンターが増えているか、コアのログに該当する接続が出ているかを確認します。

ルールカウンターが常にゼロなら、問題は通常、端末のゲートウェイ設定またはファイアウォールの制御範囲にあります。カウンターは増えるのにコアのログが出ない場合は、ポリシールーティングと待受アドレスを確認します。コアがリクエストを受け取っても外部へ接続できない場合は、システム時刻、ノードパラメータ、ルーティングルール、プロキシサーバーIPの除外設定を確認してください。問題の区間を特定してから変更すれば、複数の変数が同時に変わるのを避けられます。

公開前に行う最小限の受け入れチェックリスト

家庭内ネットワークの受け入れ確認では、復旧できること、問題を特定できること、対象範囲を段階的に広げられることが重要です。設定を変更する前にOpenWrt設定とV2Ray設定をバックアップし、旁路ルーターを通らない管理用機器を1台残し、透過プロキシルールを無効化するコマンドを記録します。これにより、振り分けやDNS設定を誤っても管理画面から復旧できます。

長期運用では必要なログだけを残します。コアをアップグレードする前に、別ポートで新しいプログラムと既存設定の互換性をテストし、その後サービスファイルを置き換えます。設定ファイル、地理ルールデータ、プログラムのバージョンは一組として管理し、プログラム更新後に互換性のない古いフィールドを読み込まないようにしてください。

• テスト端末のデフォルトゲートウェイとDNSが、ともに想定したOpenWrtアドレスを向いている。
• ルーターの管理画面、プリンター、ストレージ機器、その他のLANアドレスが直接接続のままになっている。
• TCPとUDPをそれぞれテストし、ウェブページが開くことだけでUDPの検証を済ませない。
• ルーターを再起動した後、V2Rayプロセス、待受ポート、ファイアウォールチェーン、ポリシールーティングがすべて自動復元される。
• 透過プロキシを無効にすると、LANが通常の直接接続へ戻る。
• ログレベルが通常設定に戻り、フラッシュの空き容量と使用可能メモリが安定している。