keepalive は再接続ではない：手元の障害で選ぶ

keepalive と再接続は同じ呼吸で設定されるが、解く問題は違う。だから片方を調整しても、もう片方が直ることはほとんどない。keepalive は小さな通信を送り、状態エントリを生かし続けるか、相手が応答をやめたことに気づく。再接続は壊れたものを畳んで関係を組み直す（鍵、アドレス、ルートも含まれる）。すでに知っているつまみではなく障害に合う仕組みを選ぶこと、判断する問いは二つ、経路が死んでいるのか、それとも相手の間の何かが経路を忘れているのか。

マッピングが問題のとき

数分の沈黙のあとにだけ死ぬトンネルは、たいてい相手ではなく変換エントリを失っている。WireGuard のPersistentKeepaliveは NAT とファイアウォールの状態のために存在し、プロジェクト自身の注記もそう説明している——健康チェックとしてではない。数十秒の間隔はエントリを温かく保つが、毎秒のパケットはバッテリーの判断であって信頼性の判断ではない。OpenVPNも同じ結論にpingとping-restartで到達し、まず沈黙に気づいてから行動する。

これらの設定はプロトコル間で交換できるものでもなく、IKEv2 のデッドピアの方針、OpenVPN の ping タイマー、WireGuard の keepalive は同じ問いに三つの構文と三つの既定値で答える。だから数値をそのまま移すのは、調整の衣装を着た当て推量だ。

関係が失われたとき

相手がアドレスを変え、資格情報が失効し、遠端が再起動したなら、小さなパケットは修理ではない。再接続は状態を組み直さなければならない：アドレスを取り、ルートを入れ直し、鍵を再交渉し、配備によっては利用者を再認証する。

無人で再接続するクライアントは証明書か保存された秘密を持つが、人間に尋ねるクライアントは誰もいないときにこそ失敗する。それこそが再接続の意味があった場面だ。これは数か月前の設計判断であり、障害の最中に変えられる設定ではない。

どちらも証明しないこと

トンネルは再接続され、鍵もルートもあっても、その背後のサービスが落ちていれば意味がないが、keepalive はサーバーが何時間も前に消えたセッションのためにマッピングを開いたままにできる。本当に気にしているものが使えないとき、どちらの仕組みも成功を報告しうる。

だからテストは実際のリクエストで終わる。気にする間隔のあとにトンネル越しに何かを送り、次に想定した障害を別々に起こす——マッピングの場合はアイドル期間、再接続の場合は再起動かアドレス変更だ。

直接通信を止めるのは別の判断

再接続のループが完全に健全でも、アプリが黙って通常の経路を使っていれば、それは障害ではなく漏洩だ。トンネルの外に何も出さないことが要件なら、クライアント設定で明示し、トンネルを落として何がつながったままかを見て証明する。どちらの仕組みもその挙動を含まず、再試行の作法をいくら整えても確立できない。

どの仕組みが動いたか、そのあと新しいリクエストが成功したかを記録する。次の技術者が必要とするのはその二つの事実で、どちらもステータスアイコンには出ない。クライアントが再接続したというログ行は、通ったリクエストと同じではない。

方針を書く、数値だけでは足りない

組を一文にまとめる——アイドル間隔、生存のしきい値、何が組み直しを起こすか、そして再試行中にクライアントが何をするか。その一文がなければ、今後の障害のたびに、keepalive が短すぎるのか再接続が遅すぎるのかで同じ議論が再燃する。

WireGuard の制約に関する注記は、keepalive が中間装置のための回避策であって、一般的な生存設計ではないことを思い出させる。解けない問題への対処として頻度を上げる前に、その制約を読んでほしい。