ネットワーク障害復旧マニュアル
このページの目次
適用環境：メインルーター 192.168.31.1、N100 サブルーター 192.168.31.7、クライアントは通常、ゲートウェイとDNSを .7 に設定します。まず必要な接続を復旧させ、その後プロキシまたはDNSの障害を特定します。ネットワークアーキテクチャで正常なパスを説明し、モニタリングでアラームの発生源を説明します。
設定照合：2026-09-12。 以下の自動動作は、N100 の /usr/local/sbin/nikki-failopen.sh、本機の wifi-watchdog.service、および実際の実行スクリプトの読み取り専用照合に基づいています。今回の照合ではネットワーク遮断テストは実行していません。ポーリング間隔、動作所要時間、実際のネットワーク遮断時間は異なる尺度です。
どのレイヤーで切断されているかをまず判断する
影響を受けたクライアントで現在のIP、デフォルトゲートウェイ、DNSを確認し、その後 .1 と .7 をそれぞれプローブします。既存の接続を持つウェブページが開けるだけでは、新しい接続やDNSが正常であることを証明できません。
| 観察 | 次のチェック | 復旧パス |
|---|---|---|
.1 と .7 の両方に到達不可 | 本機のWi-Fi/イーサネット、アドレス、別のデバイス、メインルーターの電源 | まずLAN接続を復旧させる |
.1 は到達可能、.7 は到達不可 | N100 の電源、スイッチポート、アドレス、ローカルコンソール | 一時的にクライアントのゲートウェイとDNSを .1 に変更する |
.7 は到達可能、ドメイン解決に失敗 | .7 と .1 にそれぞれクエリを実行し、AdGuard と mihomo のログを確認 | DNS またはプロキシ障害のブランチに従って処理 |
| DNS は正常、新しい外部接続に失敗 | メインルーターのWAN、mihomo ルーティング、ターゲット到達可能性 | ダイレクト接続とプロキシパスを比較 |
ping の失敗は、単に今回のICMPプローブに応答がなかったことを示すだけです。ファイアウォール、アドレス変更、レイヤー2接続、デバイスの起動、システム障害などが原因となり得ます。「3分以上」という事象だけでカーネルクラッシュと診断することはできません。同じサブネット内の別のデバイス、SSH、ルーターのクライアントリスト、またはローカルコンソールで補足証拠を確認してください。詳細はネットワーク障害診断方法論を参照してください。
N100 の自動フォールバック：プロキシ障害とDNS障害は別々に見る
デーモンは procd によって管理され、起動後に 60秒 待機し、その後、各プローブラウンド終了後に 10秒 待機します。連続 3回 の失敗がアクションをトリガーします。プローブがほぼ即時に返される場合、安定して動作中の検知待機時間は約20〜30秒となり、さらにプローブと実行の所要時間が加算されます。スクリプトは curl --connect-timeout 3 のみを使用しており、リクエスト全体の --max-time は設定されていないため、30秒以内の切り替えを保証するものではありません。curl のタイムアウト説明は、接続フェーズと全体の転送期限を区別しています。
| ブランチ | 現在の健全性基準 | 連続失敗後のアクション | 復旧判定後のアクション |
|---|---|---|---|
| mihomo | 本機 :9090 が HTTP 200、401 または 403 を返す | table inet nikki を削除；table inet failopen を作成し、出口マスカレードを行い、.7:53 宛の UDP/TCP DNS を .1:53 に転送 | failopen テーブルを削除し、nikki を再起動して正常なルールを再構築し、状態フラグをクリーンアップ |
| AdGuard（プロキシ全体のフォールバック状態にない場合） | 本機 :8083 が 200 を返す、または 53ポートをリッスンしているプロセスが1つでも検出される | .7:53 宛の UDP/TCP DNS のみを本機 mihomo 127.0.0.1:1053 に転送し、プロキシルールを保持 | DNS リカバリルールと対応する状態フラグを削除 |
2行目は AdGuard をバイパスします。1行目こそがメインルーターへのダイレクト接続への切り戻しです。API の応答やポートのリッスンは生存信号に過ぎず、アップストリームDNS、プロキシノード、および実際のアプリケーション通信の復旧を証明するものではありません。AdGuard のポートフォールバック基準は比較的緩く、53ポートをリッスンしている別のプロセスが存在すると、健全と判定される可能性があります。
まずクライアントで独立したDNSクエリと新しい接続をテストし、その後 N100 で状態を観察します。以下のコマンドは状態のみを読み取ります：
# 管理端末から N100 にログインし、以下をその SSH セッション内で実行します。
テーブルや状態フラグが存在しないのは、単にそのモードが有効化されていないだけかもしれません。ルール、状態フラグ、および最近のログが一致しているか照合してから実際のリクエストを確認してください。テーブル削除コマンドを丸ごとコピーして削除しないでください。nikki テーブルを手動で削除したが、TCP DNS、出口 SNAT、または復旧状態フラグを見逃すと、2つ目の障害を引き起こす可能性があります。
自動復旧で回復しない場合、まず1台のクライアントをダイレクト接続にする
.1 のLANとWANが正常であり、N100 が復旧しない場合、クライアントの元の設定を記録し、デフォルトゲートウェイとDNSを同時に 192.168.31.1 に変更し、同じサブネット内で競合しないアドレスを保持します。DNS のみを変更しても応答しないゲートウェイをバイパスできません。ゲートウェイのみを変更しても、応答しない .7 へのクエリが続く可能性があります。
まず、そのクライアントがドメインを解決でき、期待されるダイレクト接続を確立できることを検証します。プロキシに依存する宛先は、ダイレクト接続モードでは利用できない場合があります。確認後、メインルーターのDHCP設定でゲートウェイとDNSを .7 から .1 に変更し、他のクライアントにリース更新を促します。既存のリースと静的設定は、DHCP設定を保存しただけでは直ちに変更されません。
N100 へのログインが可能で、デーモンが単に実行されていない場合は、手動のリカバリルールとサービスの競合がないことを確認してから起動します：
# N100 上で実行します。監視と自動ルール切り替えが始まります。
これには起動の猶予期間があり、全世帯への即時切り替えコマンドではありません。ルールと状態フラグが既に不一致の場合、ログとルール出力を保持し、クライアントのダイレクト接続を引き続き使用します。アーキテクチャドキュメントに従って所属コンポーネントを復旧させ、手動ルールと自動復旧の競合を避けてください。
N100 が修復された後、「2分間起動したから」というのを復旧の基準としてはいけません。まずプロキシ、DNS、正常なファイアウォールルール、およびデーモンログを確認し、テストクライアントのゲートウェイ/DNS を .7 に戻し、LAN、通常の外部ネットワーク、およびプロキシが必要なターゲットをそれぞれ検証します。通過後、メインルーターのDHCP設定を復旧し、クライアントの実際のリース更新結果を確認します。
停電とメインルーターの障害
N100 は電源投入時の自動起動とコンポーネントの自動起動が設定されています。原文の約2分という見積もりは、ディスクチェック、コンテナ起動、WAN取得、およびデーモンの猶予期間をカバーできません。復旧は前のセクションに従って検証されます。.7 が長時間到達不能な場合、ダイレクト接続が復旧パスとなり、診断には電源、スイッチポート、およびローカルコンソールの証拠が必要です。
メインルーターが失敗した場合、N100 は PPPoE、NAT、DHCP、および Mesh ルートノードの役割を代替できません。「LAN管理アドレスに到達不可」と「バックエンドは到達可能だがWANが接続されていない」をまず区別し、電源、配線、WAN状態、およびアップストリームONUを確認します。現在、メインルーターのホットスタンバイはありません。ONUのブリッジモードは、メインルーターの障害フェイルオーバー機能を提供しません。
li-home-0 Wi-Fi：現在のスクリプトによる復旧手順
systemd timer は OnBootSec=60、OnUnitActiveSec=30、AccuracySec=5 です。毎回 .1 に対して ping -c 5 -W 1 でプローブし、障害カウントは実行間で /var/tmp/wifi-watchdog に保存されます：
- ネットワークインターフェース
wlp9s0が存在する場合、最初の2回の到達不能失敗はログ記録のみを行います。 - 3回目の失敗では、まず
nmcli connection upを試みます。復旧した場合はゼロに戻ります。失敗した場合は、同じ実行内で引き続きドライバのリロードを実行します。 - リロードはまず無線を無効にし、
mt7925eおよび関連する mt76 モジュールのアンロードを試み、その後ロードして接続します。2回のリロードの間には少なくとも 300秒 の間隔が必要です。ネットワークインターフェースが消滅した場合も、この冷却保護を伴うリロードブランチを通ります。 - 以降のプローブが成功して初めてゼロに戻ります。サービス実行中は、timer の期限が来ても並列で別のインスタンスが起動しません。
旧表に従って「失敗1〜3回で再接続、4〜6回でRF、7回以降でリロード」と理解することはできなくなり、また、各ステップの約25秒という所要時間を総ネットワーク遮断時間と見なすこともできません。プローブ、閾値の確認、スケジューリングの誤差、コマンドのタイムアウト、および冷却がそれに影響します。
# li-home-0 のローカルコンソールまたは利用可能な管理接続で確認します。
メインルーターが正常であり、これが本機の無線障害であることを確認してから、手動の再接続またはリロードを検討してください。リロードは、その無線接続を介した管理セッションを切断します。ローカルコンソールまたは有線管理を優先してください。冷却期間中にリロードをループさせて「復旧を加速」しようとしないでください。ネットワークインターフェース、ファームウェア、および最近のログを確認してください。
ロールバック完了の基準
変更前後のクライアントゲートウェイ、DNS、DHCP設定、および時間を記録します。まず1台のクライアントで、名前解決、新しいダイレクト接続の確立、必要なプロキシアクセスのテストを行い、その後展開します。正常なパスへの復帰も同じ順序で検証します。
旧 .8 サブルーターは、プロキシサービス、フォワーディング、DNS、およびルールがまだ利用可能であることを確認した場合のみ、代替手段として使用できます。mihomo サービスの起動は、旧パス全体が復旧したことを証明するものではありません。DHCPのロールバックのために直ちに N100 をシャットダウンする必要はありません。ログの参照と修復のために、それを保持してください。