IKEv1 と XAuth・OTP：各プロンプトは何を求めているのか

PSK、XAuth、OTP を組み合わせた IKEv1 は、複雑なパスワードを一つ求めているわけではありません。ピア間の共有鍵、ユーザー交換、そしてバックエンドが要求方法を決める第二要素を、層として重ねています。各層にはそれぞれの持ち主と、それぞれの失敗メッセージがあります。これらを混同すると、グループ秘密を保存するフィールドにワンタイムコードを打ち直すことになります。

別のクライアントを入れたり資格情報をリセットしたりする前に、各プロンプトをそれを要求する層に結び付けてください。

三つの秘密、三つの持ち主

事前共有鍵はピア間の関係に属し、両端を管理する人が一度だけ設定します。ユーザー資格情報は認証バックエンドに属し、ログインのたびに検証されます。第二要素はトークンシステムに属し、その応答は試行ごとに変わります。どれも他の代わりにはならず、三つを一つのパスワードとして扱う配備は、誰も記録していなかった層で失敗します。

持ち主、有効期間、それぞれが出す失敗メッセージの三列を書き出します。診断に使えるのはその表であって、クライアントのフィールド名ではありません。

PSK：人ではなくピアのもの

この旧来の構成では、事前共有鍵がゲートウェイのペアを認証するので、ユーザーのログインがそれを置き換えることはありません。また、プロンプトではなく一般的なネゴシエーションエラーを招く形で誤りやすい値でもあります。ユーザープロンプトが出る前にトンネルが失敗するなら、疑うべきは鍵かプロポーザルです。

ユーザー資格情報では最初のフェーズの失敗は直せません。それをローテーションしても、安全にローテーションできる唯一の資格情報を無駄にし、誤った見立てを補強するだけです。

XAuth：旧来のユーザー交換

XAuth は IKEv1 のピア認証の上にユーザー認証交換を追加するもので、どのバックエンドで検証するかはゲートウェイが決めます。そのバックエンド次第で、交換はディレクトリのパスワード、RADIUS 資格情報、トークン応答のいずれかを受け付けます。XAuth という語が指すのは交換の輸送方式であり、資格情報の種類ではありません。

ゲートウェイプロファイルがどのバックエンドを指しているかを確認します。それで、ユーザーが何を求められるのか、パスワードのリセットが実際に何を変えるのかが分かりますが、どちらもクライアントプロファイルには見えません。

OTP：バックエンドが求めるもの

パスワードの後に別途ワンタイムコードを求める配備もあれば、文書化された区切り文字を使う結合入力形式を定めている配備もあります。どちらも存在し、目の前のプロファイルがどちらかを決めます。別のサイトでうまくいったからと連結形式をでっち上げるのは、登録トークンを無駄にする最もよくある方法です。それを決着できるのはゲートウェイ自身の文書だけです。

ゲートウェイが提供する交換を完了できるクライアントで、文書化された形式を使ってください。

クライアントの境界が効いてくる場面

Fortinet によれば、FortiClient 7.4.4 以降は IPsec VPN 向けの IKEv1 をサポートしなくなりましたが、これは全面的な削除ではなく製品とバージョンの境界だと、FortiClient の互換性に関する注記が記録しています。他のクライアントも同様に互換ではなく、OpenConnect と openfortivpn は任意の IKEv1 プロファイルではなく特定のゲートウェイプロトコルを話します。インストール済みクライアントの IKE バージョン、PSK モード、XAuth 対応、相互作用モデルを個別に確認してください。別の方法で接続するクライアントは、元の要件を満たしたことを証明していません。

IKEv1 は非推奨なので、サポートされない古いクライアントの上に組んだ新しい展開は短命な解決策です。第二要素をそこでどう扱うかも含めて、サポートされる移行経路をゲートウェイの管理者に尋ねてください。

要因を無効にせずに診断する

ログの中では、ピアのネゴシエーション、ユーザー交換、第二要素の結果、その後のアドレスとルートの割り当てという段階を分けてください。コードをあちこちのフィールドで試すのではなく、どのコンポーネントのどの段階かを記録します。テストを通すために要因を無効にすると、そのトンネルは配備について何も証明しません。

登録用の秘密と共有鍵は、組織の手順に従って保護された保管場所に置きます。常設ファイルに置かれたワンタイムコードは、もはや第二要素ではありません。