問題文
AWS Cloud VPC を使用したビジネス継続計画には、以下の要件があります。
- 開発者のAWS VPCプライベートサブネットには、各開発者用のワークスペース（AWSセキュアデスクトップサービス）があります。
- これらのワークスペースから、各開発者は VPN を使用して、パブリック クラウド GCP/AWS/Azure やオンプレミス データセンターなどのさまざまなリモート クラウドに接続できます。これらのさまざまなリモート データセンターやパブリック クラウドでは IP アドレス範囲が重複している可能性があり、これらの IP 範囲の管理は制御できません。
- 開発者は、VPNを使用してワークスペースから異なるクラウド間を簡単に切り替えて接続できます。
AWSネイティブのサービス/機能は直接的には役に立ちません
サイトツーサイトVPN- これらの要件を満たすために、AWS サイト間 VPN トランジット ネットワークは、重複する IP 範囲を許可しないため、範囲外です。重複する IP
アドレス範囲を解決する間接的な方法として、AWS ドキュメントに冗長なサイト間 VPN プランがありますが、これはフェイルオーバー シナリオ用であり、すべてのリモート クラウドがいつでも接続できる (つまり、常にアクティブである) 必要があります。
トランジットゲートウェイ- AWS Transit Gateway は、マルチクラウド ネットワークの IP 範囲の重複を理想的には許可しないため、役に立ちません。Transit
Gateway で複数のルート テーブルを使用して、ルートのセグメンテーション、つまり相互接続するクラウドの個別の組み合わせのルーティング パスの分離を行う方法はありますが、このアプローチでは Transit Gateway アタッチメントを使用したセグメンテーションが必要であり、AWS VPC は複数のアタッチメントを持つことができません。
また、そのようなことを行ったとしても、EC2 インスタンスでソフトウェア VPN を使用している可能性があります (可能かどうかはわかりません)。開発者の AWS VPC サブネット ルート テーブルでは、宛先に重複する IP 範囲を持つことができないため、各ワークスペースから簡単に接続してさまざまなクラウドに切り替えることができるかどうかはわかりません。
解決策に対する私のアプローチ
私のネットワークプラン
同じサブネットで、ソフトウェアベースのIPSec VPNアプローチを使用することを考えていました。つまり、EC2の1つのインスタンスにstrongswanのようなVPNサービスとSNAT用のIptableルールを配置します。このアプローチは、AWSサポートの回答からヒントを得ています。VPNトラフィック用のNATを構成する
各クラウド/データセンターには、ソフトウェア IPSec VPN と IPtable ルールを使用して EC2 インスタンスがセットアップされます。リモート
側にも、AWS VGW とカスタマー ゲートウェイのペアリングと同様に、VPN 用のゲートウェイがあります。VPN
を使用して Workspace から適切なリモート クラウドにトラフィックを送信するには、宛先をリモート クラウドの IP アドレス範囲、ターゲットを VPN EC2 インスタンスの eni ID として、サブネットのルート テーブルにエントリを作成する必要があります。
このアプローチの問題点繰り返しになりますが、IP アドレスが重複しているリモート クラウドの場合、開発者の AWS VPC サブネット ルート テーブルにエントリを設定できません。
この問題を解決するために、私は、重複するリモート クラウドごとに完全に架空の、または非現実的な IP 範囲を設定する IP 範囲操作のようなものをしようと考えていました。つまり、実際の IP 範囲が 192.168.xy/16 のクラウドの場合、非現実的な範囲は 10.10.pq/16 になります。
その後、これらのリモート クラウドごとに個別の EC2 VPN サーバーを用意します。次に、リモート クラウドのいずれかのルートについて、ルート テーブルのエントリは、宛先として 10.10.pq/16、ターゲットとして EC2 VPN サーバーの eni ID になります。EC2
VPN サーバーでは、IPtable ルールを設定し、次に示すように、IP のみの転送に対して PREROUTING DNAT や POSTROUTING SNAT などの操作を行います。スタックオーバーフローQ/Aワークスペースの開発者は、
非実際の IP と実際の IP 間のマッピングを理解し、非実際の IP を使用してトラフィックを送信する必要があります。このマッピングを最新のマッピングに更新するには、カスタム スクリプトを使用して EC2 VPN サーバーの Iptables ルールを更新する必要があります。
上記のアプローチの正確性や有効性については確信がありません。
上記のアプローチから生じるもう一つの問題
また、リモート クラウド内の特定の IP を持つインスタンスに接続したとしても、サーバーレス関数や API、または DB/LB などのマネージド/抽象サービスなどの別のクラウド サービスにアクセスする場合はどうなるのかという疑問も生じます。
ただし、これは、開発者の VPC で IGW を使用してトラフィックを送信するか、リモート クラウド内の要塞ホストに接続することで実行できます。
インターネットで検索した他のアプローチカスタム マルチクラウド オーバーレイ ネットワークを設定することは、困難でロケット科学のように思えます。
また、OpenVPN などのオープンソース VPN やファイアウォール/ネットワーク ソフトウェアなどの pfsense のネイティブ機能の一部が、私の元の問題を解決するのに役立つかどうかもわかりません。
私はネットワークや VPN に関する知識をすべて AWS クラウドで作業しながら習得しており、コンピュータ サイエンスにおける一般的なネットワークの詳細に精通しているわけではありません。
これらの問題の解決にご協力ください。