リキー、再接続、再認証：どれが必要か

何時間も稼働しているセッションが同じ鍵を永遠に保つことはなく、それは意図された設計です。三つの異なる事象が鍵ローテーションと呼ばれます——既存のアソシエーションの下での新しいセッション素材、接続の完全な再構築、そして識別情報の確認の繰り返しです。それぞれ引き金もコストも障害の兆候も異なります。間違ったものを選ぶと、修正は何もしないか、理由もなくトンネルを落とします。

判断は、実際にどの層が期限切れになったかによって決まります。

ローテーションと呼ばれる三つの操作

リキーは、プロトコルが定める仕組みを使って、既存の制御関係の中で新しいトラフィック鍵を作ります。IKEv2 は新しい子セキュリティアソシエーションで、TLS 1.3 は鍵更新メッセージで、WireGuard は時間またはメッセージの上限に達したときの新しいハンドシェイクでこれを行います。トンネルのアドレスと認証済みの識別情報はそのまま残ります。

再接続は接続を破棄して最初から作り直すため、アドレスの割り当て、ルートの設定、最初の試行が行ったあらゆるネゴシエーションが繰り返されます。

再認証は識別情報の証明そのものを繰り返すもので、資格情報、証明書、第二要素が関わることがあります。製品によって、再接続とともに行われる場合も、そうでない場合もあります。

更新時に利用者が気づくこと

リキーはほとんど見えないはずです。アソシエーション識別子が変わり、カウンタがリセットされることがあり、アプリケーションはソケットを保持します（交換中に片方向で短い停止が起きるのは正常です）。状態一覧に新しい識別子が見えることは障害の証拠ではありません。交換のあとに続くログ行が、完了したかどうかを教えてくれます。

更新時の実際の切断は、特定の箇所を指します。提案の不一致、期限切れの資格情報、経路の変更はそれぞれ異なるログ行を生み、そのうち一つだけが存続時間の調整で直ります。

実際に三つが分かれるところ

期限が切れたのが鍵素材だけならリキーです。ピアのアドレス、ルート、NAT の紐付けが変わってパケットが届かなくなったなら再接続です。組織が定期的な識別情報の確認を求めるならそれは再認証であり、存続時間の調整では代わりになりません。

プロトコルの既定値はたいてい正しい答えを含んでいます。WireGuard は利用者の操作なしに時間とデータ量のしきい値で鍵を切り替え、IKEv2 の存続時間は子アソシエーションごとにネゴシエーションされ、TLS ベースのトンネルは既存のセッションの中で鍵を回します。繰り返すエラーを避けるために存続時間を延ばすと、障害は先送りされ、鍵が漏えいした場合の露出が長くなります。

長いセッションでは、頻度だけでは前方秘匿性が生まれないという一つの注意点が重要です。この性質は、セッション鍵が長期の秘密とどう関係するか、古い鍵が破棄されるかどうかに依存し、それは設定ではなく設計と実装の問題です。

既定値を選び、それから段階を記録する

文書化された要件が別段の定めをしていない限りベンダーの既定値を保ち、存続時間を変えるなら両方のピアで変えてください。そのうえで各事象がどの段階に達したかを記録し、次の発生をハンドシェイクの同じ地点と照合できるようにします。

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

修正のあとは統制された更新を行い、新しいアソシエーションを通じて新しいアプリケーションの通信を流します。確立したと報告しながら何も転送しないトンネルこそ、この確認が捕まえるために存在する障害です。