OpenWrtのバイパスルーターで動かすXrayコア：透過プロキシの構成ガイド

バイパスルーターとメインルーターの通信経路を把握する

バイパスルーターは、LANケーブルにつなぐだけでネットワーク全体の通信を処理できるわけではありません。LAN端末から通信を転送するか、メインルーター側で対象の通信を明示的に振り分ける必要があります。この記事では、同一サブネットに接続するシングルインターフェース構成を例にします。メインルーターがインターネット接続とDHCPを担当し、OpenWrtが指定端末の通信を受け取り、直接接続するかXrayの出力先へ転送します。

上り方向の経路は「端末 → OpenWrt → メインルーター → 上位ネットワーク」です。同一サブネット内の端末間通信は通常、レイヤー2で直接行われるため、デフォルトゲートウェイを変更しても自動的にバイパスルーターを経由することはありません。OpenWrtのデフォルトゲートウェイはメインルーターのままにしてください。メインルーターのデフォルトゲートウェイもバイパスルーターに変更すると、転送ループが発生するおそれがあります。

Xrayコア、クライアント、透過プロキシの違い

Xrayは、インバウンド、ルーティング、アウトバウンドを処理するコアであり、OpenWrtのネットワーク管理画面は付属していません。v2rayNはデスクトップ向けクライアント、v2rayNGはXrayコアを使用するAndroidクライアント、v2flyNGはv2flyコアを使用するAndroidクライアントです。これらのサブスクリプション管理画面はOpenWrtのサービス設定とは別物で、サブスクリプションURLをXrayのJSON設定ファイルとして直接使うこともできません。

明示的プロキシを利用するのは、プロキシポートへ接続するアプリだけです。透過プロキシではネットワーク層で通信を捕捉する必要があります。Xrayを起動するだけ、インバウンドポートを1つ開放するだけ、または端末のゲートウェイを変更するだけでは、透過プロキシは動作しません。Linuxの転送設定、ファイアウォールの条件、ポリシールーティング、適切な戻り通信の処理も必要です。

OpenWrtの基本設定を順番に確認する

以下のメニュー名は、一般的なLuCI日本語画面を想定しています。翻訳やテーマによって表示が異なる場合があります。OpenWrt 22.03以降は通常firewall4とnftablesを使用し、旧バージョンではfirewall3とiptablesが使われています。まず稼働中の環境を確認し、対応するルールの書き方を選んでください。異なる方式のコマンドを1つの起動スクリプトに混在させないでください。

1. システムを確認する

   「ステータス」→「概要」を開き、ファームウェアのバージョンとターゲットプラットフォームを確認します。端末からubus call system boardとuname -mを実行してください。カーネルプログラムは機器のアーキテクチャと実行環境に合わせる必要があります。デスクトップ向けパッケージをルーターに入れても動作しません。

2. IPアドレスを設定する

   「ネットワーク」→「インターフェース」→「LAN」→「編集」→「一般設定」を開き、プロトコルを「静的アドレス」に設定します。設定例として、IPアドレスに192.168.10.2、サブネットマスクに255.255.255.0、IPv4ゲートウェイに192.168.10.1を指定します。実際のネットワークに合わせて値を変更してから保存・適用してください。

3. DHCPの二重運用を防ぐ

   「ネットワーク」→「インターフェース」→「LAN」→「編集」→「DHCPサーバー」→「一般設定」で「このインターフェースを無視する」にチェックを入れ、メインルーターが引き続きIPアドレスを割り当てるようにします。この手順は記事で扱う同一サブネット構成向けです。OpenWrtが下流ネットワークを個別に管理する構成には適用しないでください。

4. OpenWrt自体のインターネット接続を確認する

   「システム」→「システム」で時刻とタイムゾーンを確認し、デフォルトルート、名前解決、上位ネットワークへの到達性も調べます。システム時刻が大きくずれているとTLS接続に影響します。OpenWrt自体が正常に通信できない場合は、透過プロキシのルールを先に変更しないでください。

5. Xrayコアを起動してテストする

   ファームウェアに対応した信頼できるソフトウェアリポジトリからXrayをインストールまたは配置し、xray versionを実行して実際のバージョンを確認します。xray run -test -config /etc/xray/config.jsonで設定を検証します。ここで使うファイルパスは記事内の例です。サービスが実際に読み込むパスは起動スクリプトで確認してください。

テストに合格しても、確認できるのは設定ファイルを解析できることだけで、リモートへの接続が保証されるわけではありません。サーバーアドレス、ポート、プロトコル、通信方式、TLSパラメーターを確認してください。VMessやVLESSを使う場合は、提供元の設定と各項目を照合し、プロトコル名だけでsecurity、flow、通信方式を推測しないでください。

ubus call system board
uname -m
ip -4 route show
sysctl net.ipv4.ip_forward
xray version
xray run -test -config /etc/xray/config.json

上記のコマンドは確認とテスト用であり、ファイアウォールを設定するものではありません。転送要件に応じてnet.ipv4.ip_forwardを有効にし、必要なLAN転送がファイアウォールで許可されていることも確認してください。トラブルシューティングのためにファイアウォール全体を無効にしたり、上位ネットワーク側のインターフェースにプロキシのインバウンドを公開したりしないでください。

透過インバウンド、パケットマーク、ループ対策を設定する

透過プロキシの代表的な方式にはREDIRECTとTPROXYがあります。REDIRECTは主にTCPのリダイレクトに使われ、TCPの設定をそのまま完全なUDP対応に流用することはできません。TPROXYはTCPとUDPを処理できますが、対応するカーネルモジュール、ファイアウォールルール、ポリシールーティングが必要です。この記事では各レイヤーの関係を説明するためにTPROXYを取り上げますが、ファームウェアに依存しない「ワンクリック設定」は提供しません。

ここに示す値は構成例であり、性能測定の結果ではありません。ポート12345はファイアウォールのTPROXY転送先ポートと一致させてください。ルーティングテーブル番号100は任意の例です。使う前に、他のサービスが使用していないことを確認してください。マーク値も既存のマルチWAN接続やポリシールーティングと競合しないよう、一貫性のある設計が必要です。

{
  "inbounds": [
    {
      "tag": "lan-tproxy",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

• 捕捉レイヤー：LANの受信方向でテスト端末を識別し、対象のTCP・UDP通信を透過インバウンドに渡します。すべてのインターフェースの通信を無条件に捕捉しないでください。
• ルーティングレイヤー：マークを付けたパケットをポリシールーティングでローカルの受信経路へ送ります。ip rule showとip route show table 100を実行し、ルールが実際に存在することを確認してください。
• 除外レイヤー：LAN、ループバック、マルチキャストなど、プロキシを経由させない宛先を除外します。実際の環境に応じて、ほかの予約済みアドレス範囲も除外してください。
• ループ防止：リモートサーバーへ向かうXrayの接続が再び捕捉されないようにします。接続元、宛先、専用マークなどに基づいて除外ルールを設計してください。ドメイン名で指定した接続先は、名前解決後にIPアドレスが変わる点にも注意が必要です。
• 戻り通信のレイヤー：同一サブネットのシングルインターフェース構成では、直接接続への応答がバイパスルーターを通らない場合があります。ネットワーク構成に応じて、選択的なSNAT、ICMPリダイレクト、コネクショントラッキングを検討してください。SNATを使うと元の端末アドレスが隠れるため、安易に全通信へ適用しないでください。

ファイアウォールの振り分けとXrayのルーティングを分けて考える

OpenWrtのファイアウォールは「どのパケットをXrayに渡すか」を決め、Xrayのrouting.rulesは「コアに渡された後、どのアウトバウンドへ送るか」を決めます。ファイアウォールの段階で接続が除外されると、Xrayからは見えないため、ドメインルールを細かく設定しても適用されません。ファイアウォールでは必要なアドレスの除外と接続対象の範囲を扱い、ドメインや用途による振り分けはコアのルーティングに集約するのがおすすめです。

Xrayのルーティングルールは上から順に評価され、最初に一致したルールのアウトバウンドが選ばれます。明確なLAN内宛ての通信や個別の例外は、広範囲なルールより前に配置してください。広すぎるルールが後続の条件を先に処理してしまうのを防げます。outboundTagは実際のアウトバウンドのtagと完全に一致させてください。ルーティングルールだけをコピーして、対応するアウトバウンドを設定し忘れないようにしてください。

• domainStrategy: AsIsでは、ルーティングのIPアドレス照合だけを目的としたドメイン名の名前解決は行われません。
• IPIfNonMatchでは、ドメインルールに一致しなかった場合にドメイン名を解決し、IPルールで再照合することがあります。「すべてのDNSをプロキシ経由にする」設定ではありません。
• 透過接続では通常、宛先IPアドレスがコアに渡されます。ドメインルールを利用できるかどうかは、DNSの設計やスニッフィングによってドメイン情報を取得できるかに左右されます。スニッフィングですべてのプロトコルのドメイン名を特定できるわけではありません。
• geositeやgeoipを使う場合は、データファイルが存在し、パスが正しく、分類内容が想定どおりであることを確認してください。ファイルの欠落をサーバー障害と誤認しないようにしましょう。

DNSとIPv6の接続経路を個別に設計する

IPv4ゲートウェイを変更しただけでは、DNSとIPv6の通信までバイパスルーター経由になるとは限りません。端末が引き続きメインルーターへDNSリクエストを送信したり、メインルーターが通知したIPv6デフォルトルートで上位ネットワークへ直接接続したりする場合があります。テスト端末のDNSを192.168.10.2に設定すればバイパスルーター経由で名前解決できますが、そのアドレスでDNSサービスが実際に稼働していることが前提です。

1. DNSの入口を1つにする。一般的には、OpenWrtのdnsmasqでLANからの53番ポートへのリクエストを受け、明確なルールに従って転送します。同じアドレスとポートを別のDNSプロセスが使用していないか、先に確認してください。
2. 名前解決のループを防ぐ。dnsmasqから同じ機器上の別のDNSサービスへ転送する場合、そのDNSサービスの上流をdnsmasqに戻さないでください。プロキシサーバーをドメイン名で指定する場合は、プロキシ接続が確立する前でも利用できる初期の名前解決経路も用意します。
3. コアのDNS設定を区別する。Xrayのdns設定はコア関連の名前解決に使われるもので、LAN端末が自動的にそのDNSを利用するわけではありません。端末からのリクエストが、実際のDNSリスナーと転送経路を通る必要があります。
4. 暗号化DNSを確認する。ブラウザーやアプリ独自の暗号化DNSは、システムのDNS設定に従わない場合があります。テストでは使用する名前解決経路を明確にしてください。1回のnslookupの結果だけで、すべてのアプリの動作を判断しないでください。
5. IPv6を確認する。端末のIPv4とIPv6のデフォルトルートをそれぞれ確認してください。IPv6もバイパスルーター経由にする場合は、ルーター広告、IPv6ファイアウォール、透過転送を個別に設計する必要があります。IPv6を経由させない場合は、テスト端末で対象範囲を明確に制限してください。

まず1台で動作を確認し、接続範囲を広げる

テスト端末のIPアドレスを192.168.10.100、ゲートウェイを192.168.10.2に設定します。まずメインルーターの管理画面、LAN内の機器、通常の直接接続先へアクセスできることを確認し、その後プロキシが必要な宛先をテストしてください。TCPのウェブ閲覧ができたら、UDPアプリとDNSを個別に検証します。ウェブページが1つ開いただけでは、透過プロキシ経路全体が正しく動作するとは限りません。

1台での動作確認が済んだら、メインルーターのDHCPオプション3でバイパスルーターのIPv4ゲートウェイを配布し、オプション6で動作確認済みのDNSアドレスを配布する方法を検討できます。設定画面はメインルーターのファームウェアによって異なります。元のゲートウェイに戻す方法を記録し、端末が古いリースを使い続ける場合があることにも注意してください。復旧手段を確保できていない状態で、ネットワーク全体を一度に変更しないでください。

• 設定の永続化を確認：再起動後もXrayサービス、ポリシールーティング、ファイアウォールルールが残っているか確認します。コマンドラインで一時的に有効になっただけの状態を避けてください。
• ルールの管理元を確認：管理コンポーネントが設定を生成している場合、同じファイルやルールチェーンを手動でも管理しないでください。更新時に互いの設定を上書きするおそれがあります。
• ログの負荷を確認：トラブルシューティング中だけログを増やし、作業後は適切なレベルに戻してください。長期間にわたる高頻度の書き込みは、ストレージと機器に負荷をかけます。ログを共有する前に、アクセス先、認証情報、機器を特定できる情報を削除してください。
• 実際の負荷を確認：CPU、メモリ、接続数、温度を確認してください。スループットはハードウェア、プロトコル、回線状況によって変わります。インバウンドポートや機器名だけから一定の通信速度を推定することはできません。

応用ガイドでルーティングルールの順序とDNS設定を確認してください。用語が混同した場合は、用語集でインバウンド、アウトバウンド、システムプロキシの違いを確認できます。バイパスルーターの構築では、各レイヤーを順番に検証することが重要です。まず基本ネットワークを疎通させ、次にコアのアウトバウンドを確認し、最後に透過転送を有効にします。