IKEv2交換は成功するのに認証で失敗する：どこを見るか

IKEv2の応答を受け取ったクライアントは、ゲートウェイに到達でき、双方が提案を交渉でき、最初の鍵交換が完了したことを証明しています。しかし、誰かが認証されたことは証明していません。次の交換では識別情報、証明書、またはEAPが運ばれ、接続はたいていそこで止まります。どの確認が失敗したのかを読み取ることが診断そのものであり、エラーメッセージだけではほとんど分かりません。

確認1：メッセージではなく段階を読む

拒否は、サーバーの識別情報を拒否するクライアント、クライアントの証明を拒否するゲートウェイ、アカウントを拒否する外部認証サービスの三か所から来ます。

それぞれが別のマシンに別のログ行を残し、それぞれに対処法が異なります。クライアント側でのサーバー証明書の拒否はクライアントの信頼または名前の問題であり、ゲートウェイ側でのクライアント証明書の拒否はゲートウェイの信頼の問題であり、EAPの失敗はアカウントまたはバックエンドの問題です。目にするメッセージは通常、そのいずれかについてのクライアントの要約であり、だからこそゲートウェイのログはクライアントのログと同じくらい重要です。

確認2：どの識別情報が確認されたか

クライアントは、ユーザー資格情報が提示される前に、サーバーの証明書や期待する識別情報を拒否することがあり、動作するサーバーアドレスはその確認の代わりにはなりません。クライアントが期待する識別子は、ゲートウェイが提示するものと一致しなければなりませんこれはネットワーク上の事実ではなく、設定上の事実です。

strongSwanの用語では、クライアント側のrightidと、反対側のゲートウェイ自身の識別情報であり、不一致はEAPが議論される前に失敗します。

ゲートウェイは別途、クライアントの証明書、その鍵の証明、またはアカウント認証を拒否することができ、この三つは互いに置き換えられません。ユーザーのパスワードをリセットしてもデバイス証明書は更新されず、デバイス証明書を再インストールしても誤ったサーバー識別情報は直りません。証明書の失敗では、まず時計、次に信頼チェーン、最後に期待する識別子を確認してください。swanctl --list-certsで両端の実際の保持内容を確認できます。

確認3：EAPが関与する場合

クライアントとサーバーはサポートされる方式に合意する必要があり、バックエンドは提示された識別情報を受け入れる必要があります。

ユーザー名には、展開が要求するドメイン接尾辞や特定のアカウント形式が必要な場合があり、その形式は推測ではなく文書化されています。運用者が文書化したフィールドを提供する方が変種を試すより速く、繰り返しの試行がアカウントのロックアウトを引き起こして元の段階を新しい失敗の背後に隠すという第二の問題も避けられます。方式がディレクトリに対するEAP-MSCHAPv2である場合、失敗はVPNではなくディレクトリに属するかもしれません。

識別情報の確認を無効にして識別情報の問題をテストしないでください。それは診断可能な失敗を診断不能に変え、接続を以前より弱くします。

確認4：ログイン成功後に何が起きるか

IKE_AUTHが完了すると、CHILD_SAの交渉がどのトラフィックセレクターをインストールするかを決め、そこで接続は成功しても何も通さないことがあります。

新たに機能するログインは、以前は認証の失敗の背後に隠れていたセレクターやルートの問題を明らかにすることがよくあります。トンネルが上がってもアプリケーションが宛先に到達できない場合は、識別情報ではなく、交渉されたセレクターとルートを見てください。その時点で識別情報の設定を変えるのは誤った段階を狙っており、通常は機能しているログインを壊します。swanctl --list-sasを使えば、IKE SAとは別に子とそのセレクターが確認できます。

確認5：サポートに何を渡すか

整理されたタイムラインと正確な拒否は、完全な診断エクスポートより価値があり、エクスポートには共有すべきでない秘密鍵や資格情報が含まれている可能性があります。

時刻をタイムゾーンとともに、クライアントとゲートウェイのバージョン、方式、パスワードではなく提示した識別情報の文字列、そしてそれを拒否した正確な段階を記録してください。strongSwanのIKEv2設定ドキュメントは、これらの結果を決める識別情報とEAPの設定を説明しており、フィールドを変更する前に読むべき参照資料です。その後、キャッシュされたセッションは古い設定について語るため、一度に一つだけ変えて新しい接続を再テストしてください。