Windows と FortiGate の IKEv2：人が混同する三つの設定
IKE の鍵交換、CHILD SA の保護、ピア認証は別々の三行です。二つのダイアログでグループ番号が一致しても、それらが統合されるわけではありません。
Windows クライアントと FortiGate ゲートウェイの間の IKEv2 合意は失敗し続け、一致しない番号を探すほど番号の一覧は長くなります。一覧が扱いやすくなるのは、独立して失敗する三つの行、すなわち IKE を保護する鍵交換、CHILD SA に適用される保護、そしてどちらが誰かを証明する認証に分けたときだけです。グループ番号はそのうち二つの行に現れ、それぞれ異なる意味を持ちます。
独立して失敗する三つの行
第一の行は IKE 自体の内部の鍵交換で、ネゴシエーションを保護する鍵を生成します。第二は CHILD SA の提案で、トンネルが運ぶ通信を保護します。第三は認証で、各側が何を提示し、相手がそれをどう検証するかを決めます。
失敗は異なる場所で起こります。交換の失敗はトンネルが存在する前にネゴシエーションを止めます。CHILD SA の失敗は認証が成功した後に起こり、ときに鍵の更新時にだけ現れます。認証の失敗は、最初のエラーだけを読むとログ上では交換の失敗のように見えます。
行を分けることは事務処理ではありません。どの設定を変える価値があるかが変わり、この分野全体で最も高くつく行為、つまり提案の不一致を直すために正常な証明書を作り直すことを防ぎます。一行の変更が他の二行の変更を強制すべきではありません。その独立性こそが、別々に書く理由そのものです。
Windows の二つのフィールドが制御するもの
Windows は二つのフィールドを分けて保持します：DHGroup は IKE 交換そのものを構成し、PfsGroup はトンネル内の通信を保護する IPsec ポリシーを構成します。両者は異なるフェーズに属します。Windows の IKE フィールドを FortiGate のフェーズ 2 の値と比べるのは間違った組み合わせを試すことであり、番号が一致しても基盤となる交換は依然として失敗します。
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA二番目と三番目のコマンドは、実際に存在するセキュリティ アソシエーションを報告し、これはクライアントが出せる答えに最も近いものです。メイン モードのアソシエーションがあり、クイック モードのアソシエーションがない場合は CHILD SA の問題であり、証明書の問題ではなくフェーズ 2 の不一致の兆候です。
一回の試行で何が提示され、何が選択されたかを記録します。受け入れ可能な提案を含む提示一覧と、ゲートウェイのポリシーに合わない選択案は構成の不一致であり、相互運用性の謎ではありません。
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
楕円曲線グループは署名鍵を選びません
この分野で最も根強い誤った推論は、楕円曲線の DH グループを選ぶには楕円曲線の証明書が必要だというものです。DH グループは鍵交換の材料を提供し、署名アルゴリズムは認証フレームワークがネゴシエートするものであって、IKEv2 では両者は別々の決定です。
RFC 7427 が存在するのは、まさにこれらの決定が以前は絡み合っていたからであり、署名アルゴリズムを鍵交換とは独立に広告し選択する方法を定めています。ゲートウェイは曲線グループと署名方式の選択を同時にサポートできます。
したがって、グループ変更の後にネゴシエーションが失敗したら、証明書の鍵種別を見る前に認証方式を見てください。証明書の変更は遅く危険な作業で、答えになることはまれであり、それを最初に行うと、どの変更が実際に役立ったのかを知る能力が失われます。証明書ストアに触れる前に認証の行を読んでください。
両者を合意シートの別々の行に保てば、その誤りは魅力的でなくなります。一方の行はグループを、もう一方は署名方式と身元を列挙し、どちらも他方の証拠にはなりません。
各秘密鍵を実際の所有者のところに置く
自分の証明書を提示するゲートウェイには、それに対応する秘密鍵が必要です。連鎖を検証するピアには CA 証明書が必要で、CA の署名鍵は特に必要ありません。これら三つの要素を混同することが、証明書を別のカテゴリに見せるために CA の秘密鍵を VPN 機器にインポートする原因です。
FortiOS では役割が分かれています：鍵を持つローカル証明書、ピアを識別するために使うリモート証明書、そしてその CA が署名した証明書への信頼を確立するリモート CA エントリです。秘密鍵のないリモート CA エントリは不完全ではなく、その目的に対して正しいものです。
インポートされた CA 署名鍵は、その機器を読める者すべての権限を広げます。また、検証には公開証明書と信頼の判断が必要で、新しい証明書を発行する能力は必要ないため、通常のピア検証も解決しません。
CA 署名鍵は発行者のプロセス側に置き、どの機器がどの鍵を持つかを記録します。監査で誰が誰になりすませたかを問われたとき、短い所有者の表は長いアルゴリズムの表より価値があります。在庫管理専用だと分かっている鍵をインポートする人はいません。インシデントの後にではなく、前に在庫を書いてください。