strongSwan EAP: IKE ID と期待される AAA 名

strongSwan EAP クライアントは二つのサーバー名を検証できます。remote.id は IKE ゲートウェイを、local.aaa_id は EAP サーバーを対象とし、両者は同じフィールドではありません。

IKEv2 上の EAP 認証では、一つの接続で二つの異なるサーバー名を検証するようクライアントに求めることがあります。IKE を終端するゲートウェイは一つの ID を提示し、内部の TLS 交換を終端する EAP バックエンドは別の ID を提示することがあります。strongSwan ではこれらは別々の設定ブロックにあり、間違ったブロックに名前を置くと証明書の問題のように見える失敗になります。どの検証が失敗したかを読むことが、どのブロックを編集すべきかを教えてくれます。

一つの接続、二つのサーバー ID

一つ目の ID は IKE 交換に属します。クライアントはアドレスを呼び出し、相手が特定の ID、通常はゲートウェイ証明書の名前を証明することを期待します。

二つ目は EAP に属します。PEAP または TTLS では、クライアントは IKE SA の内側で認証サーバーへの TLS トンネルを構築し、その内部サーバーが独自の証明書を提示します。バックエンドが別のホストである場合、その名前はゲートウェイの名前と異なります。一つ目の名前だけを確認するクライアントは、二つ目が主張する内容をそのまま受け入れます。両方の場所に同じ名前を設定したクライアントは、両者が実際に異なった時点で失敗します。

どちらの名前も運用者の設定から来るもので、エラーを消す証明書から来るものではありません。運用者に展開の詳細を尋ねるほうが、二つのホスト名を推測するより速いです。

どのフィールドがどの層に属するか

swanctl ではアドレスと IKE ID は別々の設定であり、EAP ID は三つ目です。

リモートアドレスはパケットの行き先を選び、リモート ID は相手が何を証明すべきかを示します。EAP の期待値は local ブロックの下に書きますが、それは相手の IKE の振る舞いではなく、このクライアントの EAP 交換を記述するものだからです。この配置こそが読み違えられる部分です。名前はサーバーを記述しながらクライアントの設定に置かれるため、まさにそれが不自然に見える理由です。

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

この断片は完全な接続ではありません。信頼素材、資格情報、子接続のポリシーがまだ必要であり、そのまま動作中のファイルにコピーすると、まだ必要な設定を置き換えてしまいます。

aaa_id が local の下にある理由

local ブロックは、認証時にこの側が何をするか、使用する方式と、その方式に対して相手側に期待する ID を記述します。AAA サーバーが同じマシンで動くとはどこにも書かれていません。

既定値が罠を鋭くします。明示的な値が設定されていない場合、期待される AAA ID はリモート ID に従うため、単一名の展開は動作し、区別を隠します。明示的な値は、EAP の展開が本当に別の場所で終端する場合にのみ意味を持ちます。その理由なしに別の名前に設定すると、運用者が再現できない失敗を生みます。二つ目の名前を発明する前に展開を読んでください。

値はバックエンド証明書が実際に主張する内容と同一に保ち、名前の形式も含めてください。末尾のドットやホストを覆わないワイルドカードだけでも検証は失敗します。

分割を表現できないフロントエンド

NetworkManager プロファイルは swanctl と同じ設定インターフェースではありません。その背後にあるプラグインはより狭い ID 制御しか公開せず、どれが存在するかはインストールされたバージョンによります。

展開が本当に二つの名前を必要とする場合、これが問題になります。サーバー ID というラベルのフィールドは一方の層だけを設定し、もう一方は設定しないことがあるため、プロファイルが正しく見えても内部の検証で失敗します。プロファイルがこの構成を表現できると仮定する前に、インストールされたプラグインが何をサポートするか確認してください。できなければ、選択は運用者にあり、別のプロビジョニング経路か修正されたサーバー ID 設計のどちらかになります。PEAP を弱めることや任意の名前を受け入れることは、認証ポリシーを直すのではなく変えてしまいます。

代替案はクライアント側で発明するものではありません。サポートされる構成を書面で求め、その回答をプロファイルと一緒に保管してください。

ID の不一致と期限切れ証明書を区別する

名前の不一致と期限切れ証明書は別の失敗であり、ログはそれらを区別します。どのフィールドを変えるかを決める前にメッセージを読んでください。

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

意図した AAA ID を設定しても証明書は更新されず、その発行者への信頼も確立されず、証明書を更新しても誤った期待名は修正されません。別の ID フィールドを編集する前に、どの検証が失敗したかを読んでください。その後で設定を再読み込みし、読み込まれた接続が設定した値を表示することを確認してください（読み込まれていない編集済みファイルは何も変えないため）。両方の名前とその層を展開ノートに書いてください。

関連記事