トラフィックを流さなくなったピアも、それだけで鍵を失うわけではなく、新しいハンドシェイクは誰かが利用許可を更新したことを証明しない。WireGuard のタイマーは鍵を新しく保ち、パケットを流し続けるためのもので、一定の分数が過ぎた利用者がログアウトする様子を模したものではない。ここでは三つの問いが混同されており、それぞれ証拠が異なる。この区別が、どの道具を使うかを決める。

三つの問いと一つのコマンド出力

運用者は、ピアに到達できるか、稼働していたか、まだ許可されているかを尋ねる。一つ目はプロトコル状態、二つ目はトラフィックのカウンター、三つ目は認可である。WireGuard のインターフェースから読めるのは最初の二つだけで、それらが三つすべての答えに流用されている。

QuestionEvidence it needsWhat does not answer it
Is the peer reachable now?A recent handshake and a working return pathAn interface that exists
Has it been active?Transfer counters moving over timeA handshake timestamp alone
Is access still granted?The configuration or controller that authorizes itAny protocol timer

各行を三つの別々の調査として読む。最初の二つは安価で、インターフェース自身のカウンターから答えられる。三つ目はアクセスを与える設定を必要とし、それは別のファイルや別のシステムにある。誤った行を選ぶことは、プロトコルのタイマーにポリシーの仕事をさせることになる。

タイマーが実際に管理するもの

プロトコルは、ハンドシェイクの再試行、転送鍵のローテーション、古い鍵で保護されたパケットの拒否について定数を定義している。これらはトラフィックと状態に反応するもので、カレンダーや、17:00 まで接続してよいというポリシーに反応するのではない。だからこそ、アイドルのピアは何時間も停止して見えながら、許可されたままになる。

PersistentKeepalive は、欠けているタイムアウトだとよく誤解される。NAT マッピングを生かしておくために認証済みの空パケットを送るもので、ゼロに設定すると、何も取り消すことなくそのパケットが止まる。

ピアごとの実行時状態を、コメントではなく公開鍵を使って読む:

wg show wg0 latest-handshakes
wg show wg0 transfer

最近のハンドシェイクは、ハンドシェイクが一度完了したことを示す。トンネルの先のプライベートサービスに到達できることは示さない,古いタイムスタンプは、単に静かなピアのものであることもある。

アイドルのピアがログアウトしたピアではない理由

WireGuard には開始と終了を持つセッションというオブジェクトがない。ピアとは許可されたアドレスを持つ公開鍵であり、そのトラフィックを守るハンドシェイクは必要に応じて交換され、利用者に見えるログインは存在しない。最近のトラフィックがないことをログアウトとみなすのは、モデルを逆転させている。

本当の不満が、アイドル後に接続が失敗するというものなら、原因はたいてい別のところ、つまり期限切れの NAT マッピング、スリープした端末、状態を落としたファイアウォールなどにある。反対側からトラフィックを送り、新しいフローを開始して試し、何が変わるかを比べる。

期限は認可がある場所に置く

アクセスが特定の時刻に終わる必要があるなら、期限はアクセスを与える側に属する。ピア設定を発行するコントローラーは、新しいものを渡す前に更新された承認を求めることができ、それはコントローラーの性質であって、インターフェース上の隠しパラメーターではない。

手作業で管理するピアでは、削除は稼働中のインターフェースと保存された設定の二か所に届く必要がある。実行時だけピアを削除しても、再起動や調整ループで元に戻り、失効したと思っていた同一性が復活する:

sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0

次に、ラベルではなく境界を試す。期限の後にピアが拒否されること、更新の経路が機能すること、状態がマネージャーの再読み込みを越えて残ることを確認する。ハンドシェイクの経過時間は有用な運用上の信号であり、アクセスの記録ではない。

関連記事