AWS の NAT ゲートウェイは VPN に対してどの送信元 IP を使うのか

パートナーからサイト間 VPN 経由でどの送信元レンジが届くのかと聞かれたため、VPC コンソールを開きます。NAT ゲートウェイのページには Elastic IP が関連付けられたパブリックゲートウェイが表示され、そのアドレスを送って済ませたくなります。インターネット経路には正しい答えで、VPN 経路には間違った答えであり、違いはルートテーブルがどのゲートウェイを指しているかにあります。許可リストを書く前に経路をたどってください。

許可リストではなく NAT ゲートウェイのページから始める

NAT ゲートウェイのページにはサブネット、タイプ、Elastic IP が表示され、この三つの項目だけで始められます。そこに書かれていないのは、その後にトラフィックがたどる経路です。それは NAT ゲートウェイのサブネットに関連付けられたルートテーブルから分かります。

パブリックかプライベートかで後でチェーンにインターネットゲートウェイが現れるかが決まるため、まずタイプを読みます。二番目のルートはそこにあるので、次にサブネットを読みます。

二つの変換を追う

パブリックもプライベートも NAT ゲートウェイは、ワークロードのプライベート IPv4 送信元を NAT ゲートウェイ自身のプライベート IPv4 アドレスに変換します。この最初の変換はタイプに関係なく行われます。忘れられがちなのは二番目の変換です：パブリック NAT ゲートウェイはトラフィックをインターネットゲートウェイに渡し、そこがアドレスを関連付けられた Elastic IP にマッピングします。

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

プライベート経路ではチェーンにインターネットゲートウェイがありません。トラフィックがトランジットゲートウェイや仮想プライベートゲートウェイを通って出るとき、NAT ゲートウェイのガイドは NAT ゲートウェイのプライベートアドレスを、リモート側が受け取る送信元として記録しています。パートナーが許可すべきはそのアドレスであり、Elastic IP ではありません。

VPN 経路は通常プライベートアドレスを示す

10.20.1.0/24 にあるワークロードがパートナーのプレフィックスに到達する場合、ワークロードのサブネットのルートテーブルは NAT ゲートウェイを指し、NAT ゲートウェイのサブネットのルートテーブルはプライベートゲートウェイの経路を指します。どちらのホップも重要で、パートナーが見るものを決めるのは二番目だけです。NAT サブネットに VPN 経路へのルートがない場合、パケットは決して届かず、それは誤った送信元アドレスとは別の障害です。

アドレスの話をする前に、その二番目のルートを確認してください。ルートの欠落と誤って報告された送信元は、単にトラフィックが見えていないパートナーにはまったく同じに見えます。

二番目の変換が答えを変えるとき

AWS はトランジットゲートウェイのアタッチメント上で、明示的な一致する一対一の NAT マッピングも提供しています。そのマッピングはリモートのサービスが見る前に送信元をさらに変換でき、単にルーティングするだけの既定の動作ではありません。意図的に設定する必要があるため、偶然に引き継ぐものではなく設計上の例外として扱ってください。チームの誰も有効にした記憶がないなら、アタッチメントを読むまで存在しないとみなしてください。

設計でそれを使う場合、許可リストは NAT ゲートウェイのアドレスではなく最終的なマッピングを記述する必要があります。同じ注意は可用性の経路にも当てはまります：複数のゲートウェイアドレスが関与する場合、想定される送信元の集合は和集合であり、代表的な一つのアドレスではありません。各アドレスがどの変換に属するかを書き留めてください：出所のないリストは後から監査できません。

プライベート NAT ゲートウェイは、インターネットゲートウェイに向けてもインターネットサービスを与えられません；AWS はそのようなトラフィックが破棄されると記録しています。タイプは要件の VPN という言葉ではなく、経路全体から選んでください。

パートナーが行動できる契約を書く

使える契約には四つの部分があります：フローを開始する方向、パートナーが見る変換後の ID、その ID の戻り経路、適用される保護の範囲です。NAT ゲートウェイのフローはサポートされる送信元側から開始されるため、プライベートなワークロードを公開するための受信ポート転送サービスではありません。それを早い段階で声に出して言えば、どちらも相手が開始したと思い込んでいる設計レビューを防げます。

変換はアドレス重複の緩和と予測可能な送信元ポリシーを買う一方、パートナーのログでの個別のワークロード ID を失います。監査でワークロードごとの帰属が必要なら、変換された送信元アドレスから復元しようとせず、その ID をアプリケーション層で保持してください。

新しいアタッチメントや再関連付けされたサブネットが静かに答えを書き換えるため、変更のたびに両方のルートテーブルを再確認してください。