ルーター再起動後にVPNが固まる：変わった三つの点

ルーターの起動が終わり、ノートPCは同じSSIDに再接続し、VPNは何も動かないまま接続済みで止まっている。保存済みのプロファイルは無傷だ。その下で失効したのは経路であり、クライアントは古い経路向けに作った状態をまだ保持している。

修正を決める条件は三つある。順番に確認すること。最初の条件で停止が説明できるなら、後の確認は無駄な作業になる。

条件一：ローカルアドレスが変わった

再起動によってマシンに別のアドレスが割り当てられることがある。固定のローカルエンドポイントで設定されたVPNは、存在しない接続を使い続ける。ソケットを古いアドレスに束縛したクライアントも同じだ。トンネルインターフェースは起動したままで、生成するパケットはすべて無意味な行き先へ向かう。

クライアントが使っているアドレスと、インターフェースが現在持つアドレスを比べる。変わったゲートウェイを指すデフォルトルートも、名前が違うだけで同じ種類の問題だ。

ip -4 addr show
ip route show default
ip route get 203.0.113.10

条件二：変換されたマッピングが消えた

家庭用ルーターは外向きのフローを変換し、そのマッピングはメモリ上にある。再起動はそれを一つ残らず消す。新しい接続には無害だが、既存のフローがまだ有効だと信じるトンネルには致命的だ。相手側には何も届かないので、クライアントは対処できるエラーを一度も受け取らない。

keepaliveのないトンネルが、大きな音を立てて失敗する代わりに静かに止まるのはここだ。WireGuardの文書化された制限も同じ形の失敗を説明している。エンドポイントの状態が誤っていると、診断ではなく破棄されたパケットが生まれる。

25秒の永続keepaliveが一般的な緩和策だ。アイドルタイムアウトが切れる前にマッピングを更新するからである。ただし、すでに消えたマッピングを修復するものではない。修正手段として扱うのではなく、再接続ロジックと組み合わせる。

条件三：パブリックアドレスが変わった

もしルーター自身の外部アドレスが変わっていれば、送信元アドレスで絞り込む相手側は、今は別のピアを見ている。トンネルは上がってもサーバーが通信を捨て続けることがあり、壊れたクライアントに見えて実際は相手側のポリシーである。

再起動の前後で外部アドレスを記録する。二つが違えば、問題はクライアントから許可リストの管理者へ移る。ノートPCで認証情報をリセットしても解決しない。

正しい順序で復旧する

まずキャプティブポータルのサインインを済ませ、プロセスを殺すのではなく、クライアントが対応している手順で再接続させる。IDとデータ通信の両方が戻るかを見る。同じ接続の二つの異なる段階だからだ。

キャッシュされたページは何も証明しないし、自ら再接続したチャットアプリも証明にならない。本当に必要なエンドポイントを新しいリクエストで試す。中断中も直接通信のポリシーは有効のままにする。再接続の試行はブロックではない。

これが再起動のたびに繰り返されるなら、再試行よりも記録が重要だ。ローカルアドレス、ゲートウェイ、外部アドレス、クライアントの状態を前後で記録し、二つの列を比べる。曖昧な不満が誰かが直せるライフサイクルの不具合になり、マッピングのタイムアウトで証明書が三度目に交換されるのを止められる。