編集

Azure での IPv4 枯渇の防止

Azure Firewall
Azure Virtual Network
Azure Private Link

この記事では、Azure で大規模なネットワークを構築するときに、プライベート アドレス空間の消費量を最小限に抑える方法を説明します。 適切な割り当てポリシーが確立されておらず、Azure 仮想ネットワークに割り当てるためにプライベート IP アドレスが不足している場合は、アドレス空間の消費を最小限に抑える必要がある場合があります。 この記事では、Azure で適切な IP アドレス管理を行う 2 つの方法について説明します。

シナリオの詳細

企業ネットワークでは、通常、RFC 1918 で定義されているプライベート IPv4 アドレス範囲にあるアドレス空間を使用します。 アドレス範囲は 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 です。 オンプレミス環境では、これらの範囲は、最大のネットワークの要件を満たすのに十分な IP アドレスを提供します。 その結果、多くの組織は、IP 割り当ての単純なルーティング構成とアジャイル プロセスに優先順位を付けるアドレス管理プラクティスを開発しています。 アドレス空間を効率的に使用することは、優先順位ではありません。

クラウドでは、大規模なハイブリッド ネットワークを簡単に構築でき、マイクロサービスやコンテナー化などの一般的なアーキテクチャ パターンによっては、IP アドレスの消費量が増加する可能性があります。 そのため、これらのアドレス管理プラクティスを調整することが重要です。 クラウド環境では、プライベート IPv4 アドレスを制限付きリソースとして扱います。

Azure Virtual Network IP アドレス範囲

Azure 仮想ネットワークでは、RFC 1918 で定義されているアドレス ブロックを使用することをおすすめします。 これらのアドレス ブロックは汎用プライベート ネットワーク用であり、パブリック インターネットではルーティングできません。

他の範囲を使用できますが、仮想ネットワークでこれらの範囲を使用する前に、インターネット割り当て番号機関 (IANA) のドキュメントを参照して、環境への潜在的な影響を理解してください。 次のフィールドを使用できます:

  • Azure Virtual Network のプライベート アドレス空間として扱われるキャリア グレードのネットワーク アドレス変換 (NAT) 用に RFC 6598 によって定義された共有アドレス空間。 アドレス ブロックは 100.64.0.0/10 です。
  • 組織が所有していない、インターネットでルーティング可能なパブリック IP アドレス。 仮想ネットワーク内のリソースは、パブリック IP アドレス経由で公開されているインターネット エンドポイントにアクセスできないため、この方法はおすすめしません。
  • IANA によって定義される特殊なアドレス ブロック (192.0.0.0/24、192.0.2.0/24、192.88.99.0/24、198.18.0.0/15、198.51.100.0/24、203.0.113.0/24、233.252.0.0/24)。

注意

クラス E の IP アドレスの範囲 240.0.0.0/4 は、Windows により NIC への割り当てがブロックされており、Linux の場合は互換性の問題があります。 そのため、プログラムで Virtual Network に範囲を割り当てることは可能ですが、Azure Virtual Network での使用はおすすめしません。

Note

上記の範囲では、IPv4 枯渇の問題がある組織に長期的なソリューションは提供されません。 その場合は、プライベート アドレス空間の消費量を最小限に抑える必要があります。

Azure 仮想ネットワークでは、次の IP アドレス範囲を使用することはできません:

  • 224.0.0.0/4 (マルチキャスト)
  • 255.255.255.255/32 (ブロードキャスト)
  • 127.0.0.0/8 (ループバック)
  • 169.254.0.0/16 (リンク ローカル)
  • 168.63.129.16/32 (内部 DNS)

Azure ランディング ゾーンのアラインメント

この記事のレコメンデーションは、Azure ランディング ゾーン アーキテクチャに基づくシナリオを対象としています。 このガイダンスでは、次のことを前提としています:

  • 各リージョンにはハブアンドスポーク トポロジがある。
  • 異なるリージョンにあるハブ アンド スポーク ネットワークがグローバル仮想ネットワーク ピアリングまたは同じ Azure ExpressRoute 回線または回線への接続を介して相互に接続されている。
  • ハブアンドスポーク ネットワークが ExpressRoute 回線とサイト間 VPN の組み合わせを介してオンプレミス サイトに接続されている。

次の図にアーキテクチャ例を示します。 推奨事項レコメンデーションは、各リージョンにハブアンドスポーク ネットワークがある Azure Virtual WAN 上に構築されたネットワークにも同様に適用されます。

リージョン ハブアンドスポーク トポロジを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

Azure ランディング ゾーン アーキテクチャに基づくシナリオでは、アプリケーションは独自のランディング ゾーンにデプロイされます。 各ランディング ゾーンには、リージョン ハブにピアリングされたスポーク仮想ネットワークが含まれています。 スポーク仮想ネットワークは企業ネットワークの不可欠な部分であり、ルーティング可能な IPv4 アドレスが割り当てられます。 これらのアドレスは、企業ネットワーク全体で一意です。 そのため、Azure Virtual Network にデプロイされているすべてのアーキテクチャ コンポーネントは、企業ネットワーク全体から到達できる必要があるエンドポイントを公開するコンポーネントが少数であっても、企業ネットワークのアドレス空間内の IPv4 アドレスを使用します。 これらのアーキテクチャ コンポーネントは、仮想マシン、ファースト パーティまたはサード パーティのネットワーク仮想アプライアンス (NVA)、または仮想ネットワークによって挿入されたサービスとしてのプラットフォーム (PaaS) サービスです。

この記事の残りの部分では、フロントエンド コンポーネントとは、企業ネットワーク全体から、またはコンポーネントのランディング ゾーンの外部から到達可能なアプリケーション コンポーネントを指します。 バックエンド コンポーネントとは、企業ネットワーク内のエンドポイントを公開せず、独自のランディング ゾーン内からのみ到達できる必要があるアプリケーション コンポーネントを意味します。 たとえば、エンドポイントを公開する Web アプリケーションはフロントエンド コンポーネントであり、エンドポイントを公開しないデータベースはバックエンド コンポーネントです。

次のセクションでは、Azure で大規模なネットワークを構築するときにプライベート アドレス空間の消費量を最小限に抑える 2 つの方法について説明します。

方法 1: ルーティング不可能なランディング ゾーンスポーク仮想ネットワーク

RFC 1918 は、IP アドレス ブロックを IPv4 32 ビット アドレス空間から切り取り、パブリック インターネット上でルーティングできないようにするため、内部通信のために複数のプライベート ネットワークで再利用できます。 この方法は、プライベート アドレス空間に適用されるのと同じ原則に基づいています。 1 つ以上のアドレス範囲は、組織によって使用されるプライベート アドレス空間全体から切り取られ、組織の企業ネットワーク内でルーティング不可能と宣言されます。 アドレス範囲は、複数のランディング ゾーンで再利用されます。 その結果、各ランディング ゾーンは次のようになります:

  • 1 つ以上のアドレス範囲で構成されるルーティング可能なアドレス空間が割り当てられます。 組織はアドレス範囲を一元的に管理し、企業ネットワークと通信するためにランディング ゾーンに一意に割り当てます。 ルーティング可能な空間内のアドレスは、フロントエンド コンポーネントに割り当てられます。
  • 組織が企業ネットワークで非ルーティングとして宣言するアドレス範囲である、ルーティング不可能なアドレス空間を使用できます。 これらの予約範囲は、すべてのランディング ゾーンの内部通信に使用できます。 ルーティング不可能な空間内のアドレスは、バックエンド コンポーネントに割り当てられます。

カスタマー マネージドまたは Virtual WAN に基づく Azure ハブアンドスポーク ネットワークでは、2 つ以上のスポーク仮想ネットワークに重複する IP アドレス空間を設定することはできません。 ルーティング不可能なアドレス ブロックをランディング ゾーン スポークに割り当てることはできません。 仮想ネットワーク ピアリングは非推移的であるため、ランディング ゾーンスポーク仮想ネットワークは、ルーティング不可能なアドレス空間を持つ 第 2 レベル のスポーク仮想ネットワークとピアリングできます。 次の図は、ランディング ゾーンのデュアル仮想ネットワーク トポロジを示しています。

ランディング ゾーンのデュアル仮想ネットワーク トポロジを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

各アプリケーション ランディング ゾーンには、ピアリングされた 2 つの仮想ネットワークが含まれています。 1 つの仮想ネットワークにルーティング可能な IP アドレスがあり、フロントエンド コンポーネントをホストします。 もう 1 つの仮想ネットワークには、ルーティング不可能な IP アドレスがあり、バックエンド コンポーネントがホストされます。 ルーティング可能なランディング ゾーン スポークは、リージョン ハブとピアリングされます。 ルーティング可能なランディング ゾーン スポークは、ルーティング不可能なランディング ゾーン スポークとピアリングされます。 仮想ネットワーク ピアリングは、非推移的であるため、ルーティング不可能なプレフィックスは、リージョン ハブや企業ネットワークの残りの部分には表示されません。 ルーティング可能な仮想ネットワークでは、ルーティング不可能なアドレス範囲を使用できません。 一部の組織では、ルーティング可能なネットワークに既に割り当てられている断片化されたアドレス空間があります。 未使用の大きなアドレス ブロックを特定し、それらを非ルーティングとして宣言するのは困難な場合があります。 その場合は、RFC 1918 アドレス空間に含まれていない未使用のアドレスを検討してください。 前の図は、RFC 6598 のようなキャリア グレードの NAT アドレスの例を示しています。これは、ルーティング不可能なスポーク仮想ネットワークです。

単一仮想ネットワーク ランディング ゾーンの移行

仮想ネットワーク ピアリングは、2 つのピアリングされたネットワーク間の完全なレイヤー 3 接続を提供します。 IP 経由で相互に通信する従来の単一仮想ネットワーク ランディング ゾーンにデプロイされたアプリケーション コンポーネントは、ランディング ゾーン内のルーティング可能なスポーク仮想ネットワークとルーティング不可能なスポーク仮想ネットワークの間で自由に移動できます。 このセクションでは、2 つの一般的な移行パターンについて説明します。

次のアプリケーションは、レイヤー 7 アプリケーション配信コントローラーを介して公開されます:

レイヤー 7 アプリケーション デリバリー コントローラーを介して公開されるアプリケーションの移行パターンを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

レイヤー 7 アプリケーション デリバリー コントローラーを介して公開されるアプリケーションは、ルーティング不可能なスポークに移動できます。 アプリケーション デリバリー コントローラーは、ルーティング可能なランディング ゾーン スポークに存在する必要がある唯一のフロントエンド コンポーネントです。

次のアプリケーションは、Azure Load Balancer を介して公開されます:

Azure Load Balancer を介して公開されるアプリケーションの移行パターンを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

アプリケーションが Azure Load Balancer を介してそのエンドポイントを公開する場合、ロード バランサーのバックエンド プールの一部であるコンピューティング インスタンスは、同じ仮想ネットワーク内に残る必要があります。 Azure Load Balacner では、独自の仮想ネットワーク内のバックエンド インスタンスのみがサポートされます。

アウトバウンドの依存関係

アプリケーションのバックエンド コンポーネントは、企業ネットワークから到達可能であるか、受信接続を受信する必要はありませんが、多くの場合、送信依存関係があります。 バックエンド コンポーネントは、DNS 解決、Active Directory Domain Services ドメイン コントローラー、他のランディング ゾーンによって公開されているアプリケーション エンドポイントへのアクセス、ログ記録やバックアップ機能へのアクセスなどのインスタンスで、ランディング ゾーンの外部にあるエンドポイントに接続する必要がある場合があります。

Note

NAT 経由でのクライアントから Active Directory ドメイン サービス (ADDS) ドメイン コントローラー (DC) への通信がテストされ、サポートされます。「NAT 経由での Active Directory のサポート境界の説明」で詳しく説明されているように、DC 間通信はテストされておらず、サポートされていません。

サービスがルーティング不可能なスポーク仮想ネットワークで接続を開始する場合は、ルーティング可能な IP アドレスの背後にある接続にソース NAT (SNAT) を実装する必要があります。 SNAT を実装するには、ルーティング可能なスポーク仮想ネットワークに NAT 対応デバイスをデプロイします。 各ランディング ゾーンでは、専用の NAT NVA が実行されます。 ランディング ゾーンに SNAT を実装するには、Azure Firewall またはサードパーティの NVA の 2 つのオプションがあります。 どちらの場合も、非ルーティング スポーク内のすべてのサブネットをカスタム ルート テーブルに関連付ける必要があります。 次の図に示すように、ルート テーブルはトラフィックをランディング ゾーン外の宛先に SNAT デバイスに転送します。 Azure NAT Gateway では、RFC 1918 空間などのプライベート IP アドレス空間宛てのトラフィックの SNAT はサポートされていません。

カスタム ルート テーブルがトラフィックを SNAT デバイスに転送する方法を示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

Azure Firewall　を使用して SNAT を実装する

Azure Firewall:

  • 高可用性を提供します。
  • ネイティブのスケーラビリティと 3 つの異なる SKU を提供します。 SNAT はリソースを集中的に消費するタスクではないため、ますは基本的な SKU を検討してください。 ルーティング不可能なアドレス空間からの大量の送信トラフィックを必要とするランディング ゾーンの場合は、標準 SKU を使用します。
  • 任意のインスタンスのプライベート IP アドレスの背後にあるトラフィックに対して SNAT を実行します。 各インスタンスは、特権のないすべてのポートを使用できます。

次の図は、Azure Firewall を使用してハブ アンド スポーク ネットワーク トポロジに SNAT を実装するランディング ゾーン のレイアウトを示しています。

Azure Firewall を使用した SNAT 実装を示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

Azure Firewall へのランディング ゾーン外の宛先にトラフィックを送信するには、ルーティング不可能なスポーク内のすべてのサブネットをカスタム ルート テーブルに関連付ける必要があります。

次の図は、Azure Firewall を使用して Virtual WAN ベースのハブアンドスポーク ネットワーク トポロジに SNAT を実装するランディング ゾーン のレイアウトを示しています。

Azure Firewall を使用した Virtual WAN ベースのネットワークでの SNAT 実装を示す図。このアーキテクチャの PowerPoint ファイルをダウンロードします。

Azure Firewall へのランディング ゾーン外の宛先にトラフィックを送信するには、ルーティング不可能なスポーク内、または Virtual WAN に接続されていないスポークのすべてのサブネットをカスタム ルート テーブルに関連付ける必要があります。

どちらのレイアウトでも、ルーティング可能な IP アドレスへのルーティング不可能なスポーク アクセス内のリソースをランディング ゾーンの外部に提供するには、各ランディング ゾーンのルーティング可能なスポークで [SNAT の実行] オプションを Always に設定して、Azure Firewall をデプロイする必要があります。 受信したすべての接続に SNAT を実装するように Azure Firewall を構成する方法については、パブリック ドキュメントをの手順を参照してください。 次のスクリーンショットは、ルーティング不可能なスポーク仮想ネットワーク内のリソースによって開始される接続の NAT デバイスとして Azure Firewall を使用するために必要な構成を示しています。

Azure Firewall の既定の SNAT 動作のダイアログを示すスクリーンショット。[SNAT の実施] オプションに

サードパーティの NVA を使用して SNAT を実装する

NAT 機能を備えたサードパーティの NVA は、Azure Marketplace で使用できます。 次のようなサポート方法があります。

  • スケールインとスケールアウトをきめ細かく制御します。
  • NAT プールのきめ細かい制御。
  • カスタム NAT ポリシー(送信元または宛先の IP アドレスなど、受信接続のプロパティに応じて異なる NAT アドレスを使用するなど)。

次の推奨事項を検討してください。

  • 高可用性を実現するには、少なくとも 2 つの NVA を使用してクラスターをデプロイします。 Azure Load Balancer を使用して、ルーティング不可能なスポーク仮想ネットワークから NVA に受信接続を分散します。 クラスターがランディング ゾーンを離れるすべての接続に SNAT を実装するため、高可用性ポート負荷分散規則が必要です。 Azure Standard Load Balancer では、高可用性ポートの負荷分散規則がサポートされています。
  • Azure SDN スタックでは、シングルアームとデュアルアームの NVA がサポートされています。 シングルアーム NVA は、ルーティング可能なスポーク仮想ネットワークのアドレス空間の消費量を削減するため、推奨されます。

次の図は、サードパーティ NVA を使用してハブ アンド スポーク ネットワーク トポロジに SNAT を実装するランディング ゾーン のレイアウトを示しています。

サードパーティ NVA を使用したハブアンドスポーク ネットワーク トポロジでの SNAT の実装を示す図このアーキテクチャの PowerPoint ファイルをダウンロードします。

次の図は、サードパーティ NVA を使用して Virtual WAN ベースのハブアンドスポーク ネットワーク トポロジに SNAT を実装するランディング ゾーンのレイアウトを示しています。

サードパーティ NVA を使用した Virtual WAN ベースのハブアンドスポーク ネットワーク トポロジでの SNAT の実装を示す図このアーキテクチャの PowerPoint ファイルをダウンロードします。

両方のサードパーティ NVA レイアウトでは、高可用性を提供するために、Azure Load Balancer の背後に複数のインスタンスをデプロイする必要があります。 Azure Load Balancer Standard SKU が必要です。

Private Link は、仮想ネットワークに接続されていない仮想ネットワークにデプロイされているアプリケーションへのアクセスを提供します。 サーバー側またはアプリケーション、仮想ネットワークでは、Private Link サービスがデプロイされ、内部 Azure Standard SKU ロード バランサーのフロントエンド IP アドレスで公開されるアプリケーション エンドポイントに関連付けられます。 クライアント側の仮想ネットワークでは、プライベート エンドポイント リソースがデプロイされ、Private Link サービスに関連付けられます。 プライベート エンドポイントは、仮想ネットワーク内のアプリケーション エンドポイントを公開します。 Private Link は、クライアント側とサーバー側の間でトラフィックをルーティングするためのトンネリングと NAT ロジックを提供します。 詳細については、「Azure Private Link とは」を参照してください。

Private Link では、クライアント側仮想ネットワークとサーバー側仮想ネットワークの間にレイヤー 3 接続は必要ありません。 2 つの仮想ネットワークには、IP アドレス空間が重複している可能性があります。 Private Link を使用すると、専用の分離された仮想ネットワークにアプリケーションをデプロイでき、そのすべてが同じルーティング不可能なアドレス空間を使用できます。 アプリケーションは、ルーティング可能なアドレス空間を使用する企業ネットワーク内の Private Link サービスとして公開されます。 Azure ランディング ゾーン アーキテクチャのコンテキストでは、結果として得られるランディング ゾーン トポロジには次が含まれます:

  • アプリケーション全体と、アプリケーションのエンドポイントに関連付けられている Private Link サービスをホストする分離された仮想ネットワーク。 アプリケーション チームは、仮想ネットワークのアドレス空間を定義します。
  • Private Link サービスに関連付けられているプライベート エンドポイントをホストするルーティング可能なアドレス空間を持つスポーク仮想ネットワーク。 スポーク仮想ネットワークは、リージョン ハブと直接ピアリングされます。

次の図は、Private Link 対応ランディング ゾーン トポロジを示しています。

分離された仮想ネットワークに展開されたアプリケーションを Private Link サービスが公開する場合のランディング ゾーンのトポロジを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードする。

分離されたスポーク仮想ネットワークにアプリケーションをデプロイする場合は、送信依存関係に Private Link サービスを使用します。 分離スポーク仮想ネットワークでプライベート エンドポイントを定義し、ルーティング可能な仮想ネットワーク内の Private Link サービスに関連付けます。 次の図はその概念的アプローチを示します。

分離された仮想ネットワークに展開されたアプリケーションの送信依存性に使われる Private Link を示す図。このアーキテクチャの PowerPoint ファイルをダウンロードする。

実際の大規模な実装では、Private Link メソッドは適用されない場合があります:

  • 分離された仮想ネットワークにデプロイされたアプリケーションに複数の送信依存関係がある場合。 送信依存関係ごとに Private Link サービスとプライベート エンドポイントをデプロイすると、複雑さと管理のニーズが高くなります。
  • 送信依存に、Azure Load Balancer バックエンド プールの一部にできないルーティング可能なネットワーク内のエンドポイントが含まれている場合、Private Link は適用されません。

これら 2 つの制限を克服するには、ルーティング可能なスポークにプロキシ/NAT ソリューションをデプロイし、Private Link を使用して分離された仮想ネットワークからアクセスできるようにします。

送信依存性に Private Link サービスを使用するアーキテクチャを示す図。このアーキテクチャの PowerPoint ファイルをダウンロードする。

単一のプライベート エンドポイントまたは Private Link サービスを使用して、ルーティング可能なネットワークにデプロイされたプロキシ/NAT ソリューションを公開します。 ポート変換規則とアドレス変換規則は、NVA で定義されます。 これらの規則を使用すると、分離された仮想ネットワーク内の 1 つのプライベート エンドポイントを使用して、ルーティング可能なネットワーク内の複数の依存関係にアクセスできます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Federico Guerrini | ヨーロッパ、中近東およびアフリカ テクニカル リーダー
  • Khush Kaviaj | クラウド ソリューション アーキテクト
  • Jack Tracey | シニア クラウド ソリューション アーキテクト

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ