AWS Site-to-Site VPN で MODP3072 が入る場所

要件として IKEv2、ESP、MODP3072 が送られてきたのに、コンソールにはその名前のフィールドがありません。間違いは、それを探しに行くことです。IKEv2 はネゴシエーションのバージョン、ESP は保護されたトラフィックを運ぶプロトコル、MODP3072 は鍵交換グループ、つまり IANA のグループ 15 です。この三つの事実は三つの別々の場所にあり、グループは二度現れます。

その一文は一つの設定ではない

何かに触れる前に、要件をオプション一覧に置き換えてください。下の表が対応関係のすべてです。

MODP3072 はグループ 15 で、AWS は現在 Phase 1 と Phase 2 の両方の DH グループ一覧で 15 を受け付けています。両方で受け付けることは両方で必須にすることと同じではなく、ましてパートナーが両方を意図したという意味でもありません。

Phase 1 と Phase 2 は別のものを交渉する

Phase 1 は、二つのゲートウェイがどう認証し、鍵に合意し、自分たちの会話を保護するかという IKE のセキュリティアソシエーションを構築します。Phase 2 は実際のトラフィックを運ぶ CHILD SA を構築し、その鍵交換は引き継ぎではなく新しくすることができます。

この分離があるからこそ、パートナーが完全前方秘匿性と言うときは意味があります。PFS は Phase 2 の性質であり、Phase 1 の一覧にあるグループでは提供されません。各要件がどちらの交換に当てはまるのか、暗号化モード、完全性を AEAD 暗号が担うのか、両側の鍵更新の想定を確認してください。

AES という語や一つの DH 番号から、受け入れ可能なスイート全体を推測しないでください。二つの会話の半分ずつをつなぎ合わせたポリシーは、どちらのチームも合意していないものをトンネルが提案する原因になります。

許可された一覧は交渉結果ではない

オプション一覧は、各側が何を受け入れる用意があるかを示します。何が選ばれたかは報告しません。新しい接続で実際に選択された IKE と CHILD-SA の提案を読み、要件が単に許可されているのではなく満たされていることを確認してください。一覧にある強いオプションは、それが利用可能だったことしか証明しません。

更新にも注意してください。最初の IKEv2 CHILD SA と、後から PFS を伴う CHILD 交換では、二度目の交換が PFS グループを伴って新しい鍵素材を作るため、異なる互換性の条件が現れることがあります。受け入れテストがトンネルの最初の一分間しか見ていないなら、パートナーが気にする部分は試していません。

AWS のトンネルオプションのリファレンスは Phase 1 と Phase 2 を別々に示しており、次の要件が来る前に身につける価値のある構造です。

本当に意図しているトンネルを変える

Site-to-Site VPN 接続には、それぞれ独自のオプションと状態を持つ二つのトンネルがあります。何かを確認したり編集したりする前に、AWS トンネルの外側アドレスをカスタマーゲートウェイ側のピアに合わせ、一回の保存で両方が更新されると考えないでください。

承認された変更には、カスタマーゲートウェイ側を同じポリシーに備えさせることと、選んだトンネルが受ける中断のための時間枠が必要です。変更するフェーズでピアがグループ 15 に対応していなければ、トンネルは単に上がらなくなり、どちら側が拒否したかをコンソールは教えてくれません。

合意したポリシーをフェーズ、プロトコルバージョン、暗号化、完全性、DH グループとして記録し、保護すべき交換でそれを確認してください。ルーティング、トラフィックセレクタ、アプリケーションの許可は別のままですが、この対応づけは完全なゲートウェイ設定ではなく、多様性のための追加アルゴリズムの有効化を勧めるものでもありません。