OpenVPN が後から OTP セッションを切る理由: 再認証に必要なもの

クライアント側から見ると、作業中のセッションが一時間ほどで不意に切断されたように見えます。トレイアイコンが消え、トンネルが再構築され、ログにはネットワークエラーではなく認証失敗が残ります。実際に起きたのは、セッションが再ネゴシエーションを行い、二回目のハンドシェイクがクライアントにもう有効なコピーのない資格情報を要求したことです。ログイン時に通ったワンタイムコードは二度目には通りません。だから再鍵交換は設計どおりに失敗します。

直すべきは、二回目のハンドシェイクが何を提示するかという判断であり、再試行タイマーを延ばすことではありません。

クライアント側からやり取りをたどる

ログイン時にクライアントはユーザー名、パスワード、トークン端末のコードを送り、サーバーがその組み合わせを受け入れます。その後セッションは再ネゴシエーションのトリガーが発火するまで続き、既存のトンネルの中で新しい TLS ハンドシェイクが始まります。そのハンドシェイクは再び認証を求めます。サーバーの認証経路がパスワードと現在のワンタイムコードを期待するなら、ユーザーがその場で入力しない限り、クライアントに提示できる新しいコードはありません。

ほとんどのクライアントはセッションの途中でプロンプトを開かないため、ハンドシェイクはタイムアウトし、トンネルは落ちます。ユーザーが見るのは認証プロンプトではなく再接続であり、最初の報告がネットワークのせいになりやすいのはそのためです。

auth-gen-token は二つ目の問いに誰が答えるかを変える

auth-gen-token オプションを使うと、サーバーはログイン成功後にトークンを発行でき、以降の再ネゴシエーションはパスワードとコードを繰り返す代わりにそのトークンを提示します。マニュアルには その有効期間と更新の挙動 が記されており、トークンは独自の有効期限を持つ資格情報として扱う必要があります。既定の経路では、サーバーは外部のパスワード認証器を再び呼ばずに、自分でトークンを検証します。

外部認証との統合があると、その分担が変わります。プラグインがトークンの状態を理解し、独自の検査を行う必要があります。セッションを続けるかを決めるのがサーバーだけではなくなるからです。トークンを別の数値ワンタイムコードとして扱うことは、この機能の実装ではありません。

アカウントの状態をどう扱うか決める

アカウントのアクセス権より長く生き残るトークンはポリシーの穴です。無効化されたアカウント、外されたグループ所属、失効した端末が、トークンがまだ有効な間にどう効くかを決めてください。トークンの有効期間を短くすれば窓は狭くなります。明示的な失効経路があれば、それは意図したものになります。オプションを有効にする前に答えを書き留めてください。既定の経路は再ネゴシエーションのたびに外部認証器を参照しないからです。

複数サーバーの配備では、トークン署名の秘密を共有する必要があり、さもないと、クライアントは自分のトークンを検証できないノードへ送られることがあります。

ログインだけでなく、期限切れと再接続を試す

テスト用プロファイルで再ネゴシエーション間隔を短くし、二回目のハンドシェイクを目の前で起こしてから、両方のログを追います。トークンがログイン時に発行され、再鍵交換時に提示され、設定した有効期間に従って更新または再発行されることを確認します。そのうえでトークンの期限切れと完全な再接続を強制します。きれいに再接続するクライアントでも、再鍵交換の経路では失敗しうるからです。

アカウント削除のテストは最後にします。そのケースで、書いたポリシーが実際に適用されるのか、単に文書化されているだけなのかが分かります。

更新を無効にして直そうとしない

両方のピアで再ネゴシエーション間隔をゼロにすると、症状は消えますが鍵のローテーションも一緒に消えます。それは、誰も検討していないポリシー変更の裏に資格情報のリプレイ問題を隠すことになります。更新は残したまま、ユーザーが同席しているかどうかで、サーバー発行のトークンか新たな対話型チャレンジかを選びます。

再試行タイマーを長くしても、使い切ったコードが再び有効になるわけではありません。切断が遅れるだけで、ログは読みにくくなります。