.ovpn ファイルを編集してもサーバー側の MFA は有効にならない理由

プロファイルに auth-user-pass を追加して再接続すると、クライアントはユーザー名とパスワードを要求します。MFA が有効になったように見えます。ところが、別アカウントのコードや十分前に失効したコードを入力しても、トンネルはそのまま確立します。これが症状です。クライアントは変わったが、サーバーは変わっていないのです。ワンタイムパスワードが要素になるのは、サーバー上の検証側が、それを要求する身元に対して有効かどうかを判断するときだけです。

プロンプトが証明するのは、クライアントが要求したことだけです

.ovpn ファイルはクライアント側の文書です。クライアントに資格情報を要求させ、キャッシュさせ、あるいはキャッシュをやめさせることができます。しかし、ユーザーを登録することも、PAM モジュールを導入することも、サーバーが現在確認していない第二要素を要求するように仕向けることもできません。

スマートフォンに認証アプリを入れても、その関係は生まれません。Google Authenticator PAM プロジェクトは OTP 検証の部品であり、OpenVPN の背後に置くことはできますが、読み込んだプロファイルに Google アカウントのログインを貼り付ける手段ではありません。

プロファイルにできないのは登録の部分です

TOTP には、認証アプリとその検証側の間で共有される登録材料が必要です。スマートフォンに表示される六桁は出力であり、その背後にあるシードが秘密で、しかも一つの身元に属します。

したがって運用者には、正しいシードを正しい VPN の身元に結び付ける登録プロセスと、あわせて 紛失した端末のための検証済みの再発行手順も必要です。利用者に自分の名前を付けたファイルをアップロードさせるのは、登録をアカウント乗っ取りの機会に変えることであり、アップロードを暗号化してもそれは変わりません。

PAM ベースの設計でも、VPN 利用者ごとに別々の Unix アカウントを作る必要はありません。モジュールのドキュメントは代替の秘密パスと、ファイルアクセス専用のアカウントをサポートしています。これはファイルシステム上の身元であり、検証されるログイン身元ではありません。

よくある誤りは、単一利用者の例からコピーした、一つのユーザー名で終わる固定の秘密パスです。それは一つの身元の実演にすぎず、利用者ごとの検索ではなく、すべての要求に使っても誰にも独立して登録された認証アプリは生まれません。身元の対応表を書き留め、シードファイルを保護し、パスワード・証明書・アカウントの確認を同じ認証スタックに置いてください。

PAM スタックを読んで、実際に何が要求されているかを確かめます

account required pam_permit.so のような行はアカウントの適格性を実装しておらず、要素も追加しません。それは PAM のアカウント管理段階を許可するもので、段階についての記述であって、利用者についての記述ではありません。

寛容な登録オプションにも同じことが言えます。登録済みの秘密を持たない利用者を受け入れるのは意図的な展開判断かもしれませんが、MFA が必須である証拠にはならず、終了日を定めた一時的な例外として記録すべきです。

クライアントのやり取りをサーバーの設計に合わせます

auth-user-pass

このディレクティブはユーザー名とパスワードの入力を求めます。PAM を設定するわけでも、登録記録を作るわけでも、パスワード欄に TOTP の値が入っているとサーバーに伝えるわけでもありません。サーバー側の統合とクライアントは、その配備が実際に支えるやり取りで合意する必要があります。チャレンジ、文書化された複合資格情報の形式、あるいは製品固有のフローのいずれかです。

クライアントが一つの欄を表示するからといって、パスワードにコードを付け足してはいけません。それが機能するのは、サーバーのプラグインがまさにその形式を期待している場合だけで、それ以外の場所では紛らわしく失敗します。

シードと QR の素材は、共有プロファイルや日常的な診断ログから遠ざけてください。認証済みのログイン経路で送られたコードは、管理された登録の際に発行されたシードと同じものではなく、両者をサポートチケットで混ぜることが秘密の漏えい経路になります。

再接続、トークン、そして決着をつけるテスト

最初のログインに成功した後に何が起きるかを計画してください。以前に受け入れられたコードは、次の認証では失効しているか、再生として拒否されるかもしれません。auth-nocache は資格情報の保持を制御するもので MFA を導入するものではなく、reneg-sec 0 も、フォーラムのスレッドにどれほど頻繁に現れても、TOTP 対応の定義ではありません。

配備によっては、最初の確認の後に認証トークンを発行し、再接続のたびに再入力を求めないようにします。それは独自の有効期間と失効の筋書きを持つ設計判断であり、引き継ぐ既定値ではありません。

次に、人々が実際に使っているクライアントで受け入れ方針を試します。正しいパスワード、証明書、現在のコードを持つ登録済みの利用者は接続できるはずです。間違ったコード、登録のない利用者、禁止されたアカウントはそれぞれ失敗し、その理由がサーバーログに見えるはずです。それらの拒否を見るまでは、方針ではなくプロンプトがあるだけです。