FortiGate Azure の再キー：peer SA プロポーザルがローカル ポリシーと一致しない

トンネルは上がり、通信は流れ、その後ログに peer SA proposal not match local policy と出ます。多くの人はこの行を、二つの設定が一度も一致しなかった証拠と読みます。実際にはもっと狭い意味です。最初の CHILD SA では一致し、最初の更新で一致しなくなったのです。最初のアソシエーションは、後のものが行う交換を一度も必要としませんでした。この違いが、どこを見るべきかを決めます。

最初の CHILD SA は継承し、その後はネゴシエートする

IKEv2 では、最初の CHILD SA は IKE_AUTH の間に作成され、その鍵は IKE SA の鍵素材から導出されます。その時点では独立した Diffie-Hellman 交換がないため、一方のピアが受け入れられない PFS グループはまだ試されていません。トンネルが正常に見えるのは、後で失敗する要件が一度も試されていないからです。

CHILD_SA の再キーは別のメッセージ シーケンスです。PFS が設定されている場合、ピアは新しい鍵交換を行い、双方が受け入れるグループと、新しいアソシエーション用の ESP プロポーザルに合意する必要があります。ずれが可視化されるのはこの瞬間であり、エラーが経路ではなくプロポーザルを名指しする理由でもあります。

つまり「昨日は動いていた」はプロポーザルについて何も語りません。最初の交換が成功したこと、つまり既に知っていたことを語るだけです。

失敗した交換を読む。最初の ping ではない

何かを変える前に、両端から成功した IKE 認証、最初の CHILD SA、失敗した交換用アソシエーションを集めてください。次に操作を正確に呼び分けます。IKE SA の再キー、IKE の再認証、CHILD SA の再キーは三つの別のイベントであり、日常会話の「フェーズ 2」はそのすべてを指します。

下のフィールドは、トンネル全体ではなく、失敗した接続について比較してください。

FortiGate で、そのトンネルのフェーズ 2 プロポーザル、PFS 設定、受け入れ済みの DH グループを開きます。以前に確立した接続から推測するのではなく、読み込まれている値を読んでください。GUI ページのスクリーンショットは稼働中の設定より弱い証拠です。アップグレード後に両者が食い違うことがあるからです。変更したセクションをエクスポートし、チケットと一緒に保管してください。

Azure の既定ポリシーもポリシーである

接続にカスタム ポリシーが付いていないことは、Azure が何も適用しないという意味ではありません。接続はゲートウェイの既定プロポーザル セットにフォールバックし、それは FortiGate が提示するものより広いことも狭いこともあります。 両方のセットが IKE では重なるが、PFS 付き ESP では重ならない場合、まさにこの失敗パターンになります。

この読み取り専用ビューは、秘密を出力せずに、実際に付いているポリシーを示します。

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

実際のリソース名を使ってください。明示的なポリシーが必要なときは、接続リソースに設定します。ゲートウェイ全体のスイッチではなく、同じゲートウェイの他のトンネルに黙って適用されることもありません。

ポータルでは、その接続の Configuration ページがカスタム IPsec/IKE ポリシーを置く場所です。Microsoft の カスタム ポリシーのガイド に、サポートされるパラメーターと SKU の要件が一覧されています。Azure は接続ごとに一つの完全な組み合わせを取るため、IKE のフィールドと IPsec のフィールドを一緒に指定します。一つずつではありません。

PFS は要件であり、切り替えるスイッチではない

セキュリティ ベースラインが PFS を要求するなら、解決策は双方のピアが両側で受け入れるグループを、一致するポリシーで表現することです。エラーを消すために PFS を切ると、保とうとしていたセキュリティ特性が変わり、通常は後で別のずれとして再発します。

Azure 特有の落とし穴が一つあります。ESP に GCM を選ぶ場合、暗号化と整合性の選択は同じ GCM アルゴリズムと同じ鍵長を指定しなければなりません。GCM 暗号を別の整合性アルゴリズムと混ぜると、サービスが拒否する組み合わせになり、ポリシーを注意深く読むまでピア間のずれのように見えます。

両端がサポートし、要件が許す最も強い組み合わせを選び、変更記録に書き留めてください。次の人はその記録と比較します。動いていたトンネルの記憶とは比較しません。ポリシー名だけでなく、PFS グループと ESP プロポーザルも記します。後で監査が失敗した理由や再キーが遅い理由を誰かが尋ねたとき、その一行が両方の問いに答えます。

失敗した交換を検証する

ポリシーの編集は直そうとしているトンネルを中断し得るため、変更は復旧経路とともに計画してください。通信が戻ったら CHILD_SA の更新を待つかトリガーし、新しいアソシエーションが想定した PFS グループで確立されたことを確認します。続いて、アプリケーション通信がその上を流れ続けることを確認してください。

二つの誤った手がかりに触れておきます。SA の有効期間はローカルな仕様なので、値が異なるのは正常であり、変えても問題が現れる時期がずれるだけです。DPD はピアが生きているかを検出します。タイムアウトを延ばしても ESP や PFS の選択は揃いません。

変更後にネゴシエートされた結果と次のイベントを記録してください。IKE 認証が完了する前に接続が失敗するようになったなら、見ているのは今編集した IKE 設定であり、元の CHILD 更新の失敗ではありません。