家庭ネットワークアーキテクチャドキュメント

一言⁠: 電信 GPON ブリッジ → 小米メインルーター PPPoE ダイアルアップ → 家中有線 Mesh(4 AP) → N100 単一ポート サイドルーター (mihomo + AdGuard + CN-IP ハードウェアバイパス) → li-home-0 がメインルーターに直接接続 + rathole で外部公開。家中デフォルトはプロキシ経由、コアデスクトップはダイレクト接続。

トポロジバージョン v2.1、本稿は家中ネットワークの運用真源です。

一、物理トポロジ

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

二、Mesh ネットワーク

ノード	IP	ハードウェア	位置	カバレッジの難点	バックホール
root	.1	RP01	玄関	リビング中央	—
leaf	.62	RC06	リビング	玄関エリアをカバー	有線
leaf	.67	RP03	主寝室	二つの耐力壁で隔てられる	有線
leaf	.80	RP03	書斎	コアデバイスエリア	有線
leaf	.227	RP03	次寝室	最遠端、単一 AP では信号なし	有線

SSID: 308_6G_WIFI(5G、日常使用) + 非表示(2.4G、IoT 専用)。

三、主要ホスト

デバイス	IP	役割	接続	OS
ONT	— (ブリッジ、IP なし)	光電変換	光ファイバー入力、イーサネット出力	電信 GPON
小米メインルーター	.1	PPPoE/NAT/DHCP/Mesh ルート	WAN は光モデムに接続	MiWiFi(RP01)
li-home-router	.7	サドルーター: 透過プロキシ + DNS(AdGuard)	有線単一ポート、書斎 AP LAN に接続	iStoreOS(N100)
li-home-0	.8	デスクトップ: 開発 + 外部サービス、⁠静的 IP ゲートウェイ→.1、プロキシ経由しない	WiFi(MT7927)、書斎 AP に接続	Gentoo
li-home-1	.9	退役したサイドルーター、SSH のみ	WiFi	Win11

重要な設計: li-home-0(.8) はゲートウェイをメインルーター(.1) に静的に設定し、サイドルーターの透過プロキシはこれをカバーしません——このマシンは TUN モードの mihomo で自身をプロキシし、DNS は実 IP アーキテクチャであり、家中の他のデバイスとは異なるプロキシパスを使用します。

四、DHCP と DNS

• ゲートウェイ⁠: DHCP はデフォルトで .7(N100) を発行し、家中のトラフィックはサイドルーター経由でプロキシされます。例外: li-home-0(.8) はゲートウェイを .1 に静的に設定しています。
• DNS: メインは .7(N100 AdGuard)、予備はパブリック DNS。
• リース期間⁠: 1〜2 時間。短縮することで、メインルーター障害時に DHCP 回復を加速します。
• アドレスプール⁠: 192.168.31.5–250。

通常 DNS パス

五、トラフィックパス

通常モード

① 中国本土 IP はファイアウォール層で return され、物理的に mihomo に進入しません⁠——帰国トラフィックはハードウェアで保護されます。単一ポートのヘアピン（同じ br-lan での出入力）で .1 に転送する場合、⁠必ず MASQUERADE でソースを .7 に変更する必要があります⁠。そうしないと、戻り経路の非対称性によりネットワークが即座に切断されます。 ② fake-ip で geosite の CN ドメインのマッチ漏れ⁠(198.18.x を取得)しても mihomo に進入し、ルール末尾の GEOIP,CN,DIRECT(実 IP を解決)で二重に保護されます。 li-home-0 は TUN 自己プロキシを個別に使用し、DNS は実 IP を返し、fake-ip の曖昧さがなく、帰国は元々安定しています。

Fail-Open モード(mihomo/AdGuard がダウンした場合)

六、振り分けポリシーと帰国トラフィック保護

以前、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

パラメータ	値	理由
net.ipv4.conf.*.send_redirects	0	そうしないと .7 が ICMP リダイレクトを送信し、クライアントが .7 を迂回して .1 に直接接続し、「二重パス」を形成します: 同じターゲットに対してクライアントがダイレクト接続 + mihomo がダイアルアップを代行し、メインルーターの同じパブリック IP で NAT 後、サーバーで PAWS によりタイムスタンプの小さい方が破棄されます → i/o タイムアウト嵐(闲魚などのアプリが固まる真の犯人)。⁠すべての片腕/ヘアピンサイドルーターソリューションに適用されます⁠、本機だけでなく
net.ipv4.conf.*.rp_filter	0	非対称を許可し、ヘアピンと連携

出国ライン

3台のVPSが異なるネットワークラインに分散されており、レイテンシと安定性の差は帰国ラインのQoSレベルに由来します:

ライン	正式名称	優先度	特徴	適した用途
CN2 GIA	China Telecom Next Gen Carrier	最高	電信最高級ライン、全程 CN2 骨格網で 163 網を経由せず、QoS が最も低く、夕暮れ時に速度がほとんど低下しない	レイテンシ/安定性に要求がある主力ノード
9929	China Unicom Premium	中高	联通精品ライン、CN2 GIA に似ているが联通骨格網を使用、北方联通ブロードバンドユーザーに最適	联通ユーザーのダイレクト接続に最適
4837	China Unicom Standard	普通	联通標準国際ライン、夕暮れ時に混雑が顕著だが価格が安い	予備ライン/コールドバックアップ/予算重視

本機ノード

ノード	ライン	プロトコル	レイテンシ	備考
US3-Hy2(主選択)	CN2 GIA	Hysteria2(UDP+Brutal)	136ms	主力、夕暮れ時に安定; 損失耐性
US2-Hy2	9929	Hysteria2	168ms	联通ライン、北方で高速
US1-Hy2	4837	Hysteria2	213ms	廉価な予備ライン、夕暮れ時に低速
US*/REALITY	同上	VLESS+REALITY(TCP)	420–569ms	GFW 通過時に QoS/損失により遅延が拡大、極端なバックアップのみ

Hy2 は UDP+Brutal で損失に強く、REALITY は TCP です——GFW 通過時、TCP は QoS による損失で再送信され遅延が拡大しますが、UDP はそれを回避します。そのため、3つの REALITY ノードの遅延は Hy2 の 3 倍で、実質的に飾りです。 PROXY は手動 Selector で US3-Hy2 に固定されており、Auto は使用しません——主選択がダウンした場合、手動で切り替える方が望ましく、mihomo が自動で低速ノードに切り替えるのは避けます（切り替えるとユーザー体験は「ネットが炸裂したが全滅ではない」——調査がさらに困難になります）。

VPS プロバイダ参考

ラインは重要ですが、VPS プロバイダも重要です——同じ CN2 GIA でも、異なる業者のオーバーサブスクライブ率、ライン品質、中国本土への TCP ハンドシェイク損失率は大きく異なります。個人的な段階的調査結果（価格は時間とともに変動するため、参考用です）:

優良(主力推奨):

業者	ライン	参考価格	特徴
DMIT	CN2 GIA	~$12–15/月(1C1G)	CN2 GIA の老舗、ラインが非常に安定、中国本土への損失はほぼ 0; 高いが価値あり
搬瓦工/老挖机⁠(BandwagonHost)	CN2 GIA	~$50–100/年(CN2 GIA パック)	老舗、CN2 GIA パックの費用対効果が高く、DIA ライン; 在庫切れが多いので待ちが必要
Sharon(莎伦)	CN2 GIA/9929	~$8–12/月	小規模だがラインが堅実、9929 パックの費用対効果が突出

費用対効果(使用可能):

業者	ライン	参考価格	特徴
丽萨主机	4837/CN2 混合	~$5–8/月	ラインは普通(4837 が大半)、夕暮れ時に遅くなるが、遅延に要求のない予備ラインには十分
RackNerd	標準国際	~$15–30/年	非常に安いが帰国ラインが悪く、コールドバックアップ/リアルタイムでない用途にのみ適す

廉価(予備ライン/実験):

業者	ライン	参考価格	特徴
野草云	4837	~$3–5/月	安い、夕暮れ時に混雑が深刻、最後のフォールバックにのみ適す
CloudCone	標準国際	~$20–30/年	超低額年払い、OOKLA スコアは良いが帰国 TCP は悪く、コールドバックアップのみ

選択原則⁠: 主力ノードでお金をケチらない——CN2 GIA は DMIT または搬瓦工を使用し、安定性が速度です。予備ラインは 9929(联通が良い)または 4837(安い)を使用し、REALITY は最も安いノードにコールドバックアップとして接続。本機の US3 は DMIT CN2 GIA、US2 は 9929、US1 は 4837 の廉価機に配置。

高速化項目

• 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、li-home-0、メインルーターの主要コンポーネントは Prometheus + Grafana に接続されています。詳細は monitoring.md を参照してください。ノード可用性モニタリングは Prometheus Blackbox Exporter によるプローブで行われますが、切り替えは手動です（Auto を使用しないのは意図的な選択です——主選択がダウンした場合、手動で切り替える方が望ましく、自動で低速ノードに切り替えるのは避けます）。

七、N100 主要コンポーネント

コンポーネント	アドレス/パス	説明
mihomo カーネル	/usr/bin/mihomo, procd via /etc/init.d/nikki	透過プロキシ + TUN
mihomo API	127.0.0.1:9090	健康診断
mihomo mixed	:7890(SOCKS5+HTTP)	明示的プロキシエントリ
mihomo redir	:7891	透過プロキシ リダイレクト入力
mihomo DNS	:1053(fake-ip)	AdGuard アップストリーム
Nikki dashboard	http://.7:9090/ui	Web コンソール
AdGuard Home	docker ホストネットワーク、http://.7:8083	DNS 広告フィルタリング、アップストリーム→:1053
failopen daemon	/usr/local/sbin/nikki-failopen.sh, procd	健康診断 + 自動 fail-open
CN バイパス SNAT	/etc/nikki/scripts/bypass-masq.{nft,sh} + firewall include	ヘアピン masquerade、永続化

N100 移行の動機とハードウェア選択: 以前はサイドルーターがデスクトップの WiFi で動作しており、WiFi のジッターで家中がネットワーク切断していました。N100(低消費電力 x86、iStoreOS、単一ギガビットポート)に交換し、書斎 AP LAN ポートに有線サイドルーターとして接続することで、WiFi と切り離されました。

八、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、優先度 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 192.168.31.0/24 → 非ローカル
• dns: DNAT :53 → .1:53

九、外部サービス(li-home-0)

これらのサービスはすべて li-home-0 の WiFi に依存しています。wifi-watchdog(systemd timer 30秒)が無線/ドライバの異常を自動的に回復します——一時的なジッターは自己回復可能です。長期高可用性サービスは有線の N100 に移行すべきです。

サービス	用途	可用性
DERP	Tailscale リレー	高
rathole	内網透過 (rathole-tunnel.md 参照)	高
paste/mdserve	ノート共有	中
Prometheus	モニタリング収集	中
sunshine	ゲームストリーミング	低
ローカル LLM	AI 推論 (local-llm.md 参照)	低

十、デーモン

デーモン	位置	シナリオ
nikki-failopen	N100(procd)	mihomo/AdGuard プロセス異常
通電時自動起動	N100(BIOS)	停電復旧
wifi-watchdog	li-home-0(systemd timer)	WiFi ドライバ/無線異常
sync-mihomo-to-router	li-home-0(systemd timer, 03:45)	真源→サイドルーター設定のドリフト
sync-subscribe	li-home-0(systemd timer, 03:30)	真源→パブリックサブスクライブ設定のドリフト

設定派生パイプライン

家中には mihomo 設定が必要な場所が三箇所あります: 本機(TUN 自己プロキシ)、N100(家中透過プロキシ)、パブリックサブスクライブ(スマホローミング用インポート)。これら三つのノードリスト、プロキシグループ、振り分けルールは一致している必要がありますが、DNS、TUN、入力方法はそれぞれ異なります。それぞれが独立して維持すると必然的にドリフトします。

ソリューション⁠: 単一の真源(/opt/mihomo/mihomo_config/config.yaml、手動編集する唯一のファイルで、proxies/groups/rules の三つのセクションを含む) + 二つの timer 駆動の派生スクリプト。

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

#2 N100 サドルーター(sync-mihomo-to-router.sh、timer 03:45):

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

#3 パブリックサブスクライブ⁠(sync-subscribe.sh、timer 03:30):

• clash.yaml(Clash インポート用) + sub.txt(v2rayN base64 共有リンク) を出力
• 本機化除去: external-controller+secret(漏洩すると制御される)、tun 全体セクション(スマホは不要)、nameserver:127.0.0.1(ローミングデバイスでは到達できない)、PROCESS-NAME ルール(スマホでは絶対にマッチしない) を削除
• DNS を fake-ip + パブリック DoH に置き換え、国外ドメインは出口で解決してリークを防ぐ
• エントリ: https://subscribe.liz6.com(Caddy file_server、パストークン認証)

二つの timer は 15 分ずらして、N100 への同時書き込みを避けます。真源を変更して即座に有効化したい場合は、対応するスクリプトを手動で実行すればよく、スクリプトは冪等です。

十一、既知のリスク

リスク	影響	緩和策
li-home-0 WiFi 単一障害点	rathole/DERP などの高可用性サービスがすべてダウン	長期有線 N100 への移行; wifi-watchdog 30秒自己回復は短期的な止血策
N100 単一ポートヘアピン	片腕トポロジでは戻り経路の非対称性により必ず切断される	MASQUERADE + bypass_masq nft テーブルで戻り経路の対称性を保証
mihomo/AdGuard プロセスダウン	家中ネットワーク切断(DHCP ゲートウェイはまだ .7 を指している)	nikki-failopen(procd) によるプロセスレベルの自己回復
メインルーターハードウェア/ファームウェア障害	家中ネットワーク切断(PPPoE+NAT+DHCP すべてダウン)	熱冗備はなし; 元々 N100 をメインルーターにする計画だったが未着工
光モデムブリッジ	ONT は光電変換のみを行い、ダイアルアップ・ルーティング・NAT 不可、パブリック IP はメインルーターに直接接続	基本的に障害源ではなく、二重 NAT は発生しない

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

変更履歴

日付	変更
2026-06-21	N100 サドルーター稼働、li-home-0 サドルーター退役; DHCP ゲートウェイ/DNS を .8 から .7 に切替; N100 fail-open + li-home-0 wifi-watchdog 展開
2026-06-24	パブリックサブスクライブ修正: 本機 config をそのままコピーすると本機 DNS+管理口 secret+tun が漏洩したため、sync-subscribe.sh に本機化除去消毒を追加; サドルーター profile を再実行して更新; sync-mihomo-to-router.timer を追加
2026-06-27	ICMP send_redirects を無効化: 闲魚などのアプリが固まる問題(二重パス PAWS 損失嵐の根本原因)を治療; CN-IP ファイアウォールバイパス上线(bypass_china_mainland_ip=1 + table inet bypass_masq); tcp-concurrent + CN DNS を平文 UDP 223.5.5.5 に変更; ノード洞察

関連ドキュメント

• rathole-tunnel.md — トンネルホームソリューション
• network-recovery.md — 障害復旧マニュアル
• monitoring.md — モニタリングアーキテクチャ