両方のピアが AES に対応し、どちらも SHA-256 を受け入れているのに、トンネルは上がりません。提案は誰も比較していなかった要素、通常は鍵交換グループで失敗しています。この手順書は、何かを変更する前に実際の交換を読み、対象を絞ったポリシーを一つ適用し、以前のパラメーターを復元するロールバックを残します。

グループを変更する前に失敗を読む

「ポリシー一致エラー」は要約であり、診断ではありません。相互に受け入れ可能な提案が見つからなかったという意味で、どの要素が拒否されたかは何も語りません。特定のグループに関する証拠ではなく、調査の出発点として扱ってください。

答えは通常サーバー側にあります。適切なレベルに設定した strongSwan のログには、クライアントから受け取った提案と受け入れるよう設定された提案が並び、二つの一覧の差分が失敗した要素を示します。

古いフォーラムの投稿に書かれた内容をクライアントが提示していると決めつけないでください。提示される一覧を決めるのは有効なプロファイルとそこに導入されたポリシーであり、更新された Windows ビルドは、参照しているスクリーンショットとは異なるセットを提示することがあります。

両方の一覧を書き留めます。四つの変換位置と一つのグループは短い一覧で、行ごとに比較するほうがどんな実験よりも時間がかかりません。四つの位置は目で追いやすいままです。ログ ファイルはそうはいきません。

なじみのある名前ではなく、すべての変換を比較する

IKE 提案は、すべてが一致しなければならない選択肢の集合です。暗号化は交渉を保護し、整合性または PRF がそれを認証し、Diffie-Hellman グループが新しい鍵素材を確立します。最初の二つで一致し三つ目で異なる提案は、両方のピアにとって依然として受け入れられません。

ここで混同される二つの Windows フィールドは 異なるフェーズに属します。DHGroup は IKE の鍵交換に適用され、PfsGroup はトラフィックを保護する子アソシエーションに適用されます。二つ目を変更しても一つ目の失敗は修復できません。

グループ名は実装ごとに異なり、これも混乱の独立した原因です。strongSwan は modp2048 と ecp256 と書き、Windows は Group14 や ECP256 といった列挙名を使うため、比較するにはまず読み替える必要があります。両方の名前を並べた二列のメモを残してください。そうすれば次の不一致は数秒で分類できます。

TransformWindows parameterstrongSwan nameFailure it causes
EncryptionCipherTransformConstantsaes, aes256gcm and similarNo common proposal at all
Integrity or PRFAuthenticationTransformConstantssha256, sha512 and similarProposal rejected after encryption matches
Key-exchange groupDHGroupmodp2048, ecp256Exchange fails during key establishment
Child SA protectionPfsGroupesp proposal groupsTunnel negotiates, data association does not

完全で対象を絞ったポリシーを一つ適用する

ネイティブな IKEv2 プロファイルでサポートされる手段は、接続ごとの IPsec ポリシーであり、フィールド単位ではなく一つのオブジェクトとして設定します。まずプレビューし、そのうえで適用し、以前のパラメーターは変更記録に残してください。

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

-WhatIf スイッチはローカルの変更をプレビューし、何も適用しません。これは有用であると同時にありがちな落とし穴でもあります。プレビューはパラメーターがローカルの cmdlet にとって構文的に受け入れ可能であることしか示さず、ゲートウェイが結果の提案を受け入れるかどうかは何も語らないからです。

ついでにスコープも合わせてください。すべてのユーザーのストアにある接続には、対応するすべてのユーザー向けパラメーターが必要で、同じ表示名のユーザーごとのプロファイルを編集しても、トンネルが使わない別のオブジェクトが変わります。

そのうえでテスト前に strongSwan 側も同じセットに合わせます。両端を協調して変更することだけが収束する唯一の方法で、片側だけを変えて何度も再試行すると同じ拒否で埋まったログができます。

交換と鍵の更新を別々に検証する

接続の成功は一つの観測であり、鍵の更新はまた別の観測です。最初の IKE 交渉は一つのパラメーター セットを使い、トラフィックを運ぶ子アソシエーションは後から独自のポリシーで再交渉されることがあります。接続してしばらくすると落ちる構成は、通常は二つ目のケースです。

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

最初のコマンドは、確立されたアソシエーションについてのサーバーの見方を示し、子 SA とその残りの有効期間も含みます。二つ目はクライアント プロファイルが現在保持している内容を示し、設定したポリシーが有効なポリシーであることを確認できる唯一の方法です。

成功を宣言する前に、完全な鍵の更新を観察してください。子アソシエーションが置き換わるのに十分な時間だけ接続を維持し、そのうえでトラフィックが続くことを確認するということです。ポリシーの不一致のほとんどは、最初の交渉が更新の受け入れないセットでも成功しうるために、この手順に隠れています。

ロールバックは以前のパラメーター セットであり、寛容な代替手段ではありません。クライアントが古く弱いグループしか提示していなかったなら、答えはクライアントとサーバーの共通ポリシーを改善することで、そのグループをゲートウェイに追加し、将来のあらゆるピアがそこまで引き下げて交渉できるようにすることではありません。

四つのパラメーター、グループ、接続のスコープ、鍵の更新の結果を記録します。短いメモですが、これが手順書と、あのときトンネルが上がったという物語との違いです。

関連記事