OpenWrtのバイパスルーターでmihomoを動かす方法｜透過プロキシの構成と設定

1. まずバイパスルーターが処理する通信を決める

mihomoはプロキシコアであり、OpenWrtのネットワーク設定をすべて自動で行うものではありません。サブスクリプションはノードとルールを提供し、コアは接続先を選択します。端末の通信がコアに届くかどうかは、デフォルトゲートウェイ、ルーティングテーブル、ファイアウォール、DNSの経路によって決まります。YAMLをルーターに置いて実行しただけでは、LAN内の端末が透過プロキシに接続されたことにはなりません。

ここではIPv4の構成例として、メインルーターを192.168.10.1/24（PPPoE接続とDHCPを担当）、バイパスルーターを192.168.10.2/24（デフォルトゲートウェイはメインルーター）、テスト用PCを192.168.10.100/24とします。これらのアドレスは説明用です。実際に導入する前に現在のネットワークに合わせて変更し、DHCPのアドレス範囲と重複しないことを確認してください。

2. OpenWrtへの導入前に確認すること

システムのアーキテクチャとファイアウォールのバックエンドを確認

SSHでシステムのバージョン、CPUアーキテクチャ、空きストレージを確認します。OpenWrt 22.03以降は通常firewall4とnftablesが使われますが、アップグレードやカスタムファームウェア、サードパーティープラグインによって環境が異なる場合があります。nftables環境に旧版のiptablesルールをそのまま貼り付けないでください。また、同じ通信を処理する透過プロキシ用プラグインを複数同時に動かさないでください。

ubus call system board
uname -m
df -h /overlay
free -m
command -v fw4
command -v nft
ip route show
ip -6 route show

uname -mの出力はアーキテクチャの確認に役立ちますが、それだけでmihomoのビルドを選べるわけではありません。デバイスのCPU機能に合ったものを選んでください。古い機種では新しい命令セットに対応していない場合があります。起動直後に終了したり、不正な命令のエラーが出たりする場合は、サブスクリプションを何度も変更する前にバイナリのビルドを確認します。

コア、設定ファイル、サービス管理を分ける

実行ファイル、作業ディレクトリ、サービススクリプトは分けて管理するのがおすすめです。たとえば、コアを/usr/bin/mihomo、設定を/etc/mihomo/config.yamlに置き、OpenWrtのprocdで実行状態を管理します。以下のパスは構成例であり、システムに該当ファイルがあらかじめインストールされていることを示すものではありません。

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

2つ目のコマンドは設定を読み込めるか確認するもので、インターネット接続全体をテストするものではありません。ルールセット、GeoIP、GeoSiteのデータを使う場合は、対応するリソースも必要です。外部リソースをダウンロードできるか、保存先に書き込めるか、初回起動時にまだ確立されていないプロキシ接続に依存しないかを確認します。サービススクリプトには起動順序、異常終了時の再起動、ログ出力を設定し、SSHセッション終了とともにプロセスが停止しないようにします。

3. 明示的プロキシでサブスクリプションとルールを確認

導入は「コアの起動 → 明示的プロキシの動作確認 → DNSの動作確認 → 透過プロキシ化」の順に進めます。こうすれば、ノードの問題とルーティング設定の問題を切り分けられます。以下は疎通確認用の最小構成です。プロキシノードはなく、最後のルールですべての通信を直接接続します。サブスクリプションの代わりにはならず、プロキシ経由の通信が可能かどうかも確認できません。

mixed-port: 7890
allow-lan: true
bind-address: 192.168.10.2
mode: rule
log-level: info
ipv6: false

rules:
  - MATCH,DIRECT

この設定例を実際の設定に統合するときは、同じトップレベルの項目を複数残さないでください。LANからの接続を許可する場合、OpenWrtのファイアウォールで信頼できるLANからのポート7890へのアクセスだけを許可します。WANには公開せず、インターネットからのポート転送も設定しないでください。待ち受けアドレスには、バイパスルーターが実際に使用しているアドレスを指定します。

1. まずテスト用PCのHTTPプロキシを192.168.10.2:7890に設定し、リクエストがコアに届くことを確認します。
2. 次に、有効なClash形式のサブスクリプションを読み込み、プロキシグループに利用可能なノードが含まれていることを確認して、使うノードを選びます。
3. 接続ログで適用されたルールと出力先を確認します。ルールモードでの結果はルールの順序によって決まり、プロキシグループ名に「自動」と書かれているかどうかには左右されません。
4. 透過プロキシのテストに進む前に、PC側の明示的プロキシを無効にします。2つの接続方式が重なり、誤った判断につながるのを防げます。

curlをインストールしたテスト用PCでは、curl -I --proxy http://192.168.10.2:7890 https://example.comを実行できます。このコマンドでHTTPプロキシの通信経路を確認できます。ノード経由かどうかを確認するには、適用ルール、出力先のログ、信頼できる接続元IP確認サービスの結果も併せて確認してください。

4. TProxy、redir、TUNの違い

redirは主にTCPを処理

redir-port: 7892を設定するだけでは、待ち受けポートが作られるだけです。対象となるTCP通信をそこへ転送するファイアウォール設定も必要です。この入口だけではUDPを同じように透過処理できません。Webページは開くのにゲーム、音声通話、QUICで問題が出る場合は、タイムアウトを延ばす前にUDPの実際の経路を確認してください。

TProxyにはマークとポリシールーティングが必要

tproxy-port: 7893はTCPとUDPの透過プロキシ用の入口にできますが、対応するカーネルモジュール、ファイアウォールルール、ルーティングテーブルがすべて必要です。システムはfwmarkとip ruleを使って、マーク付きパケットをローカルの受信経路に転送します。マーク値とルーティングテーブル番号は、既存のVPN、マルチWAN、その他のプラグインと重複しないように設定してください。どの機器でも同じ番号が空いているとは限りません。

TUNはスイッチを1つ有効にするだけではない

mihomoのTUNはauto-routeなどの項目を使ってルートを設定できますが、OpenWrt側の転送ポリシー、インターフェースの認識、IPv6ルートは別途確認が必要です。新しいバージョンのmihomoはLinuxでauto-redirect関連の機能も利用できます。動作は使用中のコアのバージョンに対応したドキュメントで確認してください。異なる解説記事にある自動リダイレクト機能と手動設定のTProxyルールを同時に有効にしないでください。

5. ゲートウェイ、戻り経路、ファイアウォール転送

シングルアーム構成では、テスト用PCのデフォルトゲートウェイを192.168.10.2に設定し、バイパスルーター自身のデフォルトルートは192.168.10.1を向くようにします。メインルーターとバイパスルーターのデフォルトルートを互いに向けないでください。DHCPをメインルーターで提供している場合は、まずPCの設定を手動で変更します。動作確認後、DHCPオプション3でゲートウェイ、オプション6でDNSを配布できます。

• IP転送：sysctl net.ipv4.ip_forwardでIPv4転送の状態を確認します。通常の転送には値が1である必要があります。
• ファイアウォールゾーン：LuCIの「ネットワーク」→「ファイアウォール」→「一般設定」で、インターフェースの所属ゾーンと転送ルールを確認します。画面の表記はバージョンによって異なるため、実際のゾーンとインターフェースの割り当てを基準にしてください。
• 同一セグメント内の戻り経路：メインルーターが応答パケットを直接PCに返し、経路が非対称になる場合があります。その結果、バイパスルーター上のコネクショントラッキング、フィルタールール、統計が想定と異なることがあります。
• ICMP Redirect：同じインターフェースでパケットを受信・送信すると、システムが端末により直接的なゲートウェイへ切り替えるよう通知する場合があります。バイパスルーターのリダイレクト送信設定と、端末がリダイレクトを受け入れるかを確認してください。

シングルアーム構成の一部では、送信元アドレスを制御して変換し、直接接続する通信の戻り経路をバイパスルーター経由にします。その代わり、上流から見る送信元がバイパスルーターのアドレスに統一され、端末ごとの統計やポリシーに影響することがあります。「すべてのゾーンでマスカレードを有効にする」ことを万能の解決策にしないでください。デュアルNIC、独立した下位ネットワーク、異なるファイアウォールポリシーでは、それぞれに合わせた設計が必要です。

6. DNS：ポート53と1053の役割を整理

OpenWrtでは通常、dnsmasqがポート53で待ち受け、DHCPとLAN内の名前解決を提供します。mihomoも同じアドレスのポート53で待ち受けると、競合が起こります。切り分けやすい構成は、端末からバイパスルーターの53番ポートへ問い合わせ、dnsmasqからmihomoのローカル1053番ポートへ転送し、その後mihomoが上流DNSに問い合わせる方法です。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

これはDNS設定の一例です。上流アドレスに到達できることと、その接続経路が実際のプロキシポリシーと整合していることを確認してください。LuCIの「ネットワーク」→「DHCP/DNS」→「一般設定」にあるDNS転送では、使用中のバージョンでサポートされている書式に従って127.0.0.1#1053を設定できます。resolvファイルの参照元も確認し、dnsmasqから自身へ再転送されないようにしてください。

fake-ipが返すのは接続を対応付けるためのアドレスであり、接続先Webサイトの実アドレスではありません。そのアドレスに端末が接続したとき、その通信もmihomoで受信できて初めてマッピングが機能します。DNSだけバイパスルーターを経由し、ゲートウェイがメインルーターのままだと、「名前解決はできるのに、どのWebページもタイムアウトする」ことがあります。

• LAN内のホスト名は、まずdnsmasqで処理するのがおすすめです。互換性に問題がある場合は、ドメインごとにfake-ipの除外や名前解決ポリシーを設定してください。
• ポート53のリダイレクトで処理できるのは、対象となる従来型DNSだけです。ブラウザー内蔵のDoH、アプリ独自の暗号化DNS、その他のトンネルは個別に確認する必要があります。
• dns.ipv6: falseを設定しても、端末のIPv6が無効になるわけでも、IPv6通信が透過プロキシに取り込まれるわけでもありません。端末はメインルーターから通知されたIPv6のデフォルトルートで直接接続する場合があります。

まずIPv4の動作を確認してから、IPv6のRA、DNS通知、デフォルトルート、プロキシ経路を個別に設計することをおすすめします。デュアルスタックの通信を処理する場合は、AAAAの名前解決と実際のIPv6接続も確認してください。IPv4の接続元だけでは判断できません。

7. 段階ごとの動作確認とトラブルシューティング

一度に変更するのは1か所だけにし、変更前後の結果を記録します。以下の順で確認すれば、「通信がバイパスルーターに届いていない」「コアには届いているがルールが違う」「ノード自体に問題がある」を切り分けられます。

1. 基本ネットワーク：テスト用PCからメインルーターとバイパスルーターの管理アドレスにアクセスできること、バイパスルーターのデフォルトルートが正しいこと、システム時刻が正確であることを確認します。
2. 明示的プロキシ：ポート7890経由でテストサイトに接続し、接続ログ、プロキシグループの選択、出力先のエラーを確認します。
3. DNS：nslookup example.com 192.168.10.2を実行し、想定したDNS経路に問い合わせが届くことを確認します。fake-ipを有効にしている場合は、マッピング結果も確認してください。
4. 透過プロキシ：アプリのプロキシ設定を無効にして新しい接続を開始し、mihomoのログに接続が表示され、想定したルールが適用されることを確認します。
5. UDPとIPv6：UDPが必要なアプリとIPv6の接続先をそれぞれテストします。TCPの成功だけでは、他の2つの経路も正常とは限りません。
6. 再起動後の動作：バイパスルーターを再起動し、サービスの起動、DNSの動作、ファイアウォールルールの復元、ノードのホスト名解決を確認します。

パケットを確認するには、tcpdumpをインストールした機器でtcpdump -ni br-lan host 192.168.10.100を実行し、テスト用PCの通信を確認できます。br-lanは実際のLANインターフェース名に置き換えてください。ログにサブスクリプションのURL、ノードの認証情報、アクセス先ドメインが含まれる場合は、共有する前に機密情報を削除してください。

8. 設定の管理と元に戻す方法

サブスクリプションの更新、コアのアップグレード、ファイアウォールの変更は分けて行います。機器固有のDNS、待ち受けアドレス、入口ポート、ルーティングポリシーはローカル側で管理し、リモートのサブスクリプション更新で上書きされないようにしてください。オーバーライドや設定のマージ機能を使う場合は、元のサブスクリプションだけでなく、最終的に生成されたYAMLも確認します。

• アップグレード前に、現在のコアのバージョン、有効な設定、サービススクリプト、ファイアウォールルールを保存します。まず設定をテストし、その後にサービスの再起動を行ってください。
• メインルーターのDHCPで配布するゲートウェイとDNSを変更する場合は、変更前の値を記録します。元に戻すときは両方を復元し、ゲートウェイを戻した後も停止したDNSに依存する状態にならないようにしてください。
• コントロールインターフェースは必要な管理用アドレスからだけアクセスできるようにし、認証情報を設定してください。サブスクリプションファイルは機密情報として扱い、公開リポジトリには置かないでください。
• 障害時の迂回方法は事前に設計します。端末の接続先が電源の切れたバイパスルーターのままでは、メインルーターがそのゲートウェイアドレスを自動的に引き継ぐことはありません。

バイパスルーターの導入では、通信の入口、DNS、外向き通信の3つの経路を整合させることが重要です。まず1台の端末で明示的プロキシを確認し、透過プロキシの方式を1つ選んでから、DHCPで設定を配布する範囲を広げてください。ルールモード、サブスクリプションの読み込み、クライアントの操作についてはClashの使い方ガイドを、設定項目については詳細ドキュメントをご覧ください。