OpenWrtの透過プロキシ構築ガイド：Xrayをバイパスルーターで動かす方法

まずバイパスルーターの設置場所と通信経路を決める

バイパスルーターはプロキシのプロトコルではなく、ネットワーク上の設置形態を指します。メインルーターがインターネット接続とDHCPを担当し、バイパスルーターは一部端末のゲートウェイやDNSを担います。通信が実際にバイパスルーターを通る場合に限り、透過プロキシのルールが機能します。同じLAN内の機器にXrayをインストールしても、他の端末の通信が自動的に取り込まれるわけではありません。

同一サブネットに接続したシングルアーム構成を例にします。メインルーターは192.168.10.1、OpenWrtは192.168.10.2、テスト用PCは192.168.10.100です。バイパスルーターのデフォルトルートはメインルーターを向いたままにします。まずテスト用PCのIPv4ゲートウェイとDNSをバイパスルーターのアドレスに変更し、他の端末は従来のネットワークを使います。

シングルアーム転送では、同一インターフェース間の転送、戻り経路、ICMPリダイレクトも考慮が必要です。メインルーターが応答を端末へ直接返すと、バイパスルーターから直結セッション全体が見えなくなることがあります。SNATが必要かどうかは、戻り経路とコネクショントラッキングの状態を見て判断してください。「NATを有効にする」を常に必要な手順と考えるのは適切ではありません。テスト中は、以後のゲートウェイ選択に影響するリダイレクトをバイパスルーターが端末へ送っていないかも確認します。

カーネルを選ぶ前にノードの設定項目を確認する

v2rayNはデスクトップクライアント、XrayとV2Flyはプロキシカーネルです。OpenWrtではカーネルのプロセスを直接実行し、サービス管理機能からJSON設定を読み込めます。デスクトップ画面は必要ありません。サブスクリプションの読み込み、ノード切り替え、透過転送はそれぞれ別の機能です。実行ファイルを導入した後、設定の生成、サービスの起動、ファイアウォールとの連携が必要です。

導入前にCPUアーキテクチャ、ファームウェアのパッケージソース、空き容量を確認してください。OpenWrt 24.10.xでは標準でfirewall4とnftablesが使われます。旧バージョンのiptables向けコマンドをそのまま混在させないでください。TPROXYには、ファームウェア側で対応するカーネルモジュールも必要です。パッケージをインストールでき、カーネルのプロセスが起動しても、パケットの振り分け経路が機能しているとは限りません。

ubus call system board
uname -m
xray version
nft list ruleset
ip rule show
ip route show table all

パッケージ名だけでなく、実際に出力されたカーネルのバージョンを記録してください。アップデート後も設定を再テストし、特にノードにREALITY、fingerprint、特定の通信方式の設定がある場合は念入りに確認します。OpenWrt上の設定ファイルの場所はパッケージと起動スクリプトによって異なります。以降は/etc/xray/config.jsonを例に説明します。

dokodemo-door、TPROXY、ポリシールーティングの連携

dokodemo-doorは通信を受け取るインバウンドです。followRedirectを有効にすると、透過的な振り分けの仕組みを通じて元の宛先アドレスを取得できます。ただし、nftablesのルールを作成したり、システムのポリシールーティングを設定したりする機能はありません。inboundsにポートを追加しただけでは、端末の通信は自動的にそのポートへ流れません。

以下は、TCPとUDPを12345で受け取るXrayのインバウンド設定例です。ここではinbounds部分のみ示しています。実際の運用には、有効なoutbounds、ログ設定、ファイアウォール設定も必要です。すべてのIPv4アドレスで待ち受けるのは、ローカルからの透過転送に対応するためです。アクセス元はファイアウォールで制限し、このポートをインターネットに公開しないでください。

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

0x1とテーブル番号100はこの例での設定値です。導入前に他のポリシールーティングと競合しないか確認してください。プロキシプロセス自身の通信には、アウトバウンドのsockopt.markで振り分け用のmarkとは異なる値を設定するなど、別の除外条件を設け、ルールの優先順位も調整します。これを怠ると、プロキシサーバーへの接続が再び透過インバウンドに入り、ループするおそれがあります。

• 振り分け前に、バイパスルーター自身のアドレス、管理用サブネット、ブロードキャスト、マルチキャストなど、プロキシ対象外の宛先を除外します。
• プロキシサーバーのアドレスとプロキシプロセスの通信は別途処理します。ドメイン名で指定したノードのアドレス変更も、更新方法に含めてください。
• PREROUTINGは主に機器を通過する通信を処理します。機器自身が開始する通信はOUTPUTに関係するため、同じTPROXYルールをそのまま流用できません。
• REDIRECTは主にTCPのリダイレクトに使われます。UDPも必要な場合、インバウンドのnetworkだけを変更して、TCPのみを振り分けるファイアウォールルールを残さないでください。

この記事では、ファームウェアを問わず使えるnftablesの完全なスクリプトは提供しません。firewall4がサポートする永続化方法でルールを追加し、チェーンのhook、優先度、ファイアウォールゾーンの権限を確認してください。一時コマンドが成功しても、ファイアウォールの再読み込み後にルールが残るとは限りません。

routingとDNSの振り分けは個別に検証する

ファイアウォールはどのパケットをカーネルへ渡すかを決め、routingは受け取った通信のアウトバウンドを選びます。それぞれ別の役割があり、相互に置き換えることはできません。Xrayのルーティングルールは記載順に評価されます。LANへの直結など、明確な例外を先に指定し、その後にプロキシ対象を処理してください。どのルールにも一致しない通信は通常、先頭のアウトバウンドに送られるため、outboundsの並びも確認が必要です。

以下はルーティング設定の例です。既存の設定に、directという名前の直結アウトバウンドと、有効なノードを設定したproxyアウトバウンドがあることを前提とします。透明インバウンドから受け取った、それ以外の通信をプロキシへ送る広範なルールです。動作確認をしやすくするための例であり、地域別の振り分けを網羅したものではありません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["transparent-in"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatchを設定しても、「すべてのドメインを先に名前解決してから振り分ける」という意味にはなりません。宛先がドメイン名でも、既存ルールに一致すれば、ルーティング判定用の名前解決が行われない場合があります。透過接続で宛先IPしか取得できない場合、ドメインのルールに一致するドメイン名が自動的に得られるわけではありません。必要に応じてsniffingを検討できますが、暗号化されたすべてのプロトコルを判別できるわけではなく、DNSの設計に代わるものでもありません。

• 端末からの問い合わせ：テスト用PCは192.168.10.2:53へ問い合わせを送り、dnsmasqが設定に従って上流DNSを選ぶようにします。上流と下流で転送が循環しないよう注意してください。
• ノードのドメイン名解決：プロキシがまだ接続できない段階でもノードのアドレスを解決できるようにします。ノードの初回名前解決を、未接続のプロキシだけに依存させないでください。
• 問い合わせと接続の経路：リモートDNSの応答と実際の通信出口をできるだけ整合させ、DNSが返したアドレスへ実際の出口から接続できない事態を避けます。
• アプリ内蔵のDNS：ブラウザーの暗号化DNSは通常のポート53を通りません。テスト時に設定を記録しておかないと、バイパスルーターのDNSが機能していないと誤解することがあります。
• IPv6の経路：AAAAレコード、IPv6のデフォルトルート、IPv6の振り分け設定をあわせて確認します。IPv4だけを設定しても、IPv6通信がプロキシを通るとは限りません。

5段階で導入する：まず1台の端末で検証

通信の入口を変更する前に、管理用の接続経路を確保してください。以下はOpenWrt 24.10.xでよく使われるLuCIのメニュー構成を基準にしています。テーマや翻訳によって表示が異なる場合があります。アドレスを変更する前に設定をバックアップし、テスト用PCを元のゲートウェイへ戻せるよう、メインルーターのアドレスを記録してください。

1. ネットワーク設定をバックアップ

   「システム」→「バックアップ／フラッシュファームウェア」を開き、設定をバックアップします。現在のLANアドレス、DHCP設定、ファイアウォールゾーンを記録してください。リモート接続中にルール一式を置き換えないでください。

2. バイパスルーターのアドレスを固定

   「ネットワーク」→「インターフェース」→「LAN」→「編集」→「基本設定」を開き、固定アドレス192.168.10.2、サブネットマスク255.255.255.0、IPv4ゲートウェイ192.168.10.1を確認します。「DHCPサーバー」→「基本設定」で、バイパスルーターが重複してアドレスを割り当てないよう設定してください。

3. カーネルの動作を確認

   利用可能なノードを使ってアウトバウンド設定を整え、設定テストを実行します。サービスログに問題がないことを確認してから、12345番ポートが待ち受けているか調べてください。この段階では、ネットワーク全体のゲートウェイを変更したり、すべての端末を対象にした振り分けルールを有効にしたりしないでください。

4. まず1台を振り分ける

   テスト用PCのゲートウェイとDNSを192.168.10.2に変更し、振り分けルールの送信元を192.168.10.100だけに限定します。まずTCP、次にUDPをテストし、nftablesのカウンター、インバウンドの記録、アウトバウンドのタグを順に確認してください。

5. 再起動後も動作するか確認

   「ネットワーク」→「DHCP/DNS」→「基本設定」にあるDNS転送先を確認します。ローカルコンソールからファイアウォールを再読み込みし、機器を再起動して、ルール、ポリシールーティング、サービスの自動起動を再テストしてください。すべて確認できてから、DHCPでゲートウェイを配布する範囲を広げます。

xray run -test -config /etc/xray/config.json
ss -lnptu
logread | grep -i xray
nft list ruleset
ip rule show
ip route show table 100
nslookup example.com 192.168.10.2

上記のコマンドは状態確認に使います。ファームウェアにssがインストールされていない場合は、対応する診断ツールを追加するか、利用できるソケット確認コマンドを使ってください。設定テストの成功は、カーネルが設定を受け入れたことを示すだけで、接続先ノードへの到達を保証しません。DNS問い合わせが成功しても、その問い合わせで応答が得られたことを示すだけで、Webリクエストが適切なアウトバウンドを選んだ証明にはなりません。

名前解決はできるのに接続できない、UDPだけ失敗する場合の確認方法

パケットが通る順番に沿って原因を切り分けます。まずテスト用PCのゲートウェイを確認し、次に振り分けカウンター、カーネルログ、最後にリモート接続を確認してください。同じテスト中にDNS、ノード、ファイアウォールを一度に変更すると、アクセスが回復しても原因を特定しにくくなります。

性能を確認する際は、測定条件を固定してください。たとえば同じHTTPSリクエストを10回連続で行い、成功回数、接続時間、ダウンロード中のCPU使用率を記録します。その後、単一接続と複数接続の結果を比較します。これは測定方法の提案であり、この記事での実測結果ではありません。ルーターの公称ポート速度は、暗号化通信の実効速度を示すものではありません。CPU、冷却、MTU、ノードまでの回線がボトルネックになる場合があります。

バイパスルーターとデスクトップクライアントの使い分け

バイパスルーターは家庭内ネットワークの安定したルールを適用するのに適し、デスクトップクライアントはLAN外で端末単独の接続を行うのに適しています。同じサブスクリプションを複数の端末で使えますが、サブスクリプションのテキストはカーネルでそのまま実行できる設定ファイルではありません。バイパスルーター側でノードのアウトバウンド、ルーティングルール、更新方法を設定する必要があります。新しいノードを取り込む際に、透過インバウンドやループ防止の設定を上書きしないようにしてください。

導入完了の基準は「プロセスが起動していること」ではありません。端末のゲートウェイが正しく、振り分けルールに一致し、DNSの経路が明確で、アウトバウンドがルールどおりに選択され、再起動後も同じ状態を再現できることが重要です。元のゲートウェイと設定のバックアップを残しておけば、バイパスルーターのメンテナンス時に端末をメインルーターへ戻せます。ノード更新がLAN全体に影響する事態も防ぎやすくなります。