OpenWrtルーター・バイパスルーターでmihomoを動かす方法｜構成と必要リソース

カーネル・管理画面・透過プロキシを区別する

mihomoは、Clashの設定体系を引き継ぐプロキシカーネルで、以前はClash Metaと呼ばれていました。YAML設定を読み込み、ノードへの接続、プロキシグループ、DNS、ルールによる振り分けを処理します。一方、OpenWrtはネットワークインターフェース、ルーティング、ファイアウォール、サービスを管理します。ルーターに実行ファイルを置いただけでは、LAN内の端末通信がプロキシを経由するわけではありません。

ルーターに導入する際は、サービスが起動するか、端末の通信がカーネルに届くか、カーネルが適切な出口を選ぶかをそれぞれ確認します。LuCIの管理プラグインなら通常これらをまとめて設定できますが、カーネルを手動で導入する場合は各要素を自分で連携させる必要があります。

• 明示的なプロキシ：パソコンやブラウザーでルーターのアドレスとHTTP・SOCKSポートを指定します。この設定に従うアプリだけがプロキシを利用します。
• 透過プロキシ：ゲートウェイがリダイレクト、ポリシールーティング、TUNなどで通信を取り込みます。端末ごとにプロキシアドレスを設定する必要はありません。
• DNSの振り分け：ドメイン名への応答に使うDNSリゾルバーを決め、ルール判定に必要な情報を提供します。通信の転送に関係しますが、同じ機能ではありません。

メインルーターとバイパスルーターの構成の違い

メインルーターに導入する場合：入口を集約できる一方、影響範囲も広い

メインルーターは上位ネットワークに直接接続し、通常はPPPoE接続、DHCP、DNS転送、NATも担います。端末のデフォルトゲートウェイがメインルーターを指すため、透過プロキシの通信経路を把握しやすい構成です。一方、設定更新やルール読み込み、プロキシプロセスが、PPPoE接続、無線LAN、ほかのサービスとリソースを奪い合うことがあります。

インターネット
  │
OpenWrtメインルーター：LAN 192.168.1.1
  │
スイッチ／無線LANアクセスポイント
  │
パソコン：192.168.1.100、ゲートウェイ 192.168.1.1

OpenWrt対応機器をすでに所有しており、ネットワーク全体の通信をまとめて管理したい環境に向いています。運用開始前にローカル管理用の経路を確保してください。プロキシサービスに障害が起きた場合、基本的な転送が直接接続に戻るかどうかは、プラグインのファイアウォール処理や障害対応の実装によります。自動で復旧すると決めつけないでください。

シングルアームのバイパスルーター：端末ごとに試し、戻り経路に注意

一般的なバイパスルーターはLANインターフェースを1つだけ備え、メインルーターと同じスイッチネットワークに接続します。インターネット接続は引き続きメインルーターが担います。テスト用パソコンのデフォルトゲートウェイを192.168.1.2に変更し、バイパスルーター自身のデフォルトゲートウェイは192.168.1.1のままにします。バイパスルーターではIP転送を有効にし、該当する転送を許可するファイアウォールルールを設定する必要があります。

メインルーター：192.168.1.1、インターネット接続と既存のDHCPを担当
  │
同一LANのスイッチネットワーク
  ├─ バイパスルーター：192.168.1.2、デフォルトゲートウェイ 192.168.1.1
  └─ テスト用パソコン：192.168.1.100、デフォルトゲートウェイ 192.168.1.2

この構成では、外部への通信はバイパスルーターを経由する一方、戻りの通信はメインルーターから端末へ直接返る場合があります。バイパスルーターで送信元アドレス変換を行うかどうかは、プラグインの要件とコネクショントラッキングの結果を確認して判断してください。SNATを有効にすると一部の戻り通信をバイパスルーター経由にできますが、元の端末アドレスが見えなくなります。「すべてのインターフェースでマスカレードを有効にする」方法を万能な解決策として使わないでください。

3つの導入方法と保守コスト

プラグインを使うと、サブスクリプション、プロキシグループ、実行ログを管理しやすくなります。ただし、対応カーネルとファイアウォールのバックエンドを必ず確認してください。OpenWrt 22.03以降では、nftablesベースのfirewall4が標準です。従来のiptablesルールしか生成しない古いプラグインは、インストールに成功しただけでは透過プロキシが使えるとは限りません。カスタムファームウェアでは構成要素が異なる場合もあるため、実際の環境を確認しましょう。

設定の取得元や更新のタイミングを自分で管理したい場合は、カーネルの直接実行が適しています。まずカーネルの設定テストコマンドで動作を確認し、その後、サービスをprocdに管理させます。サブスクリプションのファイルにルーター側のDNS、リスナー、通信取り込みの設定が含まれていない場合は、ローカル設定を追加する必要があります。そうしないと、更新時にローカル設定が上書きされる可能性があります。

コンテナはリソースに余裕のある機器に向いていますが、透過プロキシの複雑さがなくなるわけではありません。TUNには通常、利用可能な/dev/net/tunと適切なネットワーク管理権限が必要です。また、ブリッジネットワーク内のリスナーアドレスは、ホストのLANアドレスとは異なります。コンテナを起動するためだけに、すべての権限を付与しないでください。

# カーネルが /usr/bin/mihomo に配置されている場合
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

上記のパスは手動導入の例であり、すべてのプラグインで使われる固定のディレクトリではありません。テスト時は、プラグインが実際に使用する設定ファイルを指定してください。プラグインによっては、ダウンロードしたサブスクリプションファイルを直接使わず、一時ディレクトリに最終設定を生成します。

構成選びとメモリ・ストレージの見積もり

CPUとファームウェアのターゲットを確認してからカーネルを選ぶ

ubus call system board
uname -m
cat /proc/cpuinfo
free -m
df -h /overlay /tmp

ubus call system boardで機器とファームウェアのターゲット情報を確認し、uname -mで実行アーキテクチャを判断できます。一般的な対応関係は、aarch64がARM64、x86_64がAMD64です。MIPSはエンディアンやソフトウェア浮動小数点など、ビルドごとの差も確認してください。「MIPS」と表示されただけでファイルを選ぶことはできません。

ARMv7や、特定のCPU命令セットを必要とするx86向けビルドも、ハードウェアとの適合確認が必要です。Exec format errorが出る場合は、まずアーキテクチャとファイル形式を確認してください。Illegal instructionが出る場合は、必要な命令セットを確認します。どちらもサブスクリプションのリンクを変更して解決する問題ではありません。

容量の数値は計画の目安であり、性能を保証するものではありません

これらは容量計画の目安であり、実測スループットや最低システム要件を示すものではありません。実際の使用量は、ルールプロバイダー、地理データの形式、接続数、DNSキャッシュ、プラグインの実装によって異なります。freeの出力で「空き」メモリが少ないからといって、すぐにメモリ不足と判断しないでください。利用可能なメモリ、プロセスの常駐メモリ、カーネルログを合わせて確認しましょう。

• ストレージ：使用中のカーネル、設定、ルールデータを容量の見積もりに含めてください。更新時には古いファイル、ダウンロードしたパッケージ、展開後のファイルが同時に残る場合があります。
• 一時ディレクトリ：OpenWrtの/tmpは通常メモリファイルシステムを使用するため、大きなファイルのダウンロードは実行時メモリを圧迫します。
• 書き込み頻度：容量の小さいフラッシュストレージにデバッグログを継続して書き込まないでください。通常は適切なログレベルを使い、原因調査時だけ短時間、詳細ログを有効にします。
• CPU：プロキシの暗号化、ユーザー空間での転送、ルール判定にはCPUリソースが必要です。ギガビット対応のLANポートがあっても、すべてのプロキシプロトコルで1Gbpsの速度が出るとは限りません。

ゲートウェイ・DNS・ポート設定の役割分担

各アドレスの役割を明確にする

上記のバイパスルーターの例では、テスト用パソコンのゲートウェイは192.168.1.2です。バイパスルーターがLAN向けDNSを提供する場合、パソコンのDNSにも同じアドレスを設定できますが、バイパスルーターがLAN側の53番ポートで実際に待ち受けていることが条件です。DNSだけを変更しても、通常のインターネット通信が自動的にバイパスルーターを経由するわけではありません。ゲートウェイだけを変更しても、DNSクエリがカーネルの名前解決処理を経由するとは限りません。

よくある構成では、dnsmasqがLAN向けに53番ポートを提供し、必要なクエリを127.0.0.1:1053で待ち受けるカーネルに転送します。このとき、クエリが自分自身に戻る循環を防ぐ必要があります。たとえば、カーネルがdnsmasqを上流DNSに指定し、dnsmasqがすべての要求をカーネルへ返すと、名前解決がループします。管理プラグインがDNSをすでに制御している場合は、プラグインの設定で調整し、同じルールを別途追加しないでください。

fake-ipとIPv6をあわせて確認する

fake-ipモードでは、通常198.18.0.0/16などの予約済みアドレスプールから、対応するアドレスが返されます。このアドレスが返ったこと自体は、名前解決の失敗を意味しません。ただし、その後の接続は同じプロキシ制御の仕組みで処理する必要があります。端末がfake-ipを受け取った後、バイパスルーターを経由せずに接続すると、ドメイン名は解決できても接続がタイムアウトすることがあります。

IPv4のゲートウェイを変更しても、IPv6の経路は自動的には変わりません。メインルーターがRAでIPv6のデフォルトルートやDNSを端末に通知し、一部の接続が別経路を通る場合があります。IPv6を含めた制御を適切に設定するか、試験段階ではテスト端末のIPv6を明示的に制限して、それぞれ検証してください。IPv4で一度成功しただけで、デュアルスタックの通信全体が制御されていると判断しないでください。

透過プロキシ・TUN・ファイアウォールの連携

主な通信取り込み方式には、TCPリダイレクト、TPROXY、TUNがあります。TCPリダイレクトは主にTCPを処理します。TPROXYはTCPとUDPに利用できますが、対応するカーネルモジュール、ポリシールーティング、ファイアウォールルールが必要です。TUNは仮想ネットワークデバイスでIPパケットを受け取る方式で、適切なルーティング、権限、転送設定も必要です。

mihomoのtun.auto-routeは関連ルートの自動設定に使います。auto-redirectはLinux上の自動リダイレクト機能に関係する設定です。利用できるかどうかは、カーネルのバージョンとシステム依存関係を確認してください。これらの設定だけで「LAN内のすべての端末を取り込める」わけではありません。特にプラグインがすでにルールを生成している場合は、別の自動ルーティング方式を同時に有効にしないでください。

• LAN内の管理通信と必要なプライベートネットワーク通信が正しい経路を通るようにし、ルーターの管理画面へのアクセスまでプロキシに送られないようにします。
• プロキシノード自体への接続が、同じ通信取り込み経路に再び入らないようにしてください。ループが発生する可能性があります。
• ソフトウェアフローオフロードとハードウェアフローオフロードが、現在の通信取り込み方式を迂回していないか確認します。まずオフロードを無効にして基準となる動作を検証し、プラグインの互換性情報を確認してから再度有効にしてください。
• 透過プロキシを管理するサービスは1つだけ実行してください。複数のプラグインがDNSポートを奪い合ったり、ルートを上書きしたり、同じ接続を重複して処理したりする可能性があります。

# OpenWrtの現在の状態を確認。コマンドはインストール済みのコンポーネントによって異なります
ip route show
ip rule show
nft list ruleset
logread | grep -i mihomo
dmesg | grep -i -E 'oom|out of memory'

ip route showで表示されるのは、主にメインルーティングテーブルです。ポリシールールが別のテーブルを参照している場合は、そのテーブルも確認してください。ログにサービスの起動成功が記録されていても、プロセスが動いていることしか分かりません。LAN転送、DNS、UDPの経路が検証済みであることは示しません。

端末1台ずつ段階的に検証し、必要なら元に戻す

1. 現在の状態を保存する。OpenWrtの設定をバックアップし、メインルーター、バイパスルーター、DHCP範囲、管理用アドレスを記録します。ゲートウェイをメインルーターに設定した管理用端末を1台確保してください。
2. まずカーネルを検証する。設定テストを実行し、サブスクリプションを読み込めること、プロキシグループに選択可能なノードがあること、サービスが繰り返し終了しないことを確認します。ノードへの接続には時刻同期と上位ネットワークへの接続も必要です。
3. まず明示的なプロキシでテストする。例として7890番ポートを有効にし、LANからの接続を許可している場合は、テスト用パソコンで次のリクエストを実行し、ノードの問題と透過プロキシの問題を切り分けます。
4. 次にテスト用パソコンのゲートウェイを変更する。192.168.1.2に設定し、実際のDNS構成に応じて名前解決先も設定します。LAN内の管理、直接接続するサイト、プロキシルールがそれぞれ正常に動作することを確認してください。
5. ルールと接続を確認する。管理画面で対象ドメイン、適用されたルール、プロキシグループ、最終的に選ばれたノードを確認します。Webページが開けても、プロキシを経由しているとは限りません。DIRECTに一致している可能性もあります。
6. 最後に対象を広げる。UDP、IPv6、ルール更新、端末の再起動をテストします。すべて問題がなければ、DHCPの配布設定を変更するか、対象端末を増やしてください。

# テスト用パソコンで実行。対応するHTTPプロキシの待ち受けを有効にしておく
curl -I --proxy http://192.168.1.2:7890 https://example.com/

# バイパスルーターがLAN向けDNSを提供していることを確認してから実行
nslookup example.com 192.168.1.2

1つ目のコマンドで確認できるのはHTTPプロキシの経路です。すべてのアプリ、UDP、透過プロキシが使えることを示すものではありません。2つ目は指定したDNSサーバーが応答するかを確認するだけで、想定した上流DNSを経由した応答かどうかは分かりません。カーネルのクエリログや実際の接続記録と照らし合わせてください。

元に戻す場合は、まずテスト用パソコンのゲートウェイとDNSを元の値に戻してから、プロキシサービスを停止し、プラグインが通信取り込みルールを削除したことを確認してください。DHCPを変更していた場合は、端末にリースを再取得させます。カーネルプロセスだけを終了し、停止したポートへのファイアウォールリダイレクトを残さないでください。

導入前に決めておきたいこと

安定稼働しているOpenWrtメインルーターがあり、リソースにも余裕がある場合は、機能を集約することで追加のゲートウェイ管理を減らせます。既存のネットワーク構成を保ちながら段階的に検証したい場合は、バイパスルーターから始められますが、端末へのゲートウェイ配布、DNSの管理、戻り経路の調整が必要です。バイパスルーターはネットワーク全体を自動的に制御する機器の名称ではなく、具体的な転送構成の一つです。

機器を選ぶ前に、CPUアーキテクチャ、利用可能なメモリ、永続ストレージの容量を確認し、ファームウェアのファイアウォールに対応した管理方法を選びます。運用開始時は「明示的なプロキシ → 端末1台での透過プロキシ → DNSとデュアルスタック → ネットワーク全体へ拡張」の順に進めましょう。各段階の範囲を明確にでき、問題が起きても、サブスクリプション、ゲートウェイ、ファイアウォールを同時に変更せず、検証済みの状態に戻せます。