OpenVPN ログインで静的チャレンジのコードはどこへ行くのか

クライアントはパスワード欄の後に二つ目の欄を表示し、ハードウェアトークンのコードを入力しても、ログインは認証エラーで失敗し続けます。その欄が存在する以上、プロファイルが要求したのです。サーバーが値を理解できる形で受け取ったかどうかは別の問題であり、まず答える価値があるのはこちらです。

クライアントが実際に表示するプロンプトから始めましょう

プロファイルは、プロンプト文字列と、入力中に応答を表示するかを制御するフラグを伴う静的チャレンジ指令を持てます。プロンプトはダイアログに表示される文であり、フラグは同じ入力に対する表示設定です。どちらもサーバーに何かの検証方法を伝えません。

実際に与えられた欄を数えてください。ユーザー名用の欄とマスクされた欄が一つずつなら、チャレンジのない通常のパスワードログインです。パスワードの後に独自のラベル付きで現れる二つ目の欄は、クライアントがチャレンジのやり取りを実装している証拠です。

使っているクライアントに 二つ目の欄が決して現れないなら、そのクライアントはやり取りを実装していないか、管理インターフェースのような別のフロントエンド経由でのみ実装している可能性があります。クライアントを確認するほうがプロファイルを書き直すより安く、食い違いはたいていそこにあります。

サーバー側がすでに備えている必要があるもの

プロファイルはクライアントが何を集めるべきかを記述するだけです。サーバー側の検証を有効にするものではなく、対応する認証連携のないサーバーは、認識しないパスワードを受け取るだけです。だからこそ、プロンプトを表示してすべてのコードを拒否する配備もあり、どの仕組みが照合を行うかという運用者の答えが重要になるのです。

どの仕組みが照合を行うのかを運用者に尋ねてください。それは PAM とやり取りするプラグインであったり、応答をトークンサービスに対して検証するスクリプトフックであったり、まとめられた値を自ら解析する管理ベースの連携であったりします。それぞれ期待する入力は少しずつ違います。

ここで期待値の調整も必要です。二つ目のプロンプトは入力の仕組みであって二要素が強制されている証拠ではなく、強制はサーバー側で起き、誤ったコードを試したときにだけ現れます。

管理インターフェースが送るエンコード済みフィールド

フロントエンドが管理インターフェース経由で接続を操作する場合、パスワードとチャレンジ応答は送信前に一つの値へまとめられます。管理インターフェースのリファレンスには、接頭辞の後にパスワードと応答を別々の Base64 要素として並べる形式が記されています。

Base64 はエンコードであって保護ではありません。欄を読める相手から何かを隠すわけでも、ワンタイムコードを使い回せる何かに変えるわけでもありません。まとめられた値はパスワードと同じ扱いを受けるべきで、共有プロファイルからも、コマンドラインからも、診断ログからも外してください。

そのエンコードこそが最もよくある混乱の源で、似て見えて互換性のない三つの形が存在するからです。素の認証情報ファイルはパスワードを保持します。パスワードとコードをそのまま連結したものは別の文字列を保持します。管理クライアントのまとめた応答は三つ目を保持します。エラーが消えたという理由だけで欄を変える前に、検証経路がどれを期待しているかを確認してください。

静的と動的：タイミングの違い

静的チャレンジは最初の認証情報を送る前に分かっているため、クライアントは先に尋ねられます。動的チャレンジは後から届き、やり取りがすでに始まった後に認証フローが送るもので、会話の途中の要求を扱えるクライアントが必要です。

片方への対応がもう片方を与えるわけではありません。静的プロンプトを設定するプロファイル指令は、サーバー起点のチャレンジを実装しませんし、動的な要求を扱うフロントエンドが静的のものを表示しないこともあります。どちら側が要求を始めたかを読むのが、両者を見分ける最短の方法です。

無人運用になると、これは画面の問題ではなく設計の問題になります。保存されたコードは起動時の恒久的な認証情報ではなく、数時間後の再接続では新しい入力が必要で、ただし、運用者が意図的に有効にしたトークンの取り決めを配備が支えている場合を除きます。

成功と失敗の両方を試す：ダイアログだけでは不十分

テストの両半分を実行してください。正しい認証情報と有効な応答は成功するはずで、正しい認証情報とわざと誤った応答は拒否されるはずです。両方が成功するなら、クライアントは何も検証されない入力を集めており、ダイアログは制御と取り違えられています。この一つのテストは、どれだけプロファイルを見直すよりも多くの配備を捕まえます。

次に、再接続後の接続を、登録されていないアカウントで、利用者が実際に使うクライアントを通して繰り返してください。プロンプトが出るのはクライアントの挙動であり、誤ったコードが拒否されるのはサーバーが何かを強制しているということです。