Azure Stack Hub ラグドのネットワークの概要

ネットワーク設計の概要

物理ネットワークの設計

Azure Stack Hub ラグド ソリューションには、その操作やサービスをサポートするための回復性と可用性の高い物理インフラストラクチャが必要です。 ToR から境界スイッチへのアップリンクは、SFP+ または SFP28 メディア、1 GB、10 GB、または 25 GB の速度に制限されます。 OEM (Original Equipment Manufacturer) ハードウェア ベンダーに可用性を確認してください。

次の図は、Azure Stack Hub ラグドの推奨される設計を示しています。

Azure Stack Hub ラグドの物理ネットワーク

論理ネットワークの設計

論理ネットワークの設計は、物理ネットワーク インフラストラクチャの抽象化を表します。 これらは、ホスト、仮想マシン (VM)、およびサービスへのネットワーク割り当てを整理および簡略化するために使用されます。 論理ネットワークの作成の一環として、次のものを定義するためにネットワーク サイトが作成されます。

  • 仮想ローカル エリア ネットワーク (VLAN)
  • IP サブネット
  • IP サブネットと VLAN のペア

これらはすべて、物理的な各場所にある論理ネットワークに関連付けられています。

次の表に、論理ネットワークと、計画する必要がある関連付けられた IPv4 サブネット範囲を示します。

論理ネットワーク 説明 [サイズ]
パブリック仮想 IP (VIP) Azure Stack Hub ラグドでは、このネットワークからの合計 31 個のアドレスが使用されます。 少数の Azure Stack Hub ラグド サービスに 8 個のパブリック IP アドレスが使用されます。残りはテナント VM によって使用されます。 App Service と SQL リソース プロバイダーを使用する場合は、さらに 7 個のアドレスを使用します。 残りの 15 個の IP アドレスは、将来の Azure サービスのために予約されています。 /26 (62 ホスト)-
/22 (1022 ホスト)

推奨 = /24 (254 ホスト)
スイッチのインフラストラクチャ ルーティングを目的としたポイント ツー ポイント IP アドレス (スイッチ管理専用インターフェイス) と、スイッチに割り当てられたループバック アドレス。 /26
インフラストラクチャ Azure Stack Hub ラグドの内部コンポーネントの通信に使用します。 /24
プライベート ストレージ ネットワーク、プライベート VIP、インフラストラクチャ コンテナー、その他の内部機能のために使用されます。 /20
ベースボード管理コントローラー (BMC) 物理ホスト上のベースボード管理コントローラーとの通信に使用されます。 /26

ネットワーク インフラストラクチャ

Azure Stack Hub ラグドのネットワーク インフラストラクチャは、スイッチ上に構成されたいくつかの論理ネットワークから成ります。 次の図は、これらの論理ネットワークと、それらが TOR (top-of-rack)、ベースボード管理コントローラー、境界 (カスタマー ネットワーク) スイッチと統合される方法を示したものです。

Azure Stack Hub ラグドの論理ネットワークの図:

Azure Stack Hub ラグドの論理ネットワーク

BMC ネットワーク

このネットワークは、すべてのベースボード管理コントローラー (BMC またはサービス プロセッサとも呼ばれます) の管理ネットワークへの接続専用です。 例として、iDRAC、iLO、iBMC などがあります。 どの BMC ノードとの通信にも、1 つの BMC アカウントだけが使用されます。 存在する場合は、ハードウェア ライフサイクル ホスト (HLH) がこのネットワーク上に配置され、ハードウェアのメンテナンスまたは監視のための OEM 固有のソフトウェアが提供される可能性があります。

HLH では、デプロイメント仮想マシン (DVM) もホストされます。 DVM は Azure Stack Hub ラグドの配置時に使用され、配置が完了すると削除されます。 接続されたデプロイのシナリオの場合、DVM には、複数のコンポーネントのテスト、検証、アクセスのために、インターネット アクセスが必要です。 これらのコンポーネントは、企業ネットワークの内外に配置できます (たとえば NTP、DNS、Azure)。 接続の要件の詳細については、Azure Stack Hub ラグドのファイアウォールの統合に関する記事の NAT に関するセクションを参照してください。

プライベート ネットワーク

/20 (4096 個のホスト IP) ネットワークは、Azure Stack Hub ラグドのリージョン専用です。 Azure Stack Hub ラグド リージョンの境界スイッチ デバイスを超えて拡張されることはありません。 このネットワークは、複数のサブネットに分割されます。次に例を示します。

  • ストレージ ネットワーク:スペース ダイレクトおよびサーバー メッセージ ブロック (SMB) ストレージ トラフィックの使用や VM のライブ マイグレーションをサポートするために使用される /25 (128 IP) ネットワーク。
  • 内部仮想 IP ネットワーク:ソフトウェア ロード バランサーのための内部のみの VIP 専用の /25 ネットワーク。
  • コンテナー ネットワーク:インフラストラクチャ サービスを実行しているコンテナー間の内部トラフィックのみを対象とする専用 /23 (512 IP) ネットワーク

プライベート ネットワークのサイズは、プライベート IP 空間の /20 (4096 個の IP) です。 このネットワークは、Azure Stack Hub ラグド システム専用です。 Azure Stack Hub ラグド システムの境界スイッチ デバイスを超えてルーティングされることはありません。また、複数の Azure Stack Hub ラグド システムで再利用することができます。 ネットワークは Azure Stack Hub ラグド専用ですが、データセンター内の他のネットワークと重複することはできません。 プライベート IP 空間のガイダンスについては、RFC 1918 に従うことをお勧めします。

/20 プライベート IP 空間は複数のネットワークに分割されており、それにより将来のリリースにおいて Azure Stack Hub ラグド システム インフラストラクチャをコンテナー上で実行できるようになります。 詳細については、1910 のリリース ノートを参照してください。 この新しいプライベート IP 空間によって、デプロイ前に必要となるルーティング可能な IP 空間を減少させるための継続的な作業が可能になります。

Azure Stack Hub ラグド インフラストラクチャ ネットワーク

この /24 ネットワークは、内部の Azure Stack Hub ラグド コンポーネント専用です。相互のデータの通信と交換に使用されます。 このサブネットは、Azure Stack Hub ラグド ソリューションからデータセンターへの外部にルーティングできます。 パブリックまたはインターネットにルーティング可能な IP アドレスをこのサブネットで 使用しない ことをお勧めします。 このネットワークは境界にアドバタイズされますが、そのほとんどの IP はアクセス制御リスト (ACL) によって保護されています。 アクセスできる IP は、サイズが /27 ネットワークに相当する小さい範囲内です。 これらの IP を使用して、特権エンドポイント (PEP) や Azure Stack Hub ラグド バックアップなどのサービスをホストします。

パブリック VIP ネットワーク

パブリック VIP ネットワークは、Azure Stack Hub ラグド内のネットワーク コントローラーに割り当てられます。 これはスイッチ上の論理ネットワークではありません。 SLB はアドレスのプールを使用して、テナント ワークロードに /32 ネットワークを割り当てます。 スイッチのルーティング テーブルにおいて、これらの /32 IP は Border Gateway Protocol (BGP) 経由で使用可能なルートとしてアドバタイズされます。 このネットワークには、外部からアクセスできるパブリック アドレスが含まれています。 Azure Stack Hub ラグド インフラストラクチャは、このパブリック VIP ネットワークの最初の 31 個のアドレスを予約し、残りはテナント VM によって使用されます。 このサブネット上のネットワーク サイズは、最小 /26 (64 のホスト) から最大 /22 (1022 のホスト) までの範囲があります。 /24 ネットワークを計画することをお勧めします。

スイッチ インフラストラクチャ ネットワーク

/26 ネットワークは、ルーティング可能な Point-to-Point IP /30 (2 つのホスト IP) サブネットと Loopback が含まれるサブネットです。 これらは、インバンド スイッチ管理と BGP ルーター ID に専用の /32 サブネットです。 この範囲の IP アドレスを、Azure Stack Hub ラグド ソリューションの外部のデータセンターにルーティング可能にする必要があります。 IP アドレスは、プライベートまたはパブリックのどちらでもかまいません。

スイッチ管理ネットワーク

/29 (6 個のホスト IP) ネットワークは、スイッチの管理ポートの接続専用です。 このネットワークにより、デプロイ、管理、トラブルシューティングのためのアウトオブバンド アクセスが可能になります。 これは、上で説明したスイッチ インフラストラクチャ ネットワークから計算されます。

DNS の設計の概要

Azure Stack Hub ラグドの外部から Azure Stack Hub ラグド エンドポイント ( portaladminportalmanagementadminmanagement) にアクセスするには、Azure Stack Hub ラグドの DNS サービスを、Azure Stack Hub ラグドで使用する DNS ゾーンをホストする DNS サーバーと統合する必要があります。

Azure Stack Hub ラグドの DNS 名前空間

Azure Stack Hub ラグドを配置するときに、DNS に関するいくつかの重要な情報を指定する必要があります。

フィールド 説明
リージョン Azure Stack Hub ラグドの配置の地理的な場所。
外部ドメイン名 Azure Stack Hub ラグドの配置に使用したいゾーンの名前。 cloud.fabrikam.com
内部ドメイン名 Azure Stack Hub ラグドでのインフラストラクチャ サービスに使用される内部ゾーンの名前。 ディレクトリ サービスと統合されており、プライベートになっています (Azure Stack Hub ラグドの配置の外部からは到達できません)。 azurestack.local
DNS フォワーダー Azure Stack Hub ラグドの外部 (企業イントラネットまたはパブリック インターネット上のどちらか) でホストされている DNS クエリ、DNS ゾーンおよびレコードを転送するために使用される DNS サーバー。 デプロイ後に Set-AzSDnsForwarder コマンドレット を使用して、DNS フォワーダーの値を編集できます。
名前付けのプレフィックス (省略可能) Azure Stack Hub ラグド インフラストラクチャ ロール インスタンス マシン名に使用する、名前付けのプレフィックス。 指定されていない場合、既定値は "azs" です。 azs

Azure Stack Hub ラグドの配置の完全修飾ドメイン名 (FQDN) とエンドポイントは、リージョン パラメーターと外部ドメイン名パラメーターの組み合わせです。 前の表に示した例の値を使用すると、この Azure Stack Hub ラグドの配置の FQDN は east.cloud.fabrikam.com のようになります

同様に、このデプロイのエンドポイントは次の URL のようになります。

  • https://portal.east.cloud.fabrikam.com
  • https://adminportal.east.cloud.fabrikam.com

この例の DNS 名前空間を Azure Stack Hub ラグドの配置に使用するには、次の条件が必要です。

  • ゾーン fabrikam.com が、ドメイン レジストラー、社内 DNS サーバー、またはその両方に登録されています。 登録は、名前解決の要件によって異なります。
  • 子ドメイン cloud.fabrikam.com が、ゾーン fabrikam.com の下に存在します。
  • ゾーン fabrikam.com と cloud.fabrikam.com をホストする DNS サーバーに、Azure Stack Hub ラグドの配置から到達できます。

Azure Stack Hub ラグド エンドポイントとインスタンスの DNS 名を、Azure Stack Hub ラグドの外部から解決するには、DNS サーバーを統合する必要があります。 Azure Stack Hub ラグド用の外部 DNS ゾーンがホストされているサーバーと、使用する親ゾーンがホストされている DNS サーバーを含みます。

DNS 名ラベル

Azure Stack Hub ラグドでは、パブリック IP アドレスへの DNS 名ラベルの追加がサポートされており、パブリック IP アドレスの名前解決が可能です。 DNS ラベルは、Azure Stack Hub ラグドでホストされているアプリとサービスにユーザーが名前でアクセスできる便利な方法です。 DNS 名ラベルでは、インフラストラクチャ エンドポイントとはわずかに異なる名前空間が使用されます。 前の名前空間の例に従うと、DNS 名ラベルの名前空間は *.east.cloudapp.cloud.fabrikam.com になります。

テナントがパブリック IP アドレス リソースの DNS 名フィールドで Myapp を指定した場合、Azure Stack Hub ラグドの外部 DNS サーバー上にあるゾーン east.cloudapp.cloud.fabrikam.com 内の myapp に対する A レコードが作成されます。 結果として得られる完全修飾ドメイン名は、myapp.east.cloudapp.cloud.fabrikam.com になります。

この機能を利用し、この名前空間を使用する場合は、DNS サーバーを統合する必要があります。 Azure Stack Hub ラグド用の外部 DNS ゾーンがホストされているサーバーと、使用する親ゾーンがホストされている DNS サーバーを含みます。 この名前空間は、Azure Stack Hub ラグド サービス エンドポイントに使用されるものとは異なるため、追加の委任または条件付き転送ルールを作成する必要があります。

DNS 名ラベルのしくみの詳細については、Azure Stack Hub ラグドでの DNS の使用に関する記事を参照してください。

解決と委任

DNS サーバーには次の 2 種類があります。

  • 権限のある DNS サーバーは、DNS ゾーンをホストします。 このサーバーは、これらのゾーン内のレコードに対する DNS クエリのみに応答します。
  • 再帰 DNS サーバーでは、DNS ゾーンはホストされません。 このサーバーは、権限のある DNS サーバーを呼び出して必要なデータを収集することで、すべての DNS クエリに応答します。

Azure Stack Hub ラグドには、権限のある DNS サーバーと再帰 DNS サーバーの両方が含まれます。 再帰サーバーは、その Azure Stack Hub ラグドの配置の内部プライベート ゾーンと外部パブリック DNS ゾーンを除くすべての名前の解決に使用されます。

Azure Stack Hub ラグドからの外部 DNS 名の解決

Azure Stack Hub ラグドの外部にあるエンドポイント (例: www.bing.com) の DNS 名を解決するには、Azure Stack Hub ラグドが権限を持たない DNS 要求を転送するために、Azure Stack Hub ラグド用の DNS サーバーを用意する必要があります。 Azure Stack Hub ラグドの要求の転送先となる DNS サーバーをデプロイ ワークシート ([DNS フォワーダー] フィールド) に入力する必要があります。 フォールト トレランスのために、このフィールドには 2 つ以上のサーバーを入力します。 これらの値がない場合、Azure Stack Hub ラグドの配置は失敗します。 デプロイ後に Set-AzSDnsForwarder コマンドレット を使用して、DNS フォワーダーの値を編集できます。

ファイアウォールの設計の概要

Azure Stack Hub ラグドは、ファイアウォール デバイスを使ってセキュリティで保護することをお勧めします。 ファイアウォールは、分散型サービス拒否 (DDOS) 攻撃に対する防御、侵入検出、コンテンツ検査などに役立ちます。 ただし、これが BLOB、テーブル、キューなどの Azure ストレージ サービスのスループットのボトルネックになる場合もあります。

切断されたデプロイ モードを使用する場合は、AD FS のエンドポイントを発行する必要があります。 詳細については、データ センターの統合の ID に関する記事をご覧ください。

Azure Resource Manager (管理者)、管理者ポータル、Key Vault (管理者) のエンドポイントには、外部発行が必ずしも必要というわけではありません。 たとえば、サービス プロバイダーはインターネットからではなく、ネットワークの内部からのみ Azure Stack Hub ラグドを管理することによって、攻撃面を制限できます。

企業組織では、外部のネットワークは既存の企業ネットワークを指定できます。 このシナリオでは、企業ネットワークから Azure Stack Hub ラグドを操作するにはエンドポイントを公開する必要があります。

ネットワーク アドレス変換

デプロイの間にデプロイ仮想マシン (DVM) が外部リソースにアクセスできるようにするには、ネットワーク アドレス変換 (NAT) が推奨される方法です。 また、登録とトラブルシューティングの間の、緊急回復コンソール (ERCS) VM または特権エンドポイント (PEP) についても同様です。

また、外部ネットワークやパブリック VIP におけるパブリック IP アドレスに代わる働きとして NAT を利用することもできます。 ただし、テナントのユーザー エクスペリエンスが制限され、複雑さも増すため、これを行うことは推奨されません。 1 つオプションは、引き続きプール上のユーザー IP ごとに 1 つのパブリック IP が必要な 1 対 1 の NAT です。 もう 1 つのオプションは、ユーザーが使用する可能性のあるすべてのポートのユーザー VIP ごとに NAT 規則が必要な多対 1 の NAT です。

パブリック VIP に NAT を使うことには、いくつか不利な点もあります。

  • ファイアウォール規則を管理するときのオーバーヘッド。ユーザーが、ソフトウェア定義ネットワーク (SDN) スタック内の独自のエンドポイントと公開規則を管理するためです。 ユーザーは Azure Stack Hub ラグド オペレーターと連絡をとって、自分の VIP を公開させ、ポート リストを更新する必要があります。
  • NAT の使用によりユーザー エクスペリエンスは制限されますが、オペレーターは公開要求を完全に管理できます。
  • Azure でのハイブリッド クラウド シナリオの場合、NAT を使うエンドポイントへの VPN トンネルの設定が Azure ではサポートされていないことを考慮します。

SSL インターセプト

現在は、すべての Azure Stack Hub ラグド トラフィックで SSL インターセプト (暗号化解除のオフロードなど) を無効にすることをお勧めします。 将来の更新でサポートされた場合は、Azure Stack Hub ラグドに対して SSL インターセプトを有効にする方法のガイダンスが提供される予定です。

エッジ デプロイ ファイアウォールのシナリオ

エッジ配置の場合、エッジ ルーターまたはファイアウォールのすぐ後ろに Azure Stack Hub ラグドが配置されます。 このようなシナリオでは、ファイアウォールを境界の上に配置することがサポートされます (シナリオ 1)。この場合、アクティブ/アクティブとアクティブ/パッシブの両方のファイアウォール構成がサポートされます。 また、境界デバイスとして機能することもできます (シナリオ 2)。この場合は、アクティブ/アクティブ ファイアウォール構成のみがサポートされます。 シナリオ 2 は、フェールオーバーのために BGP または静的ルーティングでの等コスト マルチパス (ECMP) に依存します。

パブリックにルーティング可能な IP アドレスは、デプロイ時に、外部ネットワークからのパブリック VIP プールに対して指定されます。 セキュリティのため、エッジのシナリオでは、他のどのネットワークでもパブリックにルーティング可能な IP を使用することは推奨 されません。 このシナリオでは、Azure などのパブリック クラウドでのエクスペリエンスのような、完全に自己管理型のクラウドを体験できます。

Azure Stack Hub ラグドのエッジ ファイアウォール シナリオ

企業イントラネットまたは境界ネットワークのファイアウォール シナリオ

企業イントラネットまたは境界配置の場合、Azure Stack Hub ラグドの配置先は、マルチゾーン ファイアウォール、またはエッジ ファイアウォールと内部の企業ネットワーク ファイアウォールとの間になります。 そのトラフィックは、セキュア ゾーン、境界ネットワーク ゾーン (DMZ)、セキュリティ保護なしゾーンに分散されます。

  • セキュア ゾーン: 内部または企業のルーティング可能な IP アドレスを使用する内部ネットワーク。 セキュリティで保護されたネットワークは分割できます。 ファイアウォール NAT 経由でインターネットに送信アクセスできます。 通常、内部ネットワークを介してデータセンター内からアクセスできます。 Azure Stack Hub ラグドのネットワークは、外部ネットワークのパブリック VIP プールを除き、すべてセキュア ゾーンに存在します。
  • 境界ゾーン. 通常、境界ネットワークには、Web サーバーなど、外部アプリまたはインターネットに公開されるアプリがデプロイされます。 通常、DDoS や侵入 (ハッキング) などの攻撃を防ぐためにファイアウォールによって監視され、インターネットからは指定した受信トラフィックが引き続き許可されます。 Azure Stack Hub ラグドの中で、DMZ ゾーンに存在する必要があるのは、外部ネットワークのパブリック VIP プールだけです。
  • セキュリティ保護なしゾーン 外部ネットワーク、つまりインターネット。 セキュリティで保護されていないゾーンに Azure Stack Hub ラグドを配置することは推奨 されません

境界ネットワーク ファイアウォールのシナリオ

VPN の設計の概要

VPN はユーザーの概念ですが、ソリューションの所有者とオペレーターが知っておく必要のある重要な考慮事項がいくつかあります。

Azure 仮想ネットワークとオンプレミスのサイトとの間でネットワーク トラフィックを送信する前に、仮想ネットワーク用の仮想ネットワーク (VPN) ゲートウェイを作成する必要があります。

VPN ゲートウェイは、パブリック接続で暗号化されたトラフィックを送信する仮想ネットワーク ゲートウェイの一種です。 VPN ゲートウェイを使用して、Azure Stack Hub ラグド内の仮想ネットワークと Azure 内の仮想ネットワークとの間で安全にトラフィックを送信できます。 また、仮想ネットワークと、VPN デバイスに接続されている別のネットワーク間で安全にトラフィックを送信することもできます。

仮想ネットワーク ゲートウェイを作成する場合、作成するゲートウェイの種類を指定する必要があります。 Azure Stack Hub ラグドでは、仮想ネットワーク ゲートウェイの 1 つの種類である Vpn がサポートされています。

各仮想ネットワークに配置できる仮想ネットワーク ゲートウェイは 2 つですが、種類はいずれか 1 つのみになります。 選択する設定によっては、1 つの VPN ゲートウェイへの複数の接続を作成できます。 この種類の設定の一例は、マルチサイト接続構成です。

Azure Stack Hub ラグド用の VPN ゲートウェイを作成し、構成する前に、Azure Stack Hub ラグドのネットワークに関する考慮事項を確認してください。 Azure Stack Hub ラグドの構成が Azure とどのように異なるかについて説明します。

Azure では、選択する VPN ゲートウェイ SKU の帯域幅スループットが、ゲートウェイに接続されるすべての接続に分配される必要があります。 一方、Azure Stack Hub ラグドでは、VPN ゲートウェイ SKU の帯域幅値が、ゲートウェイに接続される各接続リソースに適用されます。 次に例を示します。

  • Azure では、Basic VPN ゲートウェイ SKU で、約 100 Mbps の総スループットに対応できます。 その VPN ゲートウェイへの接続を 2 つ作成し、1 つの接続で 50 Mbps の帯域幅を使用する場合、もう 1 つの接続では 50 Mbps を使用できます。
  • Azure Stack Hub ラグドでは、Basic VPN ゲートウェイ SKU への各接続に 100 Mbps のスループットが割り当てられます。

VPN の種類

VPN Gateway 構成に対して仮想ネットワーク ゲートウェイを作成する場合は、VPN の種類を指定する必要があります。 選択する VPN の種類は、作成する接続トポロジによって異なります。 VPN の種類は、使用しているハードウェアによっても異なる場合があります。 S2S 構成では、VPN デバイスが必要です。 一部の VPN デバイスでは、特定の VPN の種類のみがサポートされます。

重要

現時点の Azure Stack Hub ラグドでは、ルート ベースの VPN の種類のみがサポートされます。 お使いのデバイスがポリシー ベースの VPN のみに対応している場合、Azure Stack Hub ラグドからこれらのデバイスへの接続はサポートされません。 さらに、カスタムの IPSec/IKE ポリシー構成はサポートされていないため、現時点で Azure Stack Hub ラグドはルート ベース ゲートウェイに対するポリシー ベース トラフィック セレクターの使用をサポートしていません。

  • PolicyBased: ポリシー ベースの VPN により、パケットは暗号化され、IPsec のポリシーに基づいて、IPsec トンネル経由で送信されます。 ポリシーは、オンプレミス ネットワークと Azure Stack Hub ラグド VNet の間で、アドレス プレフィックスの組み合わせによって構成されます。 VPN デバイスの構成では、通常このポリシー (またはトラフィック セレクター) がアクセス リストになります。 PolicyBased は Azure ではサポートされていますが、Azure Stack Hub ラグドではサポートされていません。
  • RouteBased: ルート ベースの VPN によって、IP 転送テーブルまたはルーティング テーブルで構成されているルートが使用されます。 ルートにより、対応するトンネル インターフェイスにパケットが送信されます。 その後、トンネル インターフェイスではトンネルの内部または外部でパケットを暗号化または復号します。 RouteBased VPN のポリシー (またはトラフィック セレクター) は、Any-to-Any (またはワイルドカードを使用して) 構成できます。 既定では変更できません。 RouteBased VPN の種類の値は RouteBased です。

VPN ゲートウェイの構成

VPN Gateway 接続は、特定の設定で構成された複数のリソースに依存します。 ほとんどのリソースは個別に構成できますが、一定の順序で構成する必要がある場合があります。

設定

リソースごとに選択する設定は、適切な接続を作成するうえで非常に重要です。

この記事は、次のことを理解するのに役立ちます。

  • ゲートウェイの種類、VPN の種類、接続の種類。
  • ゲートウェイ サブネット、ローカル ネットワーク ゲートウェイ、および考慮する場合がある他のリソースの設定。

接続トポロジの図

VPN ゲートウェイ接続では、さまざまな構成を利用できます。 どの構成が自分のニーズに最適かを判断します。 以下のセクションでは、次の VPN ゲートウェイ接続に関する情報とトポロジの図を確認できます。

  • 利用可能なデプロイメント モデル
  • 利用可能な構成ツール
  • 記事に直接移動するリンク (利用可能な場合)

以降のセクションの図と説明は、要件を満たす接続トポロジを選択するために役立ちます。 図は主要なベースライン トポロジを示していますが、図をガイドとして使用して、より複雑な構成を構築することもできます。

サイト間とマルチサイト (IPsec/IKE VPN トンネル)

サイト間

"サイト間" (S2S) VPN ゲートウェイ接続とは、IPsec/IKE (IKEv2) VPN トンネルを介した接続です。 この種類の接続では、オンプレミスに配置され、パブリック IP アドレスが割り当てられている、VPN デバイスが必要です。 このデバイスを NAT の内側に配置することはできません。 S2S 接続は、クロスプレミスおよびハイブリッド構成に使用できます。

マルチサイト

"マルチサイト" 接続は、サイト間接続の一種です。 仮想ネットワーク ゲートウェイから複数の VPN 接続を作成し、通常は複数のオンプレミスのサイトに接続します。 複数の接続を使用する場合は、(クラシック VNet を使用する際に動的ゲートウェイと呼ばれる) ルートベースの VPN の種類を使用する必要があります。 各仮想ネットワークに配置できる VPN ゲートウェイは 1 つのみであるため、ゲートウェイを経由するすべての接続は、使用可能な帯域幅を共有します。

Gateway の SKU

Azure Stack Hub ラグドの仮想ネットワーク ゲートウェイを作成する場合、使用するゲートウェイ SKU を指定する必要があります。 以下の VPN ゲートウェイ SKU がサポートされています。

  • Basic
  • Standard
  • 高性能

選択するゲートウェイ SKU が高いほど、より多くの CPU とネットワーク帯域幅がゲートウェイに割り当てられます。 その結果、ゲートウェイは、仮想ネットワークに対してより高いネットワーク スループットをサポートできます。

Azure Stack Hub ラグドでは、Ultra Performance ゲートウェイ SKU はサポートされていません。この SKU は、Express Route 専用です。

SKU を選択する場合、次を考慮してください。

  • ポリシーベースのゲートウェイは、Azure Stack Hub ラグドではサポートされていません。
  • BGP は、Basic SKU ではサポートされていません。
  • ExpressRoute と VPN ゲートウェイが共存する構成は、Azure Stack Hub ラグドではサポートされていません。

ゲートウェイの可用性

高可用性シナリオは、ハイ パフォーマンス ゲートウェイ 接続 SKU 上でのみ構成できます。 アクティブ/アクティブ構成とアクティブ/パッシブ構成の両方で可用性を提供する Azure とは異なり、Azure Stack Hub ラグドでは、アクティブ/パッシブ構成のみがサポートされています。

[フェールオーバー]

Azure Stack Hub ラグドには 3 つのマルチテナント ゲートウェイ インフラストラクチャ VM があります。 これらの VM のうち 2 つはアクティブ モードで、3 つ目は冗長モードです。 アクティブな VM ではその上に VPN 接続を作成でき、冗長 VM ではフェールオーバーが発生した場合に VPN 接続のみを受け入れます。 アクティブなゲートウェイ VM が使用できなくなった場合、短い時間 (数秒) 接続が失われた後に、VPN 接続が冗長 VM にフェールオーバーします。

SKU の予測される合計スループット

次の表は、ゲートウェイの種類と、ゲートウェイ SKU 別の予測される合計スループットを示したものです。

VPN Gateway のスループット (1) VPN Gateway の IPsec トンネルの最大数 (2)
Basic SKU (3) 100 Mbps 20
Standard SKU 100 Mbps 20
高パフォーマンス SKU 200 Mbps 10

表の注記:

(1) - インターネット経由でのクロスプレミス接続の場合、VPN スループットは保証されたスループットではありません。 この値は、達成可能な最大スループットです。
(2) - トンネルの最大数は、すべてのサブスクリプションの Azure Stack Hub ラグドの配置ごとの合計です。
(3) - Basic SKU に対しては BGP ルーティングはサポートされません。

重要

2 つの Azure Stack Hub ラグドの配置間に作成できるのは、1 つのサイト間 VPN 接続だけです。 これは、同じ IP アドレスに対して許容される VPN 接続が 1 つだけであるというプラットフォームの制限によるものです。 Azure Stack Hub ラグドでは、Azure Stack Hub ラグド システム内のすべての VPN ゲートウェイに対して単一のパブリック IP を使用するマルチテナント ゲートウェイが活用されているため、2 つの Azure Stack Hub ラグド システム間に存在できる VPN 接続は 1 つだけです。

この制限は、単一の IP アドレスを使用する VPN ゲートウェイに複数のサイト間 VPN 接続を接続する場合にも当てはまります。 Azure Stack Hub ラグドでは、同じ IP アドレスを使用して複数のローカル ネットワーク ゲートウェイ リソースを作成することはできません。**

IPsec/IKE パラメーター

Azure Stack Hub ラグドで VPN 接続を設定する場合、両端で接続を構成する必要があります。 Azure Stack Hub ラグドとハードウェア デバイスの間に VPN 接続を構成する場合、そのデバイスによって追加の設定が要求されることがあります。 たとえば、VPN ゲートウェイとして機能するスイッチやルーターなどです。

イニシエーターとレスポンダーの両方として複数のオファーをサポートしている Azure とは異なり、Azure Stack Hub ラグドでは、既定で 1 つのオファーのみがサポートされます。 VPN デバイスを操作するために異なる IPSec/IKE 設定を使用する必要がある場合は、接続を手動で構成するために使用できる設定が他にもあります。

IKE フェーズ 1 (メイン モード) のパラメーター

プロパティ Value
IKE のバージョン IKEv2
Diffie-hellman グループ ECP384
認証方法 事前共有キー
暗号化とハッシュ アルゴリズム AES256、SHA384
SA の有効期間 (時間) 28,800 秒

IKE フェーズ 2 (クイック モード) のパラメーター

プロパティ Value
IKE のバージョン IKEv2
暗号化とハッシュ アルゴリズム (暗号化) GCMAES256
暗号化とハッシュ アルゴリズム (認証) GCMAES256
SA の有効期間 (時間) 27,000 秒
SA の有効期間 (キロバイト単位) 33,553,408
Perfect Forward Secrecy (PFS) ECP384
Dead Peer Detection サポートされています

カスタム IPsec/IKE 接続ポリシーを構成する

IPsec/IKE 標準プロトコルでは、幅広い暗号アルゴリズムがさまざまな組み合わせでサポートされています。 コンプライアンスまたはセキュリティ要件を満たすことができるように、Azure Stack Hub ラグドでサポートされているパラメーターを確認するには、IPsec/IKE パラメーターに関する記事を参照してください。

この記事では、IPsec/IKE ポリシーを作成して構成し、新規または既存の接続に適用する方法を示します。

考慮事項

ポリシーを使用する際は、次の重要な考慮事項に注意してください。

  • IPsec/IKE ポリシーは、Standard および HighPerformance (ルートベース) ゲートウェイ SKU でのみ機能します。
  • ある特定の接続に対して指定できるポリシーの組み合わせは 1 つ だけです。
  • IKE (メイン モード) と IPsec (クイック モード) の両方について、すべてのアルゴリズムとパラメーターを指定する必要があります。 ポリシーを部分的に指定することはできません。
  • オンプレミスの VPN デバイスでポリシーがサポートされることを、VPN デバイス ベンダーの仕様で確認してください。 ポリシーに対応していない場合、サイト対サイト接続を確立することはできません。

IPsec/IKE ポリシーを作成して設定するためのワークフロー

このセクションでは、サイト対サイト VPN 接続に関する IPsec/IKE ポリシーの作成と更新を行うために必要なワークフローについて説明します。

  1. 仮想ネットワークと VPN ゲートウェイを作成します。
  2. クロスプレミス接続用のローカル ネットワーク ゲートウェイを作成します。
  3. 選択したアルゴリズムとパラメーターを使用して IPsec/IKE ポリシーを作成します。
  4. IPsec/IKE ポリシーを使用する IPSec 接続を作成します。
  5. 既存の接続に対して、IPsec/IKE ポリシーを追加/更新/削除します。

サポートされる暗号アルゴリズムとキーの強度

以下の表は、サポートされている暗号アルゴリズムと、Azure Stack Hub ラグドのお客様が構成できるキーの強度を一覧にしたものです。

IPsec/IKEv2 [オプション]
IKEv2 暗号化 AES256、AES192、AES128、DES3、DES
IKEv2 整合性 SHA384、SHA256、SHA1、MD5
DH グループ ECP384、ECP256、DHGroup14、DHGroup2048、DHGroup2、DHGroup1、なし
IPsec 暗号化 GCMAES256、GCMAES192、GCMAES128、AES256、AES192、AES128、DES3、DES、なし
IPsec 整合性 GCMASE256、GCMAES192、GCMAES128、SHA256、SHA1、MD5
PFS グループ PFS24、ECP384、ECP256、PFS2048、PFS2、PFS1、なし
QM SA の有効期間 (オプション: 指定されていない場合、既定値が使用されます)
秒 (整数: 最小値 300 秒、既定値 27,000 秒)
キロバイト数 (整数: 最小値 1,024 キロバイト、既定値 102,400,000 キロバイト)
トラフィック セレクター Azure Stack Hub ラグドではポリシー ベースのトラフィック セレクターはサポートされていません。

ご使用のオンプレミス VPN デバイスの構成は、Azure IPsec/IKE ポリシーで指定した次のアルゴリズムおよびパラメーターと一致している (または含んでいる) 必要があります。

  • IKE 暗号化アルゴリズム (メイン モード/フェーズ 1)。
  • IKE 整合性アルゴリズム (メイン モード/フェーズ 1)。
  • DH グループ (メイン モード/フェーズ 1)。
  • IPsec 暗号化アルゴリズム (クイック モード/フェーズ 2)。
  • IPsec 整合性アルゴリズム (クイック モード/フェーズ 2)。
  • PFS グループ (クイック モード/フェーズ 2)。
  • SA の有効期間は、ローカルの指定のみであり、それらが一致している必要はありません。

IPsec 暗号化アルゴリズム用として GCMAES を使用する場合は、IPsec 整合性に、同じ GCMAES アルゴリズムとキーの長さを選択する必要があります。 たとえば、両方に GCMAES128 を使用します。

上記の表では、

  • IKEv2 はメイン モードまたはフェーズ 1 に対応しています。
  • IPsec はクイック モードまたはフェーズ 2 に対応しています。
  • DH グループは、メイン モードまたはフェーズ 1 で使用される Diffie-Hellman グループを指定します。
  • PFS グループは、クイック モードまたはフェーズ 2 で使用される Diffie-Hellman グループを指定します。
  • Azure Stack Hub ラグドの VPN ゲートウェイでは、IKEv2 メイン モード SA の有効期間は 28,800 秒に固定されています。

以下の表は、カスタム ポリシーでサポートされている、対応する Diffie-Hellman グループを示したものです。

Diffie-Hellman グループ DHGroup PFSGroup キーの長さ
1 DHGroup1 PFS1 768 ビット MODP
2 DHGroup2 PFS2 1024 ビット MODP
14 DHGroup14 PFS2048 2048 ビット MODP
DHGroup2048
19 ECP256 ECP256 256 ビット ECP
20 ECP384 ECP384 384 ビット ECP
24 DHGroup24 PFS24 2048 ビット MODP

Azure ExpressRoute を使用して Azure Stack Hub ラグドを Azure に接続する

概要と前提条件

Azure ExpressRoute を使用すると、オンプレミスのネットワークを Microsoft クラウドに拡張できます。 接続プロバイダーによって提供されるプライベート接続を使用します。 ExpressRoute は、パブリック インターネットを経由する VPN 接続ではありません。

Azure ExpressRoute の詳細については、ExpressRoute の概要に関するページを参照してください。

前提条件

この記事では、以下のことを前提としています。

  • Azure に関する実践的な知識がある。
  • Azure Stack Hub ラグドに関する基礎知識がある。
  • ネットワークに関する基礎知識がある。

前提条件

ExpressRoute を使用して Azure Stack Hub ラグドと Azure を接続するには、次の要件を満たしている必要があります。

  • 接続プロバイダー経由でプロビジョニングされている ExpressRoute 回線。
  • Azure で ExpressRoute 回線と VNet を作成するための Azure サブスクリプション。
  • 以下をサポートするルーター:
    • LAN インターフェイスと Azure Stack Hub ラグド マルチテナント ゲートウェイの間のサイト間 VPN 接続。
    • Azure Stack Hub ラグドの配置に複数のテナントが存在する場合に、複数の VRF (Virtual Routing and Forwarding) を作成すること。
  • 次のポートを備えたルーター。
    • ExpressRoute 回線に接続された WAN ポート。
    • Azure Stack Hub ラグド マルチテナント ゲートウェイに接続された LAN ポート。

ExpressRoute ネットワークのアーキテクチャ

次の図は、この記事の例に従って ExpressRoute の設定を完了した後の Azure Stack Hub ラグドと Azure の環境を示しています。

ExpressRoute ネットワークのアーキテクチャ

次の図は、複数のテナントが ExpressRoute ルーターを介して Azure Stack Hub ラグド インフラストラクチャから Azure に接続するしくみを示しています。

ExpressRoute ネットワーク アーキテクチャ マルチテナント