IKEv2 サーバーアドレスと ID: クライアントが実際にチェックする内容

アドレスを変更するゲートウェイは、新しい証明書の背後にある同じゲートウェイが停止している間も動作し続けることができ、その逆も起こります。アドレスはクライアントにパケットの送信先を伝えます、認証された ID は、応答するピアが信頼すべきピアであるかどうかをクライアントに伝えます。IKEv2 はこれらを 二つの別個のフィールドとして保持します、これは、これらを 一つの文字列として扱うのをやめると便利です。また、これらは異なる場所で構成されているため、一方が正しくても、他方が間違っている可能性があります。

この順序でチェックし、最初の不一致で停止します、これは、後のチェックでは前のチェックが合格したと想定されるためです。

まず、アドレスはどの値ですか

接続アドレスは、クライアントがダイヤルするもの (IP、解決される DNS 名、または負荷分散されたフロント エンド) です。それは交通情報であり、それ以上のものではありません。ID は IKEv2 ID ペイロードに組み込まれ、ピアの証明書と照合されます。アドレス ボックス内の DNS 名は期待される ID にはなりません、また、生の IP は、ソケットがそれに接続されているからといって ID になるわけではありません。

strongSwan の用語では、アドレスは right または left で、予期される ID は rightid または leftid です、これについては、IKEv2 構成ドキュメント で説明されています。アドレスを編集しただけであれば、ペアの半分が設定されたことになります。

第二に、証明書が証明できること

ID にはタイプがあり、証明書には一致する名前が付けられている必要があります。DNS のアイデンティティは、サブジェクト代替名拡張子の dNSName エントリによって満たされます、 IP ID には iPAddress エントリが必要です。vpn.example.com に対して発行された証明書は、文字通りのアドレス 203.0.113.10 について何も証明しません、また、そのアドレスに対して発行された証明書は、名前について何も証明しません。したがって、同じキーと CA が再利用されている場合でも、別の名前での再発行はドロップイン置換ではありません。

最近のクライアントは、サブジェクトの代替名が存在する場合に共通名を無視し、多くはそれを完全に無視します。SAN リストにクライアントがチェックする値が含まれていない場合、証明書がすでに信頼できるものとして受け入れられた後でハンドシェイクは失敗します、そのため、ログには信頼エラーではなく ID エラーのように記録されます。

第三に、各クライアントがどのように期待を表明するか

Windows は、入力したサーバー名またはアドレスを取得し、それに一致する証明書を必要とするため、IP を入力すると IP の期待値が作成されます。Android の IKEv2 クライアントも同様に動作し、どちらも異なるホストを指定する、公的に信頼された有効な証明書を拒否します。移行中に誰かがホスト名をそのアドレスに置き換えただけで、プロファイルが失敗し始める可能性があります。証明書に何が含まれているかを確認する前に、クライアントが何を要求したかを確認してください。

strongSwan では、期待は明示的です、rightid をサーバーが実際に提示する ID に設定しますが、これは正しくない場合があります。%any に設定すると、ピアが提供するものはすべて受け入れられ、保持しようとしているチェックが正確に削除されます。

第四に、ユーザー ログインをピア ID から分離する

EAP 認証とサーバー ID は異なる質問に答えます。[email protected] などの EAP ID は、クライアントがサーバーが正しいサーバーであると判断した後、ユーザーが誰であるかを示します。接続がユーザー ログイン段階に到達しないため、パスワードを更新してもピア ID の不一致は修正できません。

サニタイズされたレポートでは、クライアントが予期した ID、サーバーが提示した ID、および証明書の SAN エントリの両方に名前を付ける必要があります。

第五に、検証済みのチャネルを通じて変更します

ゲートウェイが正当に移動する場合は、最初にアドレスを更新し、ID はそのままにしておきます、これは IKEv2 が適切に処理するケースであるためです。ID 自体が変更された場合は、それを信頼イベントとして扱い、現在障害が発生しているエンドポイントからではなく、すでに信頼しているソースから新しい値を取得します。検証しようとしている接続を介して配信されたメッセージは、その接続に関する証拠ではありません。

最終的な住所、身元、SAN リストをプロフィールメモにまとめて記録します。次に証明書に触れた人は、三人のうち誰が移動できるかを確認します。