OpenVPN の鍵を大きくしても再鍵交換タイマーが消えない理由

AES-256 やより長い鍵を選んでも、その鍵をいつまで使えるかは何も分かりません。 鍵の強度が示すのはアルゴリズムで、再鍵交換ポリシーはセッションが新しい鍵素材を導出する時期を決めます。配備では利用可能な中最強の暗号を選んでも更新について誤ることがあり、二つの判断は別々の場所で行われるからです。これを混同すると、不要な暗号変更か、ポリシーより長く黙って生き残るセッションのどちらかが生じます。

暗号に触れる前に再鍵交換の設定を読み、そうするときは両側の設定を読んでください。

鍵の強度と鍵の寿命は別の問いに答えます

暗号と鍵の長さは、傍受された通信への攻撃がどれだけ高くつくかを左右します。再鍵交換の間隔は、一つの鍵が守る通信量と、漏えいした鍵が役に立つ期間を左右します。これらは独立した設定であり、強い暗号にしてもセッションの安全な寿命は延びません。「AES-256 を使え」という助言の多くが更新について触れないのは、更新がアルゴリズムの選択ではなくポリシーの問題だからです。

配備メモには、データチャネルを何が守るのか、その鍵の交換を何が引き起こすのかの両方を記録します。

再鍵交換には三つのトリガーがあり、どちらのピアも発火できます

OpenVPN 2.6 は、バイト数、パケット数、経過時間に基づく再ネゴシエーションのトリガーを別々に文書化しています。時間のトリガーは多くの配備が既定値のままにするもので、静かなトンネルでも予定どおりに再鍵交換します。どちらのピアも交換を開始でき、開始しなかった側はそれに従います。したがって片側のタイマーを変えてもセッションの挙動は決まらず、有効な値は先に開始する側のものです。

バイトとパケットのトリガーは、時間だけのポリシーでは一つの鍵が想定よりはるかに多くのデータを守ってしまう高スループットや小さなパケットの負荷で重要です。そうしたカウンターを無効のままにするなら、既定値を未検討のまま放置せず、その旨をメモに明記してください。

再鍵交換は認証フローを露出させます

再ネゴシエーションは新しい TLS ハンドシェイクなので、認証経路がもう一度走り、ワンタイムコードやハードウェアトークン、RADIUS チャレンジを使う配備はこれを苦い形で知ります。最初の接続は成功し、二度目のハンドシェイクが使用済みのコードを要求したとき、一時間後にセッションが落ちるのです。 auth-gen-token は、新しい対話的ログインを求める代わりに、サーバーが再ネゴシエーション用の短命トークンを発行できるようにして、その隙間を埋めるために存在します。

これは更新を切るべきだという証拠ではなく、運用者と解決すべきワークフローの問題として扱ってください。

更新は負荷をかけて試すもので、一分間のセッションでは試せません

接続して一度 ping し、切断する受け入れテストは再鍵交換に決して到達しません。設定したトリガーを越えるだけの長いセッションを実行し、その間ずっと転送を続け、両方のピアのログで新しいハンドシェイクを確認してください。次に、再ネゴシエーションを完了できないときにクライアントがどう振る舞うかという失敗経路を試します。きれいに落ちるトンネルのほうが、死んだセッションへ送り続けるトンネルより診断しやすいものです。

成功した大きな転送を暗号学的なしきい値の証拠と読まないでください。それが示すのは、経路とカウンターがその程度の通信量に耐えたというだけです。

両方の選択を記録します

記録には二行、つまりパケットをどう守るかと、その保護をいつ交換するかが必要です。各値の根拠も添えてください（暗号はディストリビューションの既定値から、タイマーは内部ポリシーから来るかもしれません）。将来の運用者がどちらも設定ファイルから推測せずに済むようにしてください。

互換性が例外を強いるなら、バージョンと終了日で範囲を限定してください。理由より長く生きる例外は、誰も選んだことを覚えていないポリシーになります。