RADIUS が VPN ユーザー名ではなく IP アドレスを見る理由

Windows の IKEv2 クライアントが接続し、RADIUS 要求にはアカウント名があるべき場所にアドレスが入って届きます。まだ何も失敗しておらず、紛らわしいのは、ゲートウェイが クライアントが IKE 層で提示した識別情報 を報告している点です。バックエンドが求めるユーザー名は、まだ起きていない別の EAP 交換から来るのかもしれません。アカウントを変更する前に、誰がそれを要求するかを決めてください。

一つの接続を二つの識別情報が移動する

一つの接続に二つの名前が現れることがあります。IKE 識別情報はトンネル設定中にピアを識別し、eap-radius プラグインは最初にそれを RADIUS User-Name にコピーします。EAP 識別情報は別の値で、ユーザー認証に使われ、誰も要求しなければ一度も送られないことがあります。

そのため、アカウントが存在しパスワードが正しくても、RADIUS ログにアドレスが表示されることがあります。バックエンドには間違った層について問い合わせているのです。RADIUS 属性は、選ばれた名前の輸送手段にすぎません。

ゲートウェイに EAP 識別情報を要求させる

サポートされている構成の一つでは、ゲートウェイが認証を RADIUS に渡す前に EAP 識別情報を要求します。接続のリモート認証セクションで、方式を eap-radius に設定し、EAP 識別情報を明示的に要求します。以下の断片は、独自のファイルではなく、既存の接続ブロックの内側に属します。別の配備から構文をコピーする前に、接続と構成バックエンドを確認してください。

remote {
    auth = eap-radius
    eap_id = %any
}

これにより、バックエンドは IKE アドレスではなく、クライアントが EAP 交換で提供する識別情報を受け取ります。接続についてほかに変わるものはありません。

または RADIUS に EAP 交換を開始させる

もう一つの構成では、最初の動作を RADIUS 側に置きます。プラグインは、最初の識別情報応答を待つ代わりに EAP-Start 指示を送ることができ、サーバーが交換を主導できるようになります。これはプラグイン単位の構成なので、プラグインを使うすべての接続に影響します。

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

両方を有効にして期待するのではなく、RADIUS の運用者と一つの構成を選んでください。両者は異なるワークフローを記述しており、開始することを前提とするサーバーが、会話を始めるゲートウェイを必ずしも扱えるとは限りません。プラグインのドキュメント は両方を説明し、各段階がどの識別情報を運ぶかも示しています。

一回の試行を両方のログで追う

一回の試行を両方のログで突き合わせます。IKE 識別情報を見て、次に EAP-Identity 交換が起きるかを見て、最後に認証段階がどの名前を受け取るかを見ます。EAP 交換の前にアドレスを拒否するバックエンドは、意図した識別情報が一度も見られる前に処理を止めてしまいます。

journalctl -u strongswan -f

識別システムが期待する正確なユーザー名形式を、ドメイン接頭辞も含めて保ってください。アドレス形式の値からアカウントを作り出してはいけませんし、ポリシー規則を満たすために認証を切ってもいけません。EAP 識別情報は主張された名前であり、方式はなおそれを証明しなければなりません。結果の名前をテスト記録に書き、次の試行が既知の状態から始まるようにします。

修正した流れが正しいアカウントに届いても拒否されるなら、次の証拠は識別情報ではなく EAP 方式とバックエンドのポリシーです。パスワードリセットを繰り返しても、以前のプロトコル層で選ばれた値を修復することはできません。