WireGuard がアイドル後に失敗する: まず方向を試す

設定を変える前に、クライアントが動作中の同じリソースは使えるか、アイドル期間はどれだけ続いたか、端末はスリープしたかネットワークを変えたか、障害は遠い側から始まる通信だけに現れるか、という四つの問いがあります。答えは、期限切れの NAT マッピングを、眠っている無線や古いアプリから切り分けます。keepalive がそもそも関係するかも教えてくれます。方向から始めればコマンド一つで済み、原因の半分を除外できます。

どちらの方向が失敗するのか？

クライアントからの新しい外向き要求と、静かな期間の後にこちらへ届く通信は、状態を持つ機器に別の負荷をかけます。外向きパケットは出ていくときにマッピングを再構築し、内向きパケットは古いマッピングが生き残っていることを必要とします。この非対称性が試験のすべてです。外へは出られるのに入ってこないならマッピングが期限切れの可能性が高く、どちらもだめならトンネルかクライアントのネットワーク接続が失われています。

静かな期間がどれだけ続いたか、その間に端末がスリープしたか別のネットワークへ移ったかを記録します。この二つの事実は、どんな設定よりも先に診断を変えます。

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

それぞれが問いの別の部分に答えるので、静かな期間の前と後にこの三つを実行します。動いていない handshake の時刻は、両者が会話をやめたことを示し、変わったエンドポイントは、マッピングが死んだのではなく移動したことを示します。転送カウンタは何かが届いたかどうかを示し、それが古いマッピングと沈黙したアプリの違いです。比較が証拠になるので、両方の時点で数値を書き留めてください。

スリープ、無線、アプリの状態

スマートフォンやノート PC では、スリープした端末がネットワーク接続を完全に失っていることがあり、keepalive は切れた無線を戻すことも、満たされていないキャプティブポータルを完了することもできません。モバイルプラットフォームはポリシーとしてバックグラウンド処理を停止するため、定期通信が続くかどうかはプラットフォームと、アプリがそれと交渉した内容によります。キャッシュされた接続は第三のケースで最も紛らわしく、トンネルが戻ることはアプリが再接続することと同じではありません。

アイドル期間の後は、開いたままのタブを信じるのではなくアプリを開き直してください。古いセッションが失敗した場所で新しい要求が成功するなら、トンネルは最初から問題ではありませんでした。

keepalive が実際にすること

PersistentKeepalive は認証済みの空パケットを定期的にピアへ送り、WireGuard のクイックスタートが説明するとおり、これでピア間の NAT マッピングを生かし、相手側のエンドポイントを最新に保てます。眠っている無線や失われたルート、決して再試行しないアプリは直せません。間隔は対応するクライアント設定で選び、状態表示が静かになったというだけでどこでも攻撃的な値にしないでください。

ほとんどのアイドル期間は障害ではありません。五分の沈黙の後に再接続するトンネルは正しく動いており、問題は遠い側から何かが届くはずだった場合だけです。

以前失敗した間隔を待つ

対応する変更を一つだけ行い、その後、そのリソースを再試験する前に同じアイドル期間を経過させます。待つことは試験の一部であり、形式ではありません。再接続こそ状態をリセットする出来事なので、再接続直後の成功は長時間アイドルの症状について何も語りません。問題がアクティブな使用中にも現れるなら、定期通信を増やすのではなく handshake とデータ経路の確認に戻ってください。

試験ごとに変更を一つに保ち、使ったアイドル時間を書き留めてください。そうしないと後の比較はすべてずれ、どの変更が効いたのか誰にも分かりません。四つの事実、つまり方向、時間、スリープ状態、アプリの挙動をまとめて記録してください。