---
title: ネットワーク障害復旧マニュアル
url: https://doc.liz6.com/ja/homelab/network-recovery
locale: ja
area: homelab
tags:
- homelab
date: 2026-07-01
modified: 2026-07-16
description: 適用トポロジ v2.1（N100 バイパスルーター + CN-IP ファイアウォールバイパス）。本ドキュメントでは、深刻度順に5つの障害シナリオを分類し、各シナリオについて症状、自動復旧メカニズム、手動介入手順を示し、末尾にロールバック手順を付録しています。アラートカバレッジについては monitoring.md を参照してください。Grafana と Bark の13ルールが、障害発生時に iPhone へプッシュ通知を送信します。
---

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

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

## リスク評価総表

| # | リスク | 深刻度 | 自動緩和 | 残余リスク |
|---|------|--------|----------|----------|
| 1 | mihomo/AdGuard プロセスのハング | 🔴→🟢 | N100 fail-open daemon、30秒で自動ダイレクト接続へ切り替え | 30秒の検出ウィンドウ |
| 2 | N100 の停電 | 🔴→🟢 | BIOS 通電時自動起動、全コンポーネントの自動起動、約2分で復旧 | 起動中のプロキシなし |
| 3 | N100 OS のクラッシュ（カーネルパニック/ディスク障害） | 🟡 | なし、手動で DHCP ゲートウェイを .1 に切り替え | 発生確率は極めて低いが、単一障害点あり |
| 4 | li-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 もハングしている場合）:

```bash
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–3 | `nmcli connection down/up` (再接続) | 約10秒 |
| 4–6 | `nmcli radio off/on` + rfkill (RF層) | 約20秒 |
| 7+ | `modprobe -r mt7925e → modprobe` (ドライバー再読み込み) | 約25秒 |

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

**手動復旧**（watchdog が機能しない場合）:

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

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

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

```bash
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`

## 関連ドキュメント

- [network-architecture.md](network-architecture.md) — 完全なトポロジと nftables 構造
- [rathole-tunnel.md](rathole-tunnel.md) — トンネル方式と障害対応
- [monitoring.md](monitoring.md) — モニタリングアラート (Bark、iPhone へのプッシュ通知)