VPNセッションのタイマーと認証トークンは別々に失効する
ゲートウェイのセッション上限、アイドルタイマー、再利用可能な認証トークンは、それぞれ異なる規則で失効する。切断時のエラー行がどれだったかを教えてくれる。
VPNの切断は、クライアントから見れば同じに見え、その下では何も共通しない理由で起こりうる。トンネルのセッションが終了したか、アイドルタイマーが発動したか、クライアントが再利用していた資格情報が古くなったかである。それぞれ担当も対処も違い、切断の瞬間のエラー列がそれらを分けるもので、たいていは一行である。
一つのトンネルに対して三つの時計が動いており、そのうち本当にトンネルなのは一つだけである。
一つのトンネルに三つの異なる時計
セッションの時計はゲートウェイのもので、接続の最大継続時間、アイドルタイムアウト、またはその両方を持ち、どちらかに達した時点でトンネルを終了させる。トークンの時計は認証システムのもので、人間を介さずに資格情報を何度も提示できる期間を決める。経路の時計はクライアントとゲートウェイの間にあるNATやファイアウォールのもので、終了したとみなしたフローの対応付けを失効させる。三つとも切断を起こすが、同じログ行を出すものは一つもない。
VPNの概念なのは一つ目だけである。残りの二つはIDとネットワークから借りたもので、しばしばそれと混同される。
トークンは実際にどう再利用されるか
OpenVPNサーバーは初回ログイン後に認証トークンを発行できるため、制御チャネルの再ネゴシエーションで利用者に資格情報を再度求めない。クライアントはそのトークンを提示し続け、サーバーがいつまで受け付けられるかを決める。トークンの寿命が再ネゴシエーション間隔より短いと、次の再ネゴシエーションが失敗するため、クライアントはタイムアウトではなく認証エラーを報告する。同じプロファイルがある一時間は動き、その後は決まった地点で失敗するのはそのためである。
再ネゴシエーション間隔は別の設定である。これを変えるとトークンを提示する時点が動くだけで、寿命は変わらない。
クライアントから見たそれぞれの失効
セッションのタイムアウトは通常、サーバー側の理由を伴うきれいな切断として、多くの場合に予測できる時間の後に、認証エラーを伴わずに訪れる。アイドルのタイムアウトは沈黙のように見え、トンネルが通信を運ばなくなり、やがてキープアライブが諦める。トークンの失効は、一秒前まで動いていたセッションの途中でAUTH_FAILEDとして訪れる。
行を読み、それから時計を見る。設定値と一致する継続時間は偶然ではない。
保存したパスワードが助けにならない理由
キャッシュされたパスワードはパスワードの要求に答える。トークンの寿命を延ばすものではなく、第二要素や端末の状態確認の要求を満たすものでもない。再試行の頻度を上げても、接続のタイムアウトを短くしても、プロファイルを再インポートしても、IDシステムが資格情報を受け付ける期間は変わらない。
持続する修正は、正しい対象に正しい寿命を設定することか、必要な要求を人間なしで完了できるクライアントの流れである。
文書化して試験すべきこと
書き留めるべきは三つの値で、ゲートウェイのセッション上限とアイドル上限、トークンの寿命、経路上で最も短い関連する対応付けのタイムアウトである。次に、一つの値を短くして意図的に各失効を試し、クライアントが何を報告するかを見て、元に戻す。境界ごとに利用者が何をすべきかを確認するべきで、毎時フルログインを求めるのは誰かが意図して決めるべき方針判断だからである。
認証イベントがまったくない切断は、経路かアイドルタイマーのものであり、それは別の証拠を持つ別の調査である。