VPN の再接続で資格情報を再び求められる理由

何時間も動いていたトンネルが、ノート PC がスリープから復帰した瞬間にパスワードを要求し、設定は何も変わっていません。変わったのは、再接続が再利用しようとした資格情報の状態です。これを左右する素材は三種類あり、任意の空白を越えて残るのはそのうち一つだけです。

クライアントがどれを要求したのかを確認してください。三つはそれぞれ別の時計で失効し、別のメッセージで失敗します。

再利用できる三種類の素材

キャッシュされたパスワードはクライアントが保持する秘密で、アカウントが変更するまで有効です。セッショントークンはログイン成功後にサーバーが発行し、独自の有効期間を持ち、いつでも失効させられます。TLS セッションチケットや IKE セキュリティアソシエーションはプロトコルの状態で、再開のコストが低く、パスワードとは完全に独立しています。それぞれ別のコンポーネントが発行し、それぞれ独自の条件で失効します。

一つ目は再起動を越えて残り、二つ目は通常はサスペンドを越えて残り、三つ目はネットワークの変化を越えられないことがあります。これらを混同すると、一度も拒否されていないパスワードをリセットするといった誤った対処になります。

プロンプトそのものが診断です。ブラウザー画面や第二要素のコードが出るなら、サーバーが対話的な認証を要求したということです。一方、プロンプトなしの無言の失敗は、クライアントが問い合わせを受けるところまで到達していないことを意味します。

鍵の更新は再認証ではない

鍵の更新は、認証済みの身元を保ったまま鍵を差し替えるもので、だから健全なトンネルでは時折無言で起きます。再認証は身元の確認そのものを繰り返す行為であり、あなたの対応を必要とするのはこちらです。IKEv2 はこの二つを明確に分けており、その間に何回鍵を更新したかに関係なく、設定した間隔で完全な再認証を要求できます。二つの事象は、ログがどちらを指しているかを読むまで外からは同じに見えます。

OpenVPN も独自の用語で同じように振る舞います。再ネゴシエーションの間隔がデータチャネルを更新し、次回の接続で完全なログインを避けるために認証トークンをクライアントに返せます。そのトークンには有効期間があり、受け入れるかどうかはサーバーが決めます。

そのため、八時間後の再接続は八分後の再接続が成功した状況でも失敗することがあり、どちらの側でも設定は変わっていません。昼食後にだけ現れるプロンプトの説明はこれで尽きます。

クライアントが新しい課題を完了できない場合

ブラウザーの手順を要求するポリシーは、それを表示する手段のないクライアントでは失敗します。ヘッドレスサーバー、起動スクリプト、パスワードのみの認証向けに作られた古いプロファイルは、いずれもこの壁に当たり、失敗は認証エラーではなく一般的なタイムアウトとして現れがちです。

端末やネットワークの切り替えがポリシー評価の時間帯に入ることもあり、Wi-Fi からホットスポットへの移動が、どのみち行われる確認と重なります。その偶然の一致が、原因がタイマーであるのにネットワークを疑わせます。

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

最初の行はクライアント自身のログにある再ネゴシエーションと認証のイベントを示し、二行目は strongSwan のピアが現在保持しているセキュリティアソシエーションを示します。タイムスタンプをプロンプトが現れた時刻と比べてください。一致すれば、ネットワークではなくタイマーが原因だと確認できます。

何を報告し、何を切ってはいけないか

手動のログインが成功し、自動の再利用が一貫して失敗するなら、そのとおりに運用担当者へ伝えてください。名前を挙げているのはコンポーネント、つまり再利用の経路であり、資格情報ではありません。失敗した時刻、使用中のアカウント、見たプロンプトの種類を含めてください。

再接続を無言にするために、第二要素を無効にしたり、証明書の検証を飛ばしたり、資格情報をスクリプトに貼り付けたりしないでください。どれもポリシーが強制するために存在する確認を外す行為で、どれもログインのプロンプトをインシデントに変えます。

代わりに、サポートされた流れを求めてください。課題を完了できるクライアント、勤務日に合ったトークンの有効期間、または問い合わせを表示できない機械向けの承認済み非対話プロファイルです。いずれも誰かが承認できる設定上の判断であり、回避策はそうではありません。