重複した IP アドレス範囲を持つネットワーク間接続

本稿では、重複した IP アドレス範囲を持つネットワーク間接続のいくつかの方法を紹介していますが、第一に VPC の IP アドレス範囲は、通信するネットワークと重複しないように慎重に設計することが重要です。

お客様のネットワークにて、IP アドレス範囲が重複したリソース同士が通信する必要のある状況がよく見られます。これは、企業が買収された際、同じプライベート (RFC1918) アドレス範囲を使用している場合によく発生します。しかし、固有の IP アドレス範囲を持つサービスプロバイダーが、同じ IP アドレス範囲を持つ2つの異なるコンシューマーにアクセスを提供する際に発生する可能性もあります。

ネットワークの重複は意図せず発生することもあります。Amazon SageMaker や AWS Cloud9 などの一部の AWS サービスでは、特定の IP アドレス範囲が自動的に予約されます。さらに、Docker などの一部のサードパーティ製品でも同様のことが行われます。定義済みの IP アドレスとの重複を避けるため、VPC を構築する際は、サービスやアプリケーションのドキュメントを必ず確認してください。

本稿では、IPv4 ベースのネットワークが抱える上記の障害に対するソリューションをいくつか説明します。アドレス空間のサイズを考えると、IPv6 を使用しているお客様にはこの問題は発生しないと予想されます。

アプリケーション間の通信方法によって、選択するソリューションが異なることに注意してください。アプリケーション間で完全な双方向接続が必要な場合があります (つまり、ネットワークセッションがどちら側からでも確立できる状態) 。また、「アウトバウンド」接続だけが必要な場合もあります。これは、一方のネットワークから他方のネットワークへのセッションは確立できるが、その逆はできない場合です。これらのパターンは、重複する IP アドレス範囲に対処するためのネットワークの設計方法に影響します。

Option 1: IP ネットワークのリナンバリング

これは常にお客様へ最初に提案することです。上記のサービスプロバイダーのシナリオでは機能しません。ただし、ネットワークのリナンバリングを行う機会があれば、それが最善の選択肢です。ネットワーク構成の変更は簡単ではありませんが、次のような長期的な苦労を避けることができます。

• ネットワーク管理コストの増加：以下に示す他ソリューションのほとんどは、有料のアプライアンスまたはサービスが必要です。ネットワークのリナンバリングは無料ではありません (結局、時間と人件費が発生します)。しかし長期的に見れば、重複するネットワークを相互に接続するために必要なコンポーネントを運用するための継続的なコストを削減できます。
• 複雑さの増大：一般的に、IP アドレス範囲の重複する2つ以上のネットワークを接続することは困難です！長期的に見れば、アプリケーション環境が拡大・変化したり、ネットワークが追加されるほど、ますます複雑になる可能性があります。
• 複雑なトラブルシューティング：問題が発生したとき、何が起きているのか、どこで起きているのか、そして対処するために何をすべきかを理解するのは、重複した IP アドレスに対処する必要がなくても十分複雑です。これら全てが混乱を招き、トラブルシューティングに通常よりもはるかに長い時間がかかる可能性があります。
• 互換性の問題：以下のソリューションはすべて、何らかの方法でネットワークアドレス変換 (NAT) を利用しています。一部のアプリケーションは、NAT では動作せず、他のアプリケーションでも使用方法に制限が生じる可能性があります。現在、 NAT で動作しないアプリケーションをお持ちでない場合でも、将来的にそのようなアプリケーションが環境にデプロイされる可能性があります。ネットワークのリナンバリングを実行すると、この問題を完全に回避できます。
• NAT を利用すると管理オーバーヘッドも増えます：アプリケーションは重複する IP アドレスを使用するため、アプリケーションが使用する元の IP アドレスと NAT された IP アドレスを追跡し更新する際に、ファイアウォールルールが複雑になります。

一般に、長期的に見てより安価で容易になるため、重複するネットワークは可能な限り、リナンバリングすることを強く推奨します。

Option 2: AWS PrivateLink

2017年、AWS は PrivateLink の提供を開始しました。これは、IP アドレス範囲が重複している場合も含め、VPC 間で API またはアプリケーションのエンドポイントを簡単に公開できる HyperPlane ベースのサービスです。また、複数のコンシューマーに接続性を提供する必要があり、リモート IP アドレス範囲を制御できないサービスプロバイダーにも理想的です。さらに、IP アドレスが重複する複雑なネットワークを持つお客様にも同じメリットがあります。これは、基礎的なネットワークアドレススキームに変更を加える必要がないため、ここで示した中で最もシンプルな方法です。

下の図では、“Provider” VPC 内にあるアプリケーションを見ることができます。このアプリケーションには Network Load Balancer (NLB) が接続されており、PrivateLink を使用することで複数の “Consumer” VPC と NLB を共有することができます。下の図では、全 Consumer VPC、Provider VPC で IP アドレス範囲が重複しています。これは最悪のシナリオです。

各 Consumer VPC では、PrivateLink エンドポイントがローカル IP アドレスを持つ Elastic Network Interface として表示されます。Provider VPC では、Consumer VPC からの接続は、Provider VPC 内のローカル IP アドレスから来たように見えます。基盤となる HyperPlane サービスは、PrivateLink を機能させるために両側で NAT 操作を実行しています。

他にも次のようなセキュリティ上の利点があります。

1. PrivateLink の接続を確立する際、プロバイダーは Consumer VPC の所有者にリクエストを送信する必要があります。次に、所有者が承認する必要があります。これは VPC ピアリングの仕組みと同じです。プロバイダーは、承認なしにコンシューマー向けの PrivateLink を作成することはできません。
2. コンシューマーとプロバイダー間で許可されるのは、設定済みの TCP ポートのみです。これにより、コンシューマーは Provider VPC 内の特定のリソースにのみアクセスでき、それ以外にはアクセスできないことが保証されます。
3. Provider VPC 内のアプリケーションが Consumer VPC への接続を確立する方法はありません。

最後に、スケーラビリティのメリットがあります。プロバイダーはアプリケーションを数百の ConsumerVPC に公開できます。

PrivateLink には、NLB の形で冗長性が組み込まれています。これにより、バックエンドサーバーおよび Consumer VPC の構成にトラフィックが配信されます。さらに、PrivateLink エンドポイントを配置するサブネットも選択できます。下の図では、複数のアベイラビリティーゾーンにまたがるマルチサブネット環境を示しています。

お客様からよくある質問の 1 つとして、オンプレミスネットワークでこのような接続を実現する方法です。下の図では、複数の独立したカスタマーに接続された Provider VPC があり、各カスタマーは VPN 経由で AWS に接続されています。Provider VPC や全カスタマーの IP アドレス範囲が重複していることに注意してください。唯一の課題は、VPN サービスがアタッチされる VPC に割り当てられる IP アドレス範囲が、オンプレミスと重複しない IP アドレス範囲を見つけることです。この例では、オンプレミスのクライアントは VPN VPC 内の PrivateLink エンドポイントに割り当てられた IP アドレスに接続します。

このソリューションは、図のCustomer C が示す通り AWS Direct Connect でも機能します。Customer C も VPN VPC で異なる IP アドレス範囲を持っています。これは 172.16.0.0/16 が既に使用されているため、VPN VPC では異なる IP アドレス範囲を使用する必要があるためと考えられます。これは問題ではありません。VPN VPC の IP アドレス範囲は、Customer C が使用するネットワークとの重複を排除する必要があるだけなため、選択できる範囲は非常に広いです。

このオプションの設定は、追加メンテナンスが不要で、冗長性が高く、拡張性も高いため、簡単です。さらに、顧客ネットワーク間を分離できます。サービスプロバイダー環境でアプリケーションを作成する場合は、PrivateLink がネットワーク柔軟性を提供できるようにソリューションを設計することを検討してください。

価格ページ通り、PrivateLink にはコストがかかることに注意してください。アプリケーションは単一の TCP ポートとして提供される必要があるため、アプリケーションによってはこのソリューションでは動作しない場合があります。アプリケーションが UDP を使用する場合、または複数の TCP ポートを持ち、クライアントがバックエンドサーバーのアフィニティを維持する必要がある場合、PrivateLink は適していません。

Option 3: VPCで複数 IP アドレス範囲を利用

アプリケーションが異なる層に分かれている場合があります。ユーザーや他のアプリケーションからのリクエストに応答するフロントエンドやミドルウェア、データベース、キャッシュ等で構成される1つ以上の “バックエンド” 層です。この環境では、フロントエンドのサブネットに重複しない IP アドレスを持たせる一方で、バックエンドのサブネットは他のアプリケーションと重複させることができます。

以下の図は、3つのアプリケーション VPC が AWS Transit Gateway に接続する様子を示しています。VPC の IP アドレス範囲は重複していますが、IP アドレス範囲の異なるフロントエンドサブネットが Transit Gateway にアドバタイズされているため、エンドユーザーはそれぞれにアクセスできることに注意してください。この場合、各 VPC の全てのサブネットをアドバタイズすべきではないため、Transit Gateway への自動ルート伝播を無効にする必要があります。

この環境では、IP アドレス範囲が重複する各 VPC (図では 10.0.0.0/22) を作成し、その後、各 VPC に重複しない2つ目の IP アドレス範囲を追加します。フロントエンドサブネットでは、Transit Gateway をターゲットとする他のフロントエンドサブネットへのルートを追加できます (またはデフォルトルートを使用できます)。

これは、バックエンドサブネットにあるサーバーをどのように管理するかという課題を解決するものではありません。実現する方法は、各 VPC のフロントエンドサブネットに踏み台ホストを配置することです。これにより、管理者は SSH または RDP を使用して踏み台ホストを経由して、バックエンドサブネットにアクセスできるようになります。また、AWS Systems Manager を使用して、ホスト上でコマンドをリモート実行したり、バックエンドホストへの SSH トンネルを作成することもできます。

バックエンドサーバーでは、リポジトリからのコードのダウンロードや適切なサーバーからの更新、アプリケーションログの送信、パフォーマンスメトリクスの提供などが引き続き必要となります。このために、AWS サービス (Amazon CloudWatch や Amazon Simple Storage Service (Amazon S3) など) のプライベートエンドポイントと組み合わせて使用することができます。サーバーが AWS 以外のエンドポイントへのアウトバウンドアクセスを必要とする場合は、フロントエンドサブネットでホストされている NAT またはプロキシサービスが必要となります。

このオプションは、重複するネットワークの一部だけをリナンバリングする必要がある場合、(フロントエンドのサブネットのみを変更することで) 作業を減らしつつ、(複雑なNATソリューションを実行せずにアプリケーションとユーザーが通信できるため) リスクの大部分を低減できることを意味します。ただし、追加コストがかかります。踏み台ホスト、NAT またはプロキシインスタンス、AWS サービス用プライベートエンドポイントなどです。また、管理コストをできるだけ低く抑えるために、このインフラストラクチャを自動化して展開および管理することを強く推奨します。

この図では、Web サーバー (または他アプリケーションのフロントエンドコンポーネント) はフロントエンドサブネットに配置されていますが、そのサブネットにロードバランサーを配置し、Amazon Elastic Compute Cloud (Amazon EC2) コンポーネントを到達不可能な IP アドレス範囲を使用して別のサブネットに保持することもできます。

このオプションでは、他アプリケーションとの重複を心配することなく、数千の IP アドレスを持つバックエンドワークロードのサブネットをデプロイできます。さらに、フロントエンドサブネットには必要最小限の IP アドレスのみを使用して、(VPC の) 外部ネットワークからアプリケーションへのアクセスを確保できます。

最後に、バックエンドサブネットには IPv4 の代わりに IPv6 の使用を検討してください。このシナリオで IPv4 を使用する場合、(上記で説明した方法を除いて) バックエンドサブネットには到達できません。IPv6 を使用することで、サブネットをオーバーラップする必要がなくなり、IPv6 に移行すると回避策なしにサブネット内のリソースに到達できるようになります。

Option 4: Private NAT Gateway を使用してサブネットを隠蔽する

2021年、Private NAT Gateway の提供を開始しました。NAT Gateway が VPC ネットワーク全体をインターネットから “隠す” (単一の Elastic IP アドレスから来たように見せる) のと同じように、Private NAT Gateway も VPC から他のプライベートネットワークに接続する際にそれを可能にします。Elastic IP アドレスと Internet Gateway の代わりに、Private NAT Gateway はVPC 内で割り当てられたプライベート IP アドレスを、VPC が “隠れる “ ためのアドレスとして使用します。

これは、VPC からオンプレミスネットワークや他 VPC に接続したいが、VPC 内のリソースには直接接続したくない環境で役立ちます。オプション3 と非常に似ていますが、VPC からの外部接続を提供するために NAT やプロキシインスタンスを実行する必要がない点が異なります。

次の図は、Private NAT Gateway の動作を示しています：

VPC の IP アドレス範囲は10.0.0.0/16ですが、その IP アドレス範囲外の2つのサブネット (10.31.10.0/24と10.31.11.0/24) が追加されていることに注意してください。各アベイラビリティーゾーンに Private NAT Gateway が追加されています (Internet-facing NAT Gateway と同様に1つで十分ですが、冗長性のため2つを推奨します)。これらは、セカンダリ IP アドレス範囲のサブネットに追加されています。NAT Gateway は、サブネットの IP アドレスを使用して、バックエンドサブネットからのワークロードの IP アドレスを変換します。

Transit Gateway 内で、フロントエンドサブネットへのルートを追加することで、戻りのトラフィックを Private NAT Gateway に送ることができます。VPC 内では、バックエンドサブネットからのトラフィックは、Internet-facing NAT Gateway のルートテーブルとほぼ同じ方法で Private NAT Gateway にルーティングされます。

この場合、バックエンドサブネットのインスタンス管理は、フロントエンドサブネットの SSM または踏み台ホストを使用して行う必要があります。アプリケーションのデプロイが自動化されていれば、これらのホストを人間が管理する必要はありません。これは望ましい結果です。

前のオプション同様に、IP アドレスを節約しつつ、ワークロードの関連性の高い重要な部分にルーティング可能で利用できる状態を維持する優れた方法です。このタイプの環境を作成する方法の詳細な手順は、こちらの投稿で見つけることができます。

Private NAT Gateway の使用には、料金ページに示されているように料金が発生することにご注意ください。

まとめ

この投稿では、重複する IP ネットワークに対処するいくつかの方法を紹介しました。以下の表は、それぞれのオプションの比較を示しています。

重複するネットワークをリナンバリングすることが、長期的には (コストや複雑さ、可視性の面で) 最も良い選択肢であることを覚えておいてください。PrivateLinkは、接続先のネットワークを制御できないサービスやアプリケーションプロバイダーに対処することに特化して設計されています。

本稿は、2022年6月16日に Networking & Content Delivery で公開された “Connecting Networks with Overlapping IP Ranges” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。