7 分で読了 #homelab
このページの目次

ネットワーク障害復旧マニュアル

適用トポロジ v2.1(N100 バイパスルーター + CN-IP ファイアウォールバイパス)。本ドキュメントでは、深刻度順に5つの障害シナリオを分類し、各シナリオについて症状、自動復旧メカニズム、手動介入手順を示し、末尾にロールバック手順を付録しています。アラートカバレッジについては monitoring.md を参照してください。Grafana と Bark の13ルールが、障害発生時に iPhone へプッシュ通知を送信します。

リスク評価総表

#リスク深刻度自動緩和残余リスク
1mihomo/AdGuard プロセスのハング🔴→🟢N100 fail-open daemon、30秒で自動ダイレクト接続へ切り替え30秒の検出ウィンドウ
2N100 の停電🔴→🟢BIOS 通電時自動起動、全コンポーネントの自動起動、約2分で復旧起動中のプロキシなし
3N100 OS のクラッシュ(カーネルパニック/ディスク障害)🟡なし、手動で DHCP ゲートウェイを .1 に切り替え発生確率は極めて低いが、単一障害点あり
4li-home-0 WiFi 断線🔴→🟢wifi-watchdog による階層型自己修復(再接続→RF→ドライバー再読み込み)約25秒の通信断
5小米メインルーターのハング🔴なしPPPoE/NAT/DHCP/Mesh が一台に集約されており、ホットスタンバイなし

シナリオ 1: N100 での mihomo/AdGuard プロセスハング

自動動作⁠: fail-open daemon (procd) は mihomo API :9090 を60秒ごとにプローブし、3回連続失敗すると table inet nikki を削除し table inet failopen を注入し、全世帯の接続をダイレクト接続へ切り替えます。mihomo が復旧すると自動的に元の設定へ戻ります。

手動介入⁠(daemon もハングしている場合):

ssh root@192.168.31.7

# 手動 fail-open
nft delete table inet nikki
nft add table inet failopen
nft add chain inet failopen srcnat '{ type nat hook postrouting priority srcnat - 1; policy accept; }'
nft add rule inet failopen srcnat ip saddr 192.168.31.0/24 ip daddr != 192.168.31.0/24 masquerade
nft add chain inet failopen dns '{ type nat hook prerouting priority dstnat - 1; policy accept; }'
nft add rule inet failopen dns ip daddr 192.168.31.7 udp dport 53 dnat to 192.168.31.1:53

# 復旧後
nft delete table inet failopen
/etc/init.d/nikki restart

table inet bypass_masq は処理不要です。nikki/failopen とは独立しており、fail-open 時にハーフオープン SNAT が発生しても冗長なだけで競合しません。nikki の再起動後、china_ip は自動的に再設定されます。

シナリオ 2: N100 の停電

自動動作⁠: 復電 → BIOS 通電時自動起動 → 起動チェーン: S99nikki (TUN+透明プロキシ) → S99nikki-failopen (60秒の猶予) → docker adguardhome (unless-stopped)。約2分で復旧し、人的介入は不要です。

シナリオ 3: N100 OS のクラッシュ(カーネルパニック/ディスク障害)

症状⁠: 192.168.31.7 への ping が応答せず、長時間回復しない。停電とは異なり、N100 は通電時自動起動するため、3分以上応答がない場合は OS クラッシュまたはハードウェア障害を示唆します。

手動復旧⁠:

  1. ブラウザで http://192.168.31.1/ を開き、小米管理画面にログイン
  2. 共通設定 → ローカルネットワーク設定 → ゲートウェイ/DNS を .7 から .1 に変更
  3. 保存し、クライアントのリース更新または再起動を待つ

N100 復旧後⁠: 起動完了を確認(2分)→ 小米管理画面でゲートウェイ/DNS を .7 に戻す。

シナリオ 4: li-home-0 WiFi 断線

自動動作⁠: wifi-watchdog (systemd timer、30秒ごとに .1 へ ping) による階層型復旧:

連続失敗回数動作所要時間
1–3nmcli connection down/up (再接続)約10秒
4–6nmcli radio off/on + rfkill (RF層)約20秒
7+modprobe -r mt7925e → modprobe (ドライバー再読み込み)約25秒

復旧後、カウンターはゼロに戻ります。ログ: journalctl -u wifi-watchdog.service

手動復旧⁠(watchdog が機能しない場合):

sudo nmcli radio wifi off && sleep 2 && sudo nmcli radio wifi on
# またはドライバー再読み込み
sudo modprobe -r mt7925e && sudo modprobe mt7925e

長期的対策⁠: DERP/rathole などの高可用性サービスを有線接続の N100 へ移行し、WiFi の単一障害点を解消する。

シナリオ 5: メインルーターのハング

ping 192.168.31.1
# 応答なし → 電源/インジケータランプを確認
# 応答ありだが外網不通 → ルーター管理画面で PPPoE 接続状態を確認

PPPoE/NAT/DHCP/Mesh の全機能が一台の小米ルーターに集約されており、ホットスタンバイは存在しません。これが全屋ネットワークにおける最大の単一障害点です。現時点での唯一の緩和策は、光モデムをブリッジモードにして二重 NAT を回避することであり、メインルーターがハングしても光モデムの設定は保持されます。

ロールバック手順

N100 バイパスルーター全体で問題が発生した場合、ダイレクト接続または旧バイパスルーターへ戻ります:

  1. メインルーターの DHCP ゲートウェイ/DNS を .1 (ダイレクト接続) または .8 (li-home-0 旧バイパスルーター) に戻す
  2. li-home-0 バイパスルーターを復旧させる場合: sudo systemctl start mihomo
  3. N100 をシャットダウン: ssh root@192.168.31.7 poweroff

関連ドキュメント