まずバイパスルーターの役割を決める

バイパスルーターは設置方法の一つであり、特別なプロキシプロトコルではありません。一般的には、既存の主ルーターにOpenWrt端末を追加し、選んだ端末のデフォルトゲートウェイとして設定します。主ルーターは回線接続、Wi-Fi、インターネットへの出口を引き続き担当し、OpenWrtは通過する通信をルールに従って処理します。

mihomoはClash Metaプロジェクトから派生したプロキシコアで、設定の読み込みやルール判定、接続の確立を担います。ルーターを管理するための総合的な画面ではありません。端末にコアをコピーしただけでは導入は完了せず、透過プロキシにはルーティング、DNS、ファイアウォールの設定も必要です。

通信をプロキシに通す方法を選ぶ

  • 明示的プロキシ：端末にHTTPまたはSOCKSプロキシのアドレスを設定します。サブスクリプションやノードの接続確認に適していますが、プロキシ設定に対応したアプリだけが利用します。
  • 透過プロキシ：OpenWrtで端末の通信を捕捉またはルーティングします。TProxyを使う方法と、mihomoのTUN仮想インターフェースを利用する方法があり、必要なカーネルモジュールやルーティング設定はそれぞれ異なります。
  • 統合管理プラグイン：プラグインでコア、設定、ファイアウォールを管理します。LuCIのGUIを使いたい場合に便利ですが、利用中のOpenWrtバージョンに対応しているか、事前に確認してください。

透過プロキシの管理には、いずれか一つの方法を選びます。複数のプラグインでDNSリダイレクト、ポリシールーティング、ファイアウォール設定を重複して行わないでください。また、プラグインが自動生成する設定を使う場合は、一時的な実行ファイルを直接編集しないようにします。

IPアドレス、デフォルトゲートウェイ、DHCPを設計する

以下は、LANポート1つ・同一サブネットを使う構成例です。主ルーターは192.168.10.1、OpenWrtは192.168.10.2、テスト用Macは192.168.10.50、サブネットマスクはすべて255.255.255.0です。実際に設定する際は、自宅のネットワークに合わせてアドレスを置き換え、重複がないことを確認してください。

デバイスデフォルトゲートウェイDNSと役割
主ルーター .1プロバイダー側の上流回線接続、インターネット向けNAT、DHCPを担当
OpenWrt .2192.168.10.1テスト端末からのDNS要求を受け、ルールに従って通信を振り分ける
テスト用Mac .50192.168.10.2DNSの接続先：192.168.10.2

まずOpenWrt自身の上流設定を行う

  1. LANケーブルで主ルーターのLANポートとOpenWrtのLANポートを接続します。ポートの役割は現在のネットワーク設定で確認し、本体の表示だけで判断しないでください。
  2. LuCIの「ネットワーク」→「インターフェース」→「LAN」→「編集」を開き、固定IPv4アドレス、サブネットマスク、主ルーターを指すIPv4ゲートウェイを設定します。
  3. OpenWrt自身が使う上流DNSを設定します。プロキシを起動する前に、コアのダウンロード、プロキシサーバーのドメイン名解決、サブスクリプションの更新ができる状態にしてください。
  4. 主ルーターでDHCPを引き続き提供する場合は、OpenWrtの該当LANにある「DHCPサーバー」→「一般設定」で「このインターフェースを無視」にチェックを入れます。これでそのインターフェースのDHCPによるアドレス配布は停止しますが、DNSサービスまで停止するわけではありません。

DHCPは、IPアドレス、ゲートウェイ、DNSを自動で割り当てる仕組みです。同じブロードキャストドメインで、競合するDHCPサーバーを不用意に動かさないでください。端末が主ルーターのゲートウェイを取得したり、次はバイパスルーターを取得したりして、接続が不安定になることがあります。

次にテスト用Macを設定する

macOSの「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「TCP/IP」を開き、元の設定を記録します。テスト用アドレス、サブネットマスク、「ルーター」のアドレスを表に合わせて入力し、「DNS」タブには192.168.10.2を設定してください。テスト用アドレスがDHCPプール外にあるか、予約済みであることを確認し、アドレスの重複を防ぎます。

LAN全体に適用する場合は、主ルーターのDHCPからオプション3（デフォルトゲートウェイ）とオプション6（DNSサーバー）を配布し、どちらもバイパスルーターを指定できます。家庭用ルーターによっては個別に設定できないため、その場合は端末ごとの設定を残すほうが戻しやすくなります。DHCPの変更後は端末のリース更新が必要です。すでに取得済みのリースはすぐには一斉に切り替わりません。

CPUアーキテクチャとリソースの余裕を確認する

ルーターにインストールするのはLinux向けの実行プログラムで、macOS用アプリではありません。まずSSHでシステムを確認し、mihomoのリリースから対応するアーキテクチャのファイルを選びます。「64ビットCPU」という情報だけでは判断できません。CPUが64ビットに対応していても、ファームウェアのユーザーランドが64ビットとは限りません。

ubus call system board
uname -m
getconf LONG_BIT
free -m
df -h
cat /etc/openwrt_release

軽量ファームウェアにはgetconfが含まれていないことがあります。その場合はシステムのボード情報とファームウェアのターゲットを確認します。一般にx86_64はAMD64、aarch64はARM64に対応します。MIPS機器ではエンディアン、命令セット、浮動小数点ABIも確認が必要です。実行時にExec format errorが出たら、実行権限を何度も変更するのではなく、まずアーキテクチャを確認してください。

推奨容量と実際の使用量を分けて考える

  • メモリ：256 MBの機器は慎重な検討が必要です。512 MB以上あれば、ルールセット、DNSキャッシュ、同時接続のための余裕を確保しやすくなります。これは導入計画の目安であり、コアが定める最低要件ではありません。
  • ストレージ：/overlayの空き容量を確認します。コアやルールデータベースに加え、更新時には新旧ファイルも容量を使うため、圧縮ファイルのサイズだけで判断しないでください。
  • CPU：プロキシ通信の暗号化、ルール判定、多数の接続はCPU負荷を高めます。回線の公称速度が1000 Mbpsでも、ルーター経由のプロキシ通信が同じ速度になるとは限りません。

インストール後にmihomo -vを実行してバージョンを記録し、トラブル調査時にはファームウェアのバージョン、通信の取り込み方式、ルールの規模も記録します。アイドル時、サブスクリプション読み込み後、10分間の連続転送後に、それぞれtopとfree -mを確認してください。プロセスの常駐メモリとシステムの空きメモリを見ます。Linuxのキャッシュ使用分を、単純にメモリリークとみなすことはできません。

コア、透過プロキシ、DNSを分けて設定する

OpenWrt 22.03以降の一般的なバージョンでは、標準のファイアウォールがfirewall4で、nftablesを使ってルールを生成します。古い解説にあるiptablesコマンドを、そのまま汎用設定として貼り付けないでください。プラグインを使う場合は、対応するファイアウォールのバックエンドを確認します。手動で導入する場合は、TProxyまたはTUNに必要なモジュールが現在のファームウェアで利用できるか確認してください。

設定を検証してから端末の通信を取り込む

実行設定とリソースの保存先を固定します。以下のコマンドは、コアが/usr/bin/mihomoにインストールされ、設定ファイルが/etc/mihomo/config.yamlにある場合を想定しています。実際にこのパスを使っている場合にのみ実行してください。

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

設定の検証に成功しても、設定を読み込めることが確認できただけです。サブスクリプションの更新、ノードへの接続、透過プロキシの動作が保証されるわけではありません。選択中のポリシーグループ、最終的なフォールバックルール、ノードのドメイン名を解決できるかも確認します。サブスクリプションURLにはアクセス情報が含まれることがあるため、ログやスクリーンショットを共有する前にURL全体を隠してください。

各ポートの用途を確認する

mixed-port: 7890を設定した場合、7890はアプリが明示的に接続するHTTP/SOCKS混合プロキシのポートです。tproxy-port: 7893を設定した場合、7893は透過転送ルールが使うポートです。どちらも変更可能な例であり、コアの起動時に必ず用意されるポートではありません。7890を開放しただけでは、LAN内の通信は自動的に取り込まれません。

TUNは仮想ネットワークインターフェースです。対応するデバイスや権限、ルーティング設定が必要になります。自動ルートを有効にしても、LANの転送、ファイアウォールゾーン、DNSの入口は別途確認が必要です。バイパスルーターの設定がすべて自動で完了するわけではありません。TProxyは通常、パケットマークとポリシールーティングを利用して、捕捉した通信をローカルのプロキシに渡します。

DNSの転送経路を一方向にする

よくある構成では、端末からバイパスルーターの53番ポートに届いたDNS要求をdnsmasqが受け取り、mihomoのローカルDNSリスナー（例：127.0.0.1:1053）に転送します。1053は実際の設定に合わせてください。dnsmasqからmihomoに転送した要求を、mihomoが再びdnsmasqへ戻すとループするため避けてください。

  • fake-ipを使う場合：コアが端末に対応付け用のアドレスを返し、その後、対応関係をもとにドメイン名を復元します。よく使われるアドレスプールは198.18.0.0/16です。既存ネットワークやVPNで使っているアドレス帯とは重複しないようにしてください。
  • ノードのドメイン名を解決する：プロキシサーバー自体の名前解決に使えるブートストラップ経路を確保します。プロキシサーバーに接続しないと、そのサーバーの名前を解決できないという循環を避けてください。
  • 暗号化DNSを確認する：ブラウザー独自のDoH設定により、LAN内のDNSを迂回することがあります。その結果、ドメイン名ベースのルールやfake-ipの対応付けが想定どおりに動かない場合があります。テスト時はDNSの経路を統一してください。

バイパスルーターがfake-ipを返した後は、端末の接続も同じコアを経由する必要があります。DNSだけをバイパスルーターに向け、ゲートウェイを主ルーターのままにすると、主ルーターは通常、これらのマッピング用アドレスを処理できません。ドメイン名は解決できるのにWebページが開かない、という症状が起きやすくなります。

シングルアーム構成、IPv6、安全性を確認する

シングルアームのバイパスルーターは、主に1つのLANインターフェースを使うため、受信と主ルーターへの送信が同じインターフェースを通ることがあります。直接接続の通信は往路でバイパスルーターを通っても、復路では主ルーターから端末へ直接返され、非対称経路になる場合があります。バイパスルーターで送信元アドレス変換が必要かどうかは、コネクショントラッキング、ファイアウォール、上流のルーティングを踏まえて判断してください。

構成によっては、転送される通信にSNATまたはmasqueradeを適用し、主ルーターから見える送信元をバイパスルーターのアドレスに変えます。これにより戻りの通信もバイパスルーターを通るようになり、シングルアーム構成を簡素化できる場合があります。一方、上流からは複数端末の送信元がまとめて見えるようになります。「LANゾーンでアドレスマスカレードを有効にする」設定が、すべての機器で必須とは限りません。

IPv4の設定後はIPv6も個別に確認する

主ルーターがRA（ルーター広告）を使って、端末にIPv6のデフォルトルートを通知し続ける場合があります。IPv4のゲートウェイだけ変更しても、IPv6通信は制御できません。IPv6も取り込むのか、対応するDNSや転送ルールを用意するのかを、構成に応じて明確にしてください。テスト時は一時的に端末のIPv6を無効にして比較できます。結果を確認してから、正式なデュアルスタック構成を決めましょう。

管理用ポートへのアクセスを信頼できる範囲に限定する

  • プロキシポート、DNSサービス、コントロール用インターフェースをインターネットに公開しないでください。
  • LANにプロキシを公開する必要がある場合は、allow-lan、待ち受けアドレス、クライアント認証、ファイアウォールの接続元制限を確認します。
  • コントロールAPIは、まずループバックアドレスだけで待ち受ける設定にします。リモートパネルが必要な場合は強固なキーを設定し、アクセスできる管理端末を制限してください。
  • OpenWrtのprocdサービス機能またはプラグインに付属するサービス管理機能を使って常駐させ、SSHセッション内でプロセスを起動するだけの運用は避けてください。

通信障害やルールの問題を経路に沿って調べる

トラブル調査では、一度に変更する箇所を一つに絞ります。まずアドレスとルート、次にDNS、最後にルールとノードを確認してください。サブスクリプションの変更、ゲートウェイの変更、ファイアウォールの再構築を同時に行うと、原因を特定しにくくなります。

テスト用Macでネットワーク設定を確認する

route -n get default
scutil --dns
ping -c 3 192.168.10.2
dig @192.168.10.2 example.com
curl -I --connect-timeout 10 https://example.com

IPv4のデフォルトゲートウェイが、例では192.168.10.2になっていることを確認します。DNS問い合わせがタイムアウトせず応答することも確認してください。システムのDNS出力にはVPN独自の検索ドメインが含まれる場合があるため、使用中のネットワークサービスに応じて判断します。特定の宛先からping応答がないだけでは、インターネット全体の切断とは限りません。DNSとHTTPSの結果も確認してください。

OpenWrtで転送設定とログを確認する

ip route
ip rule
ip route show table all
logread | tail -n 80
nft list ruleset

以下のコマンドは状態確認用で、既存のルールを削除しません。想定したデフォルトルート、パケットマークに関するポリシー、LANから処理チェーンへの転送入口があるかを確認します。ルールの出力にLAN内のアドレスやサービス情報が含まれることがあるため、共有時は調査に必要な部分だけ残してください。

症状まず確認する項目
ゲートウェイ変更後に完全に通信できなくなるバイパスルーターのアドレスに到達できるか、デフォルトゲートウェイ、IP転送、ファイアウォールが経路を許可しているか
IPアドレス宛ては接続できるが、ドメイン名の解決がタイムアウトする53番ポートの待ち受け状態、dnsmasqの転送先、上流DNSのループ
明示的プロキシは使えるが、透過プロキシは使えない透過プロキシの入口、ポリシールーティング、転送ルール、必要なカーネルモジュール
一部のWebサイトでプロキシルールが適用されないIPv6のデフォルトルート、ブラウザーの暗号化DNS、ルールの順序、実際の接続記録
再起動後に動かなくなるサービスの自動起動、設定ファイルの保存先、起動時のネットワークと時刻同期の状態

小さな通信は正常でも大きなファイルの転送が止まる場合は、MTU、Path MTU Discovery、上流のPPPoEカプセル化を確認します。最初からすべてのインターフェースを同じ値に変更しないでください。速度を測る際は、まずプロキシなしの基準値を測り、同じ端末と接続方式でプロキシ経由の速度を比較します。Wi-Fiの電波状況の変化を、コアの性能問題と誤認しないようにしましょう。

元に戻す手段を確保してから適用範囲を広げる

  1. 初期状態を保存する。OpenWrtの設定をバックアップし、主ルーターのアドレス、DHCPプール、テスト端末の元の自動取得設定を記録します。
  2. 基本機能を確認する。中国本土向けの直接接続、プロキシが必要な接続、LAN内のプリンターやNASへのアクセスが、ルールの想定どおりに動くことを確認します。
  3. 再起動後の動作を確認する。コアとバイパスルーターをそれぞれ再起動します。さらにMacのネットワークを切断して再接続し、正しいゲートウェイとDNSが使われているか確認してください。
  4. バイパスルーターが停止した場合を試す。テスト端末のゲートウェイとDNSを主ルーターおよび元の設定に戻し、通常のインターネット接続が復旧することを確認します。fake-ipを使っている場合は、DNSキャッシュの消去または関連アプリの再起動も必要です。
  5. 段階的に適用する。まず少数の端末を追加し、その後DHCPの配布設定を変更します。主ルーターの管理画面に直接接続できる端末を1台残してください。

同一サブネット内のバイパスルーターには、通常、自動で障害を引き継ぐ仕組みはありません。端末が停止中のバイパスルーターをデフォルトゲートウェイにしていると、主ルーターが稼働中でも自動的には引き継がれません。アドレス設計、DNSの経路、サービスの自動起動、復旧手順をまとめて記録しておけば、コアの更新やサブスクリプションの変更後も問題を迅速に特定できます。

Mac1台だけでプロキシを使う場合は、まずデスクトップクライアントを使うほうが、サブスクリプションやルールを確認しやすくなります。テレビやゲーム機、複数端末で同じルールを使う必要がある場合に、OpenWrtへ設定を移行しましょう。それぞれ対応する範囲が異なるため、最初から家庭内ネットワーク全体を変更する必要はありません。