家庭ネットワーク構築の実践：有線Mesh、単臂バイパスルーターとFail-Open

このネットワークの目的はデバイスを積み重ねることではなく、以下の3つの問題を同時に解決することにあります：複数部屋での安定したカバレッジ、デバイスごとのプロキシパスの選択、そしてバイパスルーター障害時に家庭全体のネットワークをダウンさせないこと。最終的な構造は以下の通りです：光モデムブリッジ → メインルーターPPPoE接続 → 4つのAP有線バックホール。N100単一ネットワークインターフェースデバイスが透過プロキシとDNSを担当し、コアワークステーションはバイパスルーターを迂回して自身でプロキシを管理します。

本記事はアーキテクチャの振り返りであり、ご自身のネットワークをチェックするための設計書としても機能します。文中のホスト名、SSID、サブスクリプションアドレス、およびパブリックノードはすべて一般化されています。.1、.7、.8 などは、同一プライベートネットワーク内の役割関係を説明するためにのみ使用されています。

設計上の結論

• Meshノードは可能な限り有線バックホールを使用してください。無線ローミングでは、バックホールリンク自体の輻輳を補うことはできません。
• 単臂バイパスルーターのトラフィックは同じLANインターフェースを出入りするため、戻り経路の対称性とICMPリダイレクトは個別に処理する必要があります。
• DNS、透過プロキシ、DHCPゲートウェイを結合した場合、Fail-Openを設計する必要があります。プロキシが故障しても機能低下可能とし、家庭全体のネットワーク断線を防ぐ必要があります。
• 重要なワークステーションはメインルーターに直接接続し、独自のTUNを実行することで、家庭全体の透過プロキシから障害ドメインを分離できます。
• 設定は1つの真のソースから派生させるべきであり、ターゲット側は自前のDNS、TUN、およびインバウンド設定の違いのみを維持します。

1. 物理トポロジー

光モデムは光電変換のみを行い（ブリッジモード、PPPoE接続なし、ルーティングなし、NATなし）、パブリックIPはメインルーターのPPPoEインターフェースに直接接続され、二重NATは発生しません。家庭は約120m²の4部屋構成で、単一APではすべての部屋（特に主寝室と次寝室は2つの耐力壁で隔てられている）をカバーできません。4つのAPによる有線Meshで死角をカバーし、統一されたSSIDでシームレスなローミングを実現します。すべてのAPは有線バックホールを使用し、無線帯域幅を占有しません。

2. Meshネットワーク

無線側では、メインのSSID（5 GHz、日常デバイス用）と独立した2.4 GHz IoT用SSIDの2つを使用します。IoTネットワークを非表示にするかどうかはセキュリティ境界を構成するものではありません。真の分離は、ゲストネットワーク、VLAN、またはファイアウォールポリシーによって行うべきです。

3. 主要ホスト

重要な設計：コアワークステーション（.8）の静的ゲートウェイはメインルーター（.1）を指しており、バイパスルーターの透過プロキシの影響を受けません。独自にTUNモードのmihomoを実行し、実際のアドレスを返すDNSを使用するため、通常の家庭デバイスとは2つの独立した障害ドメインを形成します。

4. DHCPとDNS

• ゲートウェイ⁠：DHCPはデフォルトで .7（N100）を配布し、通常デバイスはバイパスルーター経由で転送されます。コアワークステーションは例外で、静的ゲートウェイは .1 を指します。
• DNS：DHCPは .7（N100上のAdGuard Home）のみを公開します。パブリックDNSを「バックアップ」として同時に配布しないでください。クライアントはメインDNSを迂回できるため、フィルタリングとトラフィック分割の結果が予測不可能になります。コンポーネント障害時には、Fail-Openによって :53 が一時的に引き継がれます。
• リース時間⁠：1〜2時間。ゲートウェイ設定変更後の収束を早めるために短いリース時間を使用しますが、ゲートウェイの冗長性を代替するものではありません。
• アドレスプール⁠：192.168.31.5–250。

通常時のDNSリンク

5. トラフィックパス

通常モード

① 中国本土IPはファイアウォール層でreturnされ、物理的にmihomoに入らない⁠——中国本土へのトラフィックのハード保護。単一ネットワークインターフェースのヘアピン（同じ br-lan を出入り）で .1 に転送する場合、⁠必ず MASQUERADE でソースを .7 に変更する必要があります⁠。そうしないと、戻り経路の非対称性によりネットワークが即座に切断されます。

② fake-ip で geosite の CN ドメインにマッチし漏れた場合⁠（198.18.0.0/15 アドレスを取得）は、mihomo に入ります。ルール末尾の GEOIP,CN,DIRECT により、実際のアドレスに解決された後にフォールバックできます。コアワークステーションは独自の TUN と実際のアドレス DNS を使用するため、このパスに依存しません。

Fail-Open モード（mihomo/AdGuard 障害時）

ここでの Fail-Open には明確な境界があります。これは N100 上で実行可能なデーモンに依存しており、mihomo または AdGuard Home の終了、ハングアップなどのソフトウェア障害のみをカバーします。N100 の電源断、カーネルパニック、または LAN リンク断の場合は、.7 がデフォルトゲートウェイとして全体として到達不能になり、通常クライアントのネットワーク断続を引き起こします。この層の障害をカバーするには、VRRP/デュアルホットスタンバイ、またはメインルーターのヘルスチェックによるDHCPゲートウェイの自動変更が必要です。現在のアーキテクチャでは実装されていません。

6. トラフィック分割戦略と中国本土トラフィック保護

以前、CN ドメインが geosite にマッチし漏れたことにより MATCH,PROXY → 米国ノード経由で中国本土サーバーに再接続 → GFW が「中国本土へのトラフィック」として認識し VPS IP をブロックするという事象が発生しました。現在は二重保護を採用しています：

第一層（ハード、ファイアウォール）: bypass_china_mainland_ip=1(v4) により nft china_ip 集合（約3.7k chnroute）を埋めます。中国本土IPはprerouting段階で return され、物理的にmihomoに到達できず、ドメインがgeositeにマッチするかどうかとは無関係です。

• 単一ネットワークインターフェースのヘアピンでは、table inet bypass_masq により転送トラフィックを MASQUERADE でソースを .7 に変更する必要があります。
• v6 は現時点でファイアウォールバイパスを無効にしています（v6 のヘアピン失敗を避けるため）。v6 の CN は mihomo の GEOIP,CN でフォールバックします。

第二層（フォールバック、mihomo ルール）: ルール末尾に GEOSITE,cn,DIRECT → GEOIP,CN,DIRECT → MATCH,PROXY を配置します。fake-ip で漏れた CN ドメインが mihomo に入ると、GEOIP,CN により実際の IP に解決されてブロックされます。

重要な sysctl 設定

出国回線

3台のVPSが異なるネットワーク回線に分散配置されており、レイテンシと安定性の差は中国本土への回線のQoSレベルに起因します：

ノードとプロトコルの選択方法

アーキテクチャドキュメントにベンダー、プラン価格、または特定のベンチマーク結果を固定しません。これらの情報は変化が速く、異なる地域、プロバイダ、夕暮れ時帯の体験を代表するものではありません。より確実な選択方法は、自前のアクセスネットワークで継続的に測定することです：

1. 平日の昼間と夕暮れ時帯のRTT、ジッター、パケット損失率、TCP/UDPスループットを個別に記録します。
2. 主力ノードと予備ノードは異なるアップストリームまたは異なるルーティングを選択し、一見すると複数のノードがあるように見えても、実際には同じ障害ドメインを共有しないようにします。
3. TCPとUDPプロトコルの両方をテストします。プロトコルのパフォーマンスはリンク品質に依存するため、1回のレイテンシテストから長期的な結論を導き出せないことに注意してください。
4. スイッチング戦略はビジネス体験を考慮に入れる必要があります。ノード品質が近い場合は自動切り替えが適しています。品質差が大きい場合は、手動切り替えの方がフォールダウンを発見しやすいです。
5. 生データをPrometheus Blackbox Exporterまたは同様のプローブに保存し、瞬間的な最小値ではなく1週間以上の分位数に基づいて決定します。

このネットワークでは手動Selectorを選択しています：主力ノードに異常が発生するとアラートが発信され、保守担当者が確認後に切り替えます。代償は復旧が完全には自動化されないことですが、利点は「接続可能だが体験が非常に悪い」ノードに静かにフォールダウンしないことです。

高速化項目

• tcp-concurrent: true: 並列接続で複数のIPを解決し、最速のものを選択します。
• QUIC拒否ルールを意図的に保持: AND,(DST-PORT,443),(NETWORK,UDP),(NOT,GEOSITE,cn),REJECT により、外部のHTTP/3をh2に強制し、「QUIC-over-Hy2 アイドル後のリソース共有フリーズ」を治療します。解放すると再発します。

IPv6 でハードバイパスを開けない理由⁠: v4 ハードバイパスの鍵はヘアピン MASQUERADE（ソースを .7 に変更して戻り経路の対称性を保証）ですが、この操作には N100 に固定された内網 v4 アドレスが必要です。しかし、v6 アドレスは SLAAC により動的に割り当てられるため、安定した内網アドレスによる SNAT アンカーがありません——v6 上ではヘアピンの戻り経路対称性を信頼できる形で実現できず、無理に開くとランダムな通信断を引き起こします。そのため、v6 の CN は現在 mihomo ルール層の GEOIP,CN によるフォールバックのみで、ファイアウォールの prerouting ハードバイパスは使用しません。 監視⁠：N100、コアワークステーション、メインルーターの主要コンポーネントは Prometheus + Grafana に接続されています。詳細は monitoring.md を参照してください。ノードの可用性は Prometheus Blackbox Exporter によってプローブされます。ここでは、手動確認後の切り替え戦略を保持しています。

7. N100 主要コンポーネント

N100 移行の動機とハードウェア選定：以前はデスクトップ機の WiFi 上でバイパスルーターを実行していましたが、WiFi のジッターにより家庭全体のネットワークが断続していました。N100（低消費電力 x86、iStoreOS、単一ギガビットポート）に交換し、書斎 AP LAN ポートに有線バイパスルーターとして接続することで、WiFi から切り離されました。

8. nftables 構造

処理順序⁠（prerouting → forward → postrouting）：

table inet fw4 (OpenWrt ファイアウォール)

• forward: policy drop; TUNトラフィック + LAN→WAN 転送を許可
• srcnat_lan: docker MASQUERADE

table inet nikki (透過プロキシルール)

• china_ip 集合: 約3.7k chnroute CIDR（bypass_china_mainland_ip=1 により埋められる）
• dstnat / mangle_prerouting_lan: 中国本土IP / プライベートネットワーク / 198.18 にマッチ → return によりバイパス; その他は DNAT TCP→:7891 または TUN マーク
• mangle_output: 本機発信 → TUN
• fail-open 時はテーブル全体を削除

table inet bypass_masq (CN-IP バイパスのヘアピン SNAT)

• postrouting(nat hook、priority srcnat+5): iifname br-lan oifname br-lan ip daddr != {プライベート+198.18+マルチキャスト} masquerade
• china_ip によりバイパスされ、.1 に転送して戻す必要があるパブリック CN 直結トラフィックのみマッチし、ソースを .7 に変更して戻り経路の対称性を保証
• table nikki とは独立しており、nikki の再起動に影響されません⁠。永続化は firewall.bypass_masq include により行われます。

table inet failopen (障害注入、復旧時に削除)

• srcnat：MASQUERADE <lan-cidr> → 非ローカル
• dns: DNAT :53 → .1:53

9. セルフホスティングサービスと障害ドメイン

以下のサービスは現在、コアワークステーションの Wi-Fi に依存しています。wifi-watchdog（systemd timer）は、一時的なRFまたはドライバの異常を回復できますが、無線リンクを高可用性インフラストラクチャに変えることはできません。長期間稼働するエントリポイントと監視サービスは、有線ノードに移行する必要があります。

10. デーモン

設定派生パイプライン

家庭内には mihomo 設定が必要な場所が3箇所あります：コアワークステーション（TUN 自前プロキシ）、N100（家庭全体透過プロキシ）、およびモバイル端末用インポートファイル。これら3つのノードリスト、プロキシグループ、トラフィック分割ルールは一致している必要がありますが、DNS、TUN、入力方法はそれぞれ異なります。個別に維持すると必然的にドリフトが発生します。

方案⁠：<config-root>/config.yaml のみを手動で編集し、proxies、proxy-groups、および rules を含めます。2つのtimer駆動スクリプトがこれらからターゲット設定を派生させます。

#1 本機⁠: 真のソースを直接使用します。TUNデバイス Meta + ローカル AdGuard + fake-ip + controller。

#2 N100 バイパスルーター (sync-mihomo-to-router.sh, timer 03:45):

• 真のソースから proxies/proxy-groups/rules の3セクションのみを抽出 → /etc/nikki/profiles/home.yaml
• 本機で mihomo -t により真のソースを検証 → scp で N100 に転送 → nikki -t により検証 → 旧ファイルバックアップ（タイムスタンプ付き）→ 検証失敗時は自動ロールバック → Nikki をリロード
• DNS/TUN/sniffer は N100 側のローカル UCI mixin により注入され、プロファイルには含まれません——これらはターゲット側固有のものであり、真のソースから上書きされるべきではありません。

#3 モバイル端末設定 (sync-subscribe.sh):

• clash.yaml(Clash インポート用) + sub.txt(v2rayN base64 共有リンク) を出力
• 本機依存の除去: external-controller+secret（漏洩すると制御される）、tun 全体（スマホは不要）、nameserver:127.0.0.1（ローミングデバイスでは到達不可）、PROCESS-NAME ルール（スマホでは絶対にマッチしない）を削除
• DNS を fake-ip + パブリック DoH に置き換え、国外ドメインは出口解析を使用して漏洩を防ぐ
• パブリック経由で配布する場合、エントリポイントには独立したドメインと予測不可能なパストークンを使用します。Webサーバーは派生ファイルのみを公開し、真のソース、コントローラーキー、またはディレクトリリストは公開しません。

2つのtimerは実行時間をずらして、ターゲット設定の同時読み書きを避けます。真のソースを変更した後、対応するスクリプトを手動で実行することもできます。スクリプトは冪等性を保ち、置換前に構文検証とバックアップを完了させる必要があります。

11. 運用後の検証チェックリスト

まず、バイパスルーターのアドレスを環境変数に設定し、サンプルコマンドに実際のアドレスが出現しないようにします：

SIDE_ROUTER_IP=192.168.31.7

通常モードでは、少なくとも以下の項目を検証します：

# クライアントのデフォルトルートがバイパスルーターを指しているか確認
ip route show default

# DNS が AdGuard のみを通過し、予期される fake-ip 応答を取得できるか確認
dig @"$SIDE_ROUTER_IP" example.com

# バイパスルーター上で転送、リダイレクト、SNAT ルールが存在することを確認
ssh "root@$SIDE_ROUTER_IP" 'nft list ruleset'

# 2つのプロセスとそのリスニングポートが生きているか確認
ssh "root@$SIDE_ROUTER_IP" 'pgrep -a mihomo; ss -lntup'

Fail-Open は、障害発生後に推測するのではなく、保守ウィンドウで演習する必要があります。mihomo と AdGuard Home を個別に停止し、デーモンが透過プロキシルールを取消し、DNS を引き継ぎ、クライアントが依然として直結できることを確認します。その後、サービスを復旧し、ルールが重複して注入されていないことを確認します。最後に、N100 の電源断を個別にシミュレートし、監視が実際にアラートを出し、現在のアーキテクチャ下では通常クライアントがネットワーク断続するという事実を受け入れることを確認します。

12. 既知のリスク

詳細な評価と復旧手順は network-recovery.md を参照してください。

変更履歴

関連ドキュメント

• rathole-tunnel.md — トンネルホーム方案
• network-recovery.md — 障害復旧マニュアル
• monitoring.md — 監視アーキテクチャ