Windows VPN Group24 と MODP3072：どちらのグループが必要か
グループ番号はレジストリの登録項目であり、サイズの順位ではありません。名前をそのパラメーターに対応づけ、Windows のパラメーターがどのグループを表現できるかを確認します。
Group24 と MODP3072 はどちらも鍵交換グループの名前であり、強度の異なる同じグループではありません。Group24 は 2048 ビットの法と 256 ビットの素数位数部分群を組み合わせたもので、MODP3072 は 3072 ビットのグループ 15 です。指定された側と違う側を選ぶと、要件を満たすのではなく要件そのものを変えてしまいます。結果を決めるのは四つの点であり、そのいずれも似た名前を信頼することを求めません。
番号はレジストリの登録項目であり、順位ではない
IANA は鍵交換グループを登録された順に番号付けしているため、大きい番号はより強いグループではなく、より後の登録項目を意味します。グループ 14 は 2048 ビットの MODP、グループ 15 は 3072 ビットの MODP、グループ 24 は 2048 ビットの法と 256 ビットの素数位数部分群を組み合わせたものです。識別子をサイズの順位として読むと、24 を 15 より大きいとみなす誤りがそのまま生じます。名前はラベルにすぎず、その背後のパラメーターこそがネゴシエーションで実際に使われます。
| IANA group | What the group is | Expressible as Windows DHGroup | What a mismatch looks like |
|---|---|---|---|
| 14 | A 2048-bit finite-field modulus | Group14 | The gateway reports modp2048, which is the same group in other vocabulary |
| 15 | A 3072-bit finite-field modulus | Not in the documented enumeration | You cannot request it from this parameter; a gateway reporting modp3072 was configured elsewhere |
| 24 | A 2048-bit modulus with a 256-bit prime-order subgroup | Group24 | The gateway reports modp2048s256, so the two names differ while describing one group |
| 20 | The NIST P-384 curve | ECP384 | The gateway reports ecp384, and that 384 counts a field size rather than a modulus |
楕円曲線グループは独自の混乱を加えます。曲線のビット数は法ではなく体を表すため、P-384 を 3072 ビットの有限体グループと、数値が同じものを測っているかのように比較しても何も分かりません。
Windows の列挙が表現できるもの
IKE レジストリと Windows クライアントのパラメーターは、語彙の異なる別々のインターフェースです。Microsoft の VpnClient コマンドレット リファレンス は、DHGroup が None、Group1、Group2、Group14、ECP256、ECP384、Group24 を受け付けると記しています。Group15 はその文書化された集合に含まれておらず、つまりこのパラメーターでは要求されたグループを表現できません。これはインターフェースの制約であり、プロトコルがどのグループをサポートするかについての記述ではありません。
一覧にない綴り、整数、コピーしたポリシー文字列を渡しても列挙は広がりません。実際に展開する Windows のバージョンについてリファレンスを確認し、グループが利用できない場合の正直な結論は、別の承認済みポリシーか別のクライアントです。
DHGroup、PfsGroup、証明書の種類を分けて考える
DHGroup は IKE 鍵交換のグループを選び、PfsGroup は後続の保護トラフィックのアソシエーションに対する前方秘匿性を司ります。別々のフィールドなので、一方を正しく設定しても他方については何も言えません。証明書の RSA または ECDSA 鍵は三つ目の属性であり、一時的な交換ではなく認証に属します。したがって一つのプロファイルが ある層では正しく別の層では誤っていることがあり、接続に成功してもどちらかは分かりません。
特定の証明書の種類がすべての IKEv2 接続で ECP グループを強制したという報告は、一つの設定の組み合わせを述べているにすぎません。それはプロトコルの規則を確立するものではなく、規則として扱うことが局所的な癖をポリシーに変える道です。
ゲートウェイがネゴシエートしたグループを読む
VpnClient モジュールは Set-VpnConnectionIPsecConfiguration を書き込み専用のインターフェースとして提供し、ホスト上でそのポリシーを読み戻す対応する Get- コマンドレットはありません。適用した DHGroup と PfsGroup の値を記録し、実際に交換が何を使ったかをゲートウェイで読み取ります。コマンドは新しい接続の後に実行し、古いアソシエーションを再利用した再接続の後には実行しないでください。
swanctl --list-sas
ipsec statusallプロファイルが Group24 を報告し、ゲートウェイが modp2048s256 を報告するのは、二つの語彙で同じグループだから整合しています。ゲートウェイが modp3072 を報告し、プロファイルが Group24 と言うのは整合しておらず、どちらかの端点が想定どおりに適用していません。証明書の行は別個の認証の問いに答え、PFS フィールドは三つ目の問いに答えます。コンプライアンスの記録を書く前に三つすべてを比較してください。
要求したグループ、ネゴシエートされたグループ、設定を受け入れたか拒否したインターフェースを記録します。レビュー担当者が必要とするのはこの三つ組であり、そのどれもポリシー名から推測することはできません。