1つの AWS VPN トンネルに複数の LAN：SA 制限の意味

AWS Site-to-Site VPN に二つ目の拠点 LAN を追加するのに、そのトンネル内で二つ目の独立した IPsec アソシエーションは要りません。多くの人がつまずく制限は実在しますが、聞こえより狭いもので、AWS は トンネルごとに一組の IPsec SA ペアを文書化しており、上り一つと下り一つで、一つの接続の二つのトンネルがそれぞれ自分のペアを持ちます。これはサービスの性質であり、IPsec が一度に一つのサブネットだけを保護するという規則ではありません。この区別が最も重要になるのは、ポリシーベースのカスタマーゲートウェイが各ポリシー項目を独自のアソシエーションに変えるときです。

LAN の一覧ではなく、接続から始める

コンソールで接続を開き、どのようにルーティングされるかを確認します。静的接続は宣言したリモートプレフィックスを運びます。BGP 接続はカスタマーゲートウェイからそれらを学習します。

いずれにしても、トンネルはルートベースです。中に何が通るかは、デバイスがネゴシエートするセレクターで決まり、フォームに入力できるサブネットの数では決まりません。

カスタマーゲートウェイが何をネゴシエートするかに注目する

ポリシーベースのデバイスは、すべてのポリシー項目を独自の SA に変えられます。二つの LAN は二つの項目、つまり二つの SA を意味し、ここでトンネルあたりの制限が効いてきます。 カスタマーゲートウェイの要件 はまさにこの動作を警告し、そうしたデバイスでは統合ルールを提案しています。デバイス上の ACL の数ではなく、ネゴシエートされたセレクターを確認してください。

デバイスは両方のプレフィックスを単一のポリシーの下に提示するよう設定する必要があり、そうでなければ対向側は結果を保持できません。

三つの台帳を分けて保つ

この三つの一覧を混ぜると、あらゆる変更が推測になります。別々の列として保ち、それぞれを自分のネットワーク向けに埋めてください。

SA 制限に縛られるのは真ん中の列だけです。最初の列はビジネス上の事実であり、三番目の列はアプリケーションを動かすものです。書いた ACL 行の数からカバレッジを推測するのではなく、デバイス上で受け入れられたセレクターを読んでください。

権限を広げずに統合する

要約ルートは一つのポリシー項目を得る明白な方法であり、保護対象の集合が静かに増える方法でもあります。両方の /24 をカバーする /20 は、どちらの拠点も使わないアドレスもカバーし、トンネルはそれらを喜んで運びます。要約が必要なら、受信側でフィルタリングと組み合わせ、余分な空間を単に告知しないのではなく拒否させてください。拒否されたパケットは証拠です。告知されないアドレスは、証拠の不在にすぎません。

保護ポリシーの統合は、何を暗号化できるかの変更です。アクセスの付与ではなく、そのように扱うべきでもありません。

両方の LAN をテストし、その後も両方のトンネルを保つ

調整された変更の後、有効な保護範囲を確認し、次に各 LAN から実際のアプリケーションを実行します。一つのサブネットが動いても、二つ目のセレクターのカバレッジについては何も証明できず、その応答経路についてはなおさらです。

設計に両方のトンネルを残してください。ポリシーの統合は冗長性を捨てる許可ではなく、すべての拠点 LAN を運ぶ一本のトンネルは、次の保守ウィンドウを停止に変えます。

ネゴシエートされたセレクター、二つのプレフィックス、ルートの所有者を同じ変更記録に書いてください。三つ目の LAN が来たとき、その記録はセレクターを追加しているのか、最初からやり直しているのかを教えてくれます。