この記事の概要

この記事では、PCやAndroidのクライアントを使えており、LAN内の端末でプロキシ接続を共有したい方を対象に、バイパスルーターのゲートウェイをテスト端末で確認し、コア、透過プロキシの入口、DNS、ルールの順に点検します。コアを主ルーターとバイパスルーターのどちらに置くか、OpenWrtのネットワーク設定とXray・V2Flyの設定の違いも整理できます。ここでは導入手順と確認方法を紹介します。機器の環境を問わずそのまま使える完全なファイアウォールスクリプトは掲載していません。

1. 主ルーターとバイパスルーター：通信経路を確認する

透過プロキシを使うには、通信がコアを実行している機器を実際に通る必要があります。「同じLANにOpenWrtを接続した」だけでは、ほかの端末が自動的にその機器を使うわけではありません。主ルーターがデフォルトゲートウェイなら、転送経路上で通信を取り込めます。スイッチに接続したバイパスルーターを使う場合は、端末のデフォルトゲートウェイを変更するか、主ルーターのポリシールーティングで対象の通信を転送する必要があります。

まずは1台でバイパスルーターを試す

おすすめ

主ルーターのPPPoE接続、Wi-Fi、DHCPはそのままにして、テスト用PC 1台だけのゲートウェイをバイパスルーターに設定します。影響範囲を小さくでき、問題が起きた場合も、そのPCのネットワーク設定を戻すだけで復旧できます。

おすすめのケース：既存のネットワークが安定しており、透過プロキシを初めて導入する場合

主ルーターでコアを直接実行

OpenWrtがゲートウェイとプロキシ転送を兼ねるため、通信経路はシンプルです。一方、コアの障害、ファイアウォールの変更、リソース不足がLAN全体に影響する可能性があります。

おすすめのケース：OpenWrtに慣れており、ゲートウェイを一元管理できる場合

主ルーターのポリシーでバイパスルーターへ転送

端末のゲートウェイは主ルーターのままにし、主ルーターから端末やサブネット単位でバイパスルーターへ転送します。往復の経路とループの回避を設計する必要があり、デフォルトルートを1つ追加するだけでは不十分です。

おすすめのケース：端末をグループ単位で一元管理したい場合、ポリシールーティングの経験がある場合

LANポートが1つのバイパスルーターでは、「主ルーターと端末が同じサブネットにある」構成になりがちです。この場合、往路はバイパスルーターを通っても、復路は主ルーターから端末へ直接送られる可能性があります。送信元アドレス変換が必要かどうかは、復路、ステートフルファイアウォール、コネクショントラッキングを踏まえて判断してください。NATを有効にすれば解決するとは限りません。同じインターフェース間の転送でICMPリダイレクトが発生し、端末が想定したゲートウェイを迂回する可能性もあるため、導入後に確認しましょう。

2. IPアドレスとポートを計画する：DHCPサーバーの二重稼働を防ぐ

ここでは、主ルーターを 192.168.10.1、バイパスルーターを 192.168.10.2、テスト用PCを 192.168.10.100、サブネットマスクを 255.255.255.0 とする構成を例にします。これらは説明用に設定した値で、機器の初期設定ではありません。使用前にアドレスの重複がないことを確認し、バイパスルーターのアドレスをDHCPの割り当て範囲から除外してください。

対象設定例役割
主ルーター192.168.10.1/24上位ネットワークに接続し、既存のDHCPサービスを維持
バイパスルーターのLAN192.168.10.2/24管理用の固定IPを設定し、上位ゲートウェイは主ルーターを指定
テスト用PC192.168.10.100/24デフォルトゲートウェイとDNSに、ひとまずバイパスルーターのアドレスを設定
ほかの端末既存の自動設定を維持試験中も従来のネットワーク経路を利用
53
端末からバイパスルーターのDNSへ接続するポート
1053
内部DNSサービスのポート例
12345
透過プロキシのインバウンドポート例

ポート番号は実際の待ち受け設定に合わせてください。ここでは、任意のローカルDNSサービスに 1053、透過プロキシのインバウンドに 12345 を使っています。コアをインストールしただけでは、これらのポートで自動的に待ち受けるわけではありません。dnsmasqは通常、端末向けに53番ポートを提供します。同じアドレスの53番ポートを別のプロセスと同時に使用しないでください。

3. XrayとV2Fly：プロトコル設定からコアを選ぶ

V2Rayはプロジェクトや技術エコシステムで広く使われる呼称ですが、導入時には具体的なコアを区別する必要があります。XrayとV2Flyは別の名称で呼ばれる同一のものではなく、同じ設定をそのまま相互に使えるとは限りません。既存の接続でREALITYやXTLS Visionが必要なら、Xrayが対応しているか確認してください。VMessなどを使う場合も、サーバーのパラメーター、トランスポート方式、選択したバージョンとの互換性を確認しましょう。

cat /etc/openwrt_release
ubus call system board
uname -m

# インストール済みコアのバージョンを確認
xray version
v2ray version

インストールには、現在のファームウェアのバージョンとアーキテクチャに合ったパッケージソースを優先してください。OpenWrt 22.03以降では、標準のファイアウォールがfirewall4とnftablesに切り替わっています。旧バージョン向けのiptablesベースの手順を、そのまま共通の方法として扱うことはできません。パッケージ管理ツールもファームウェアのバージョンによって異なる場合があるため、現在のシステムで使われているツールを確認し、異なるリリースのパッケージソースを混在させないでください。

結論：接続を確認してから通信を取り込む

ゲートウェイを変更する前に、バイパスルーター上のコアで明示的なプロキシ接続をテストしてください。これにより「ノードや設定の問題」と「透過転送の問題」を切り分けられ、プロトコル、DNS、ファイアウォールを同時に調査する事態を避けられます。

4. OpenWrtの導入手順：ネットワーク、コア、転送を個別に設定

以下のメニュー名は、一般的な中国語版LuCIを基準にしています。ファームウェアや翻訳によって表示名が異なる場合があります。操作前に既存の設定を保存し、少なくとも1台の端末から主ルーターへ直接アクセスできる状態を確保してください。初回の試験では、LAN全体のDHCPゲートウェイを変更したり、リモート接続中にファイアウォールルールを一括置換したりしないでください。

  1. 設定をバックアップ

    「システム」→「バックアップ/アップグレード」→「バックアップを生成」を開き、現在の設定を保存します。主ルーターのアドレス、DHCPの割り当て範囲、バイパスルーターの配線を記録し、直接接続できる管理用の経路も事前に確保してください。

  2. 固定アドレスを設定

    「ネットワーク」→「インターフェース」→「LAN」→「編集」→「基本設定」を開き、固定アドレス 192.168.10.2、マスク 255.255.255.0、ゲートウェイ 192.168.10.1 を設定します。管理画面にアクセスできることを確認してから、DHCPを設定してください。

  3. コアを確認

    対応するアーキテクチャのXrayまたはV2Flyをインストールし、各コアに合った形式で設定ファイルを作成します。まず構文を確認し、一時的な明示プロキシの入口を起動して接続をテストしてください。この段階では、全通信の取り込みは有効にしません。

  4. 転送を設定

    現在のファイアウォール環境に合わせて、透過プロキシの入口、トラフィックマーク、必要なポリシールーティングを設定します。対象をまず 192.168.10.100 に限定し、バイパスルーター本体、コアの送信通信、管理用サブネットを除外してください。

  5. テスト端末を接続

    テスト用PCのデフォルトゲートウェイとDNSを 192.168.10.2 に変更し、PC上のシステムプロキシを無効にします。直接接続するアドレス、プロキシ経由の接続先、ドメイン名の名前解決をそれぞれテストし、PCのクライアントがルーターの問題を覆い隠さないようにしてください。

  6. 自動起動を設定

    テストに成功したら、procdサービスとファイアウォールルールの永続化を設定します。「システム」→「起動時設定」でサービスの状態を確認し、機器を再起動してルールとプロセスが復元されることを確認してください。

以下では、指定した設定ファイルの場所を使った確認コマンドを示します。インストール済みのコアに合うコマンドだけを実行してください。ファイルパスはサービスの起動引数と一致させます。V2Flyの例はv5形式のコマンドです。旧バージョンでは、まず付属のヘルプを確認し、引数をそのまま流用しないでください。

# Xrayの設定を確認
xray run -test -config /etc/xray/config.json

# V2Fly v5の設定を確認
v2ray test -c /etc/v2ray/config.json

# OpenWrtのサービスログ
logread

設定チェックに成功しても、ファイルを解析できたことが分かるだけで、接続先に到達できるとは限りません。実運用では、プロセスの権限、ログ出力、待ち受けアドレス、システム時刻、証明書の検証も確認してください。ルーターの再起動後、時刻が同期する前にTLS接続が失敗することがあります。起動後の確認項目に時刻同期も含めましょう。

5. 透過プロキシの仕組み：ファイアウォールの取り込みとコアの振り分け

第1段階ではOpenWrtがコアに渡すパケットを決め、第2段階ではコアが受け取った接続を直接接続とプロキシ接続のどちらへ送るかを決めます。コアのroutingルールを書いただけでは、透過プロキシの入口がない限り端末の通信はコアに届きません。ファイアウォールで転送しても、アウトバウンド設定が正しくなければプロキシ接続は確立できません。

仕組み主な役割導入時の注意点
REDIRECT接続をローカルポートへリダイレクトし、主にTCP通信を取り込むコアが元の宛先アドレスを復元する方式に合わせる必要があります。TCP向けの設定をUDPにそのまま適用しないでください。
TPROXY通信を透過的にローカルの待ち受け先へ送り、TCPとUDPに対応透過ソケット、マーク、ポリシールーティング、関連するファイアウォールルールが必要
コアのルーティングドメイン名、宛先アドレス、ポートなどに応じてアウトバウンドを選択ルールの順序、ドメイン情報の取得元、使用するデータファイルに注意
送信通信の除外コア自身が開始した接続を再び取り込まないようにするプロセス、マーク、宛先アドレスなどの条件で設計し、ノードのドメイン名解決も考慮

Xrayを例にすると、透過プロキシの入口には dokodemo-door を使い、followRedirect と適切なsocket設定を組み合わせられます。これらのフィールドは、実際に使う方式に応じて設定してください。TPROXYでは専用のルーティングテーブルを用意し、指定したマークのパケットをローカル通信としてループバックデバイスへ送る構成が一般的です。マーク値とルーティングテーブル番号は環境に合わせて決め、既存のVPN、ポリシールーティング、ほかのサービスで使用中の値を避けてください。

6. DNSとIPv6：ゲートウェイが正しくても振り分けを迂回することがある

端末のDNSをバイパスルーターに向けた後は、バイパスルーターがクエリをどこへ転送するか、その経路が目的の振り分けに合っているかも確認してください。すべての名前解決を同じ出口に送るより、直接接続するドメインには適切なDNS経路を使い、プロキシ対象ドメインのクエリは想定した経路で処理するほうが、問題を特定しやすくなります。dnsmasqからコアへクエリを転送し、コアからの名前解決がdnsmasqに戻る循環を作らないでください。

  1. 待ち受けの経路を明確にする。端末は 192.168.10.2:53 に接続します。独立したローカルDNSサービスを使う場合、dnsmasqから 127.0.0.1:1053 へ転送できます。後者が必要なDNSリクエストに実際に対応していることを確認してください。通常のプロキシポートで代用することはできません。
  2. 転送設定を確認する。「ネットワーク」→「DHCP/DNS」を開き、DNSの転送先と上位DNSの取得元を確認します。回線事業者が提供するDNSサーバーを意図せず使い続けていないか確認してください。変更前に元の値を記録しておくと、元に戻すときに便利です。
  3. コア内蔵のDNSを区別する。コア内蔵のDNSをルーティング判定に使うかどうかと、LANからアクセスできるDNSの受け口を提供するかどうかは別の問題です。設定にDNS項目があるだけで、端末の名前解決を取り込めているとは限りません。
  4. 暗号化DNSを確認する。ブラウザーのセキュアDNSやアプリ内蔵のDNS機能によって、端末の設定が迂回されることがあります。テスト時はいったんDNSの経路を統一し、その後、端末の設定やルーティングポリシーでの対処を検討してください。
  5. IPv6を個別に確認する。IPv4のゲートウェイをバイパスルーターに変更しても、端末が主ルーターのIPv6ルーター広告を受け、上位ネットワークへ直接接続する場合があります。IPv6にも対応する転送とDNSのポリシーを設定するか、問題を切り分けるため、テスト端末で一時的にIPv6を無効にしてください。

FakeDNSは合成アドレスを返し、コアが元のドメイン名を復元する仕組みです。「有効にすればDNS漏れを防げる」という単純な機能ではありません。アドレス範囲、端末のキャッシュ、透過プロキシの入口、ルーティング判定を連携させる必要があります。初めて導入する場合は、通常のDNSとTCP・UDP転送の動作を先に確認し、FakeDNSが必要かどうかを検討してください。アドレスの対応付けとゲートウェイの問題を混同せずに済みます。

7. トラブルシューティングと復旧：アドレス、名前解決、転送の順に確認

接続できないときは、まず基本的なネットワークを確認してください。すぐにプロトコルを変更する必要はありません。テスト用PCからバイパスルーターの管理用アドレスにアクセスできること、バイパスルーターから主ルーターに到達できること、コアの明示プロキシが動作することを確認してから、透過プロキシとDNSを調べます。テスト用コマンドは任意のパッケージに含まれる場合があります。コマンドが見つからない場合は、ネットワーク障害と判断する前にインストール状況を確認してください。

# バイパスルーターでアドレス、ルート、ポリシールールを確認
ip addr show
ip route show
ip rule show

# firewall4を使うシステムで実際のルールを確認
nft list ruleset

# nslookupを使えるテスト端末で指定DNSサーバーを確認
nslookup example.com 192.168.10.2
症状まず確認する項目切り分けの目安
管理画面にもアクセスできないIPアドレスの競合、LANケーブル、サブネットマスク、端末のルートまずLAN内の接続を復旧します。プロキシプロトコルの問題ではありません。
明示プロキシは使えるが、透過プロキシは動作しない送信元の条件、透過プロキシの待ち受け、マーク、ポリシールーティングOpenWrtで通信を取り込む経路を重点的に確認
名前解決がタイムアウトする、または繰り返し失敗する53番ポートの待ち受け、上位DNSへの到達性、DNSのループ端末からバイパスルーターへ、バイパスルーターから上位DNSへ、それぞれテスト
一部のアプリだけがプロキシを迂回するUDP、IPv6、アプリ内蔵DNS、ゲートウェイブラウザーの表示だけで、すべての端末の通信経路を判断しない
再起動後に動作しなくなるprocd、自動起動、ルールの永続化、時刻同期サブスクリプションを再インポートするのではなく、起動時の処理を確認

結論：1台で元に戻せる手段を確保する

LAN全体へ展開する前に、テスト用PCのゲートウェイとDNSを元の設定に戻し、従来のネットワークが使えることを確認してください。その後、端末ごとにバイパスルーターのポリシーへ追加し、変更内容を記録します。再起動、DNS、UDP、IPv6のすべてを確認してから、ゲートウェイを一括配布するか検討してください。

バイパスルーターの導入で重要なのは、コアのプロセスを「実行中」にすることではなく、経路を説明・検証でき、問題があれば元に戻せるようにすることです。まずプロトコルの接続を確認し、次に通信がコアに届くことを確認してから、直接接続とプロキシ接続がそれぞれ正しい出口を通ることを確かめます。PCやAndroidのクライアントは接続パラメーターの検証に使えます。OpenWrtではさらに、ファイアウォール、ゲートウェイ、DNS、サービスの起動と停止を管理する必要があります。