OpenVPN auth-nocache: 次のログインで何が起きるか

auth-nocache を有効にすると、パスワードのキャッシュに関する警告が消え、OpenVPN が次の再ネゴシエーション用に保持していた認証情報のコピーも消えます。それがプロンプトになるか、静かな再試行になるか、切断されたトンネルになるかは、二回目に認証情報がどこから来るかで決まります。つまりこれは展開形態の比較であり、このオプションへの判定ではありません。どのプロファイルを編集する前にも、実際に動かしている形態を読んでください。

二つ目の認証情報をどこから得るか

OpenVPN は auth-nocache を auth-user-pass と askpass が集めた秘密に適用し、使用後は次のハンドシェイクのために保持せずプロセスが破棄します。再ネゴシエーションはタイマーで、既定では一時間に一回訪れるため、二回目の要求はパスワードを入力した人がその場を離れたずっと後に届きます。その差がすべてです。キャッシュを有効にしたままなら、クライアントは誰にも尋ねずに保存済みのコピーを再生し、無効なら秘密を別の場所で見つけるか失敗するしかありません。

その瞬間に秘密が来うる場所をすべて挙げ、そのうちどれがホスト上に存在するかを正直に見てください。端末の前にいる人、auth-user-pass や askpass が読めるファイル、サーバーが発行するセッショントークンの三つがここでは重要です。どれも使えない場合、再ネゴシエーションは変更の一時間後に失敗し、変更したその瞬間には失敗しません。

三つの形態、三つの失敗点

前に人がいるデスクトップクライアントは軽いケースで、プロンプトが戻り、誰かがもう一度パスワードを入力し、代償は注意だけです。端末なしで OpenVPN を動かすサービス、コンテナ、ルーターは厳しいケースで、答える人がおらず、かつて静かだった再接続が今ではトンネルを終わらせます。ハイブリッドはその中間で、プロンプトに答えられたセッションが消えるまではデスクトップのケースのように振る舞います。両者を分けるのは GUI の有無ではなく、再ネゴシエーションの時点で認証情報の供給源があるかどうかです。

何かを変える前に、オンラインで見つかる助言はほぼ常に一つ目向けに書かれているため、自分の展開をこの三つのどれかに当てはめてください。デスクトップ向けの答えを端末なしのサービスに当てはめるのが、何か月も動いていたトンネルが一時間ごとに落ち始める理由です。

ディレクティブかフラグか: どちらか一方を選び、使った方を把握する

プロファイルの中では auth-nocache は独立した行で、プロファイルを明示する呼び出しではそのコマンドラインのフラグであり、OpenVPN のマニュアル は両方の形を挙げています。どちらも認証情報の保持に対して同じ働きをし、どちらもインターフェース種別に触れず、同じログにある無関係な警告を直しません。違いは永続性で、フラグはその実行だけを覆うため、unit ファイルやラッパースクリプトから再起動したサービスは、ラッパーもそれを渡さない限りフラグを持ちません。

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

どの成果物が設定を所有するかを決め、そこだけを変え、他のどこも変えないでください。ノート PC で編集したプロファイルと、フラグでそれを上書きする systemd unit の組み合わせが、再起動後に矛盾した挙動を生みます。

認証情報ファイルは秘密を消すのではなく移す

auth-user-pass をファイルに向けると、以降の再ネゴシエーションすべてに供給源ができ、パスワードは再起動を越えて残る場所に置かれます。そのファイルを誰が読めるか、特権を落とした後もデーモンが読めるか、ファイルシステムが読み取り専用でマウントされたりコンテナのビューがパスを隠したりしたらどうなるかを問うてください。ディスク上の秘密とメモリ上の秘密は別の問題で、片方を解決してももう片方はそのまま残ります。見落とされるのがローテーションで、サーバー側で変えてファイル側で変えていないパスワードは、ネットワーク障害のように読める失敗を生みます。

ファイルはデーモンを動かすアカウントの所有にし、他の誰も読めないようにし、ホストを離れるバックアップの外に置いてください。OpenVPN のサーバー側 auth-gen-token オプションは、ログイン成功後にセッショントークンをクライアントに渡し、アカウントのパスワードよりは小さなものを放置することになります。いずれにせよ、ファイルは通常作った人より長く残るため、ローテーションの手順をファイルの隣に書いてください。

再ネゴシエーションを伸ばすのは費用を移すだけで、なくさない

もう一つの提案は、プロンプトが無視できるほど稀になるまで reneg-sec を上げるというものです。それはセッションの鍵ローテーションの予定を書き換え、同じ認証情報の問題をより遅く、予測しにくい時点へ押しやるだけで、認証情報の供給源は作りません。理由があって鍵を予定どおり更新する方針を、パスワード入力の回避だけのために緩めるべきではありません。

生きたセッションは何も証明しないため、今座っているセッションではなく再接続を試してください。サーバー側からトンネルを落とすかクライアントサービスを再起動し、キーボードの前に誰もいない状態で次の再ネゴシエーションが何をするかを見てください。再接続するなら秘密を供給した仕組みを名指しし、しないならこのホストにおけるこのオプションの本当の代償を見つけたことになります。どちらの結果でも、試験中に成り立った答えではなく、障害時に成り立つ答えが得られます。

管理されたフリートでは、展開を所有する人が、認証情報がどこから来るか、どこに保存されるか、誰がローテーションするかの三つを挙げられるべきです。その答えのどれかがホストを設定した本人なら、そのホストではまだこのオプションは安全ではありません。