AWS VPN にオンプレミスのサブネットを追加する: VGW と Transit Gateway の違い
BGP の広告は AWS にパケットの送信先を伝えるだけで、ローカルの経路を作るわけではありません。VGW かトランジットゲートウェイの境界を確認し、次に戻り経路のポリシーを確認します。
既存の Site-to-Site VPN が 10.60.0.0/16 を伝送しており、同じオンプレミスゲートウェイの背後に新しいサービスネットワークが 10.70.0.0/16 として現れ、プロキシが必要かと誰かが尋ねています。通常は不要です。ルーティングされた経路はプレフィックスを伝送できますが、それは三つの条件が揃った場合に限られ、どの三つかは既に運用している AWS のアーキテクチャによって変わります。仮想プライベートゲートウェイにはルートテーブルの境界が一つ、トランジットゲートウェイには二つあります。広告が正しくテーブルが誤っていると、健全に見えて何も届かないセッションが出来上がります。
ゲートウェイが実際に届けられるプレフィックスを広告する
広告が意味を持つ前に、オンプレミスゲートウェイには新しいネットワークへの先の経路が必要です。BGP で 10.70.0.0/16 を広告すると、その範囲のパケットをどこへ送るかを AWS に伝えますが、反対側でその範囲に到達できるようにするローカルの転送経路を作るわけではありません。ゲートウェイに、そのプレフィックスを保持する機器を指す経路があり、その機器がこれらのアドレスに応答するよう設定されていることを確認します。次に効くのはエクスポートポリシーと受け入れ可能なプレフィックス数の上限です。セッションが除外したプレフィックスは AWS にまったく届きません。
集約経路とより具体的な経路は意図して扱います。二方向から届く重複した経路は設計上の判断であり、後から気づく詳細ではありません。
経路その一: 仮想プライベートゲートウェイの境界
仮想プライベートゲートウェイでは、AWS VPN のルーティングのドキュメントに二つの配布モード、静的ルートと BGP 広告が説明されており、どちらもアプリケーションが実際に使うサブネットのルートテーブルに依存します。範囲全体を管理しているなら伝播は便利で、宛先をターゲットの隣に並べたいなら明示的なルートのほうが考えやすくなります。いずれの場合も確認は同じです。特定のアプリケーションサブネットのテーブルに、新しいプレフィックスに対する VPN ターゲットへの有効な経路があり、より具体的な経路に勝っているかどうかです。
健全な BGP セッションはチャネルの存在を証明します。あるサブネットのテーブルがその経路を取り込んだかどうかは何も語りません。
経路その二: トランジットゲートウェイはテーブルを一つ増やす
トランジットゲートウェイはその一つの問いを二つに分けます。VPC のサブネットは宛先をトランジットゲートウェイのアタッチメントへ送る必要があり、次にトランジットゲートウェイのルートテーブルが同じプレフィックスに対して VPN のアタッチメントを選ぶ必要があります。関連付けと伝播の設定が、どの接続ネットワークが経路を受け取るかを決めるため、VPN が正しく広告しても、正しいルートテーブルに関連付けられていない VPC には決して届かないことがあります。
よくある失敗は、一方のテーブルには存在し、もう一方には存在しない経路であり、どちらのチームも自分の側が正しいと確信しています。二つのアーキテクチャを比べると、この追加の境界がすべての違いです。見る場所が増え、誰が経路を受け取るかをより細かく制御できます。
経路の伝播も、すべてのアタッチメントにプレフィックスを与えるわけではありません。受け取るよう設定されたテーブルに配布するだけです。
戻り経路はそれ自体がポリシーの判断です
到着するトラフィックはやり取りの半分にすぎません。新しいオンプレミスネットワークには、正しいゲートウェイを通って AWS の送信元プレフィックスへ戻る経路が必要で、両端のセキュリティポリシーがその送信元と宛先の組を許可しなければなりません。トンネルがトラフィックセレクタで保護範囲を交渉する場合、新しいプレフィックスはその内側にある必要があり、そうでなければルートテーブルを参照する前にパケットは破棄されます。
もう一つの落とし穴はアドレスの重複です。重複しない明示的な所有範囲なら話は単純で、重複する範囲は変換か再設計を意味し、どちらも同じ手順の互換的な変種ではありません。
新しいネットワークの送信元とアプリケーションサブネットの宛先で試し、次に逆方向でも繰り返します。一方向の試験は一方向しか証明しません。
プロキシが本当に優れた境界となる場合
要件が狭いサービスインターフェースである場合、アプリケーションがすでにそのアーキテクチャを前提としている場合、あるいは望まない変換なしにはネットワーク経路でプレフィックスを運べない場合に、プロキシはその場所を得ます。誰も確認していないルートテーブルの項目の代替手段ではありません。
次の順序で判断します。ローカル転送、広告、テーブルの境界、戻り経路のポリシーです。最初に失敗したものを直し、そのうえでルーティングされた経路がそもそも正解なのかを問います。