VNet 間の接続の構成 (クラシック)

  • [アーティクル]

この記事では、仮想ネットワーク間で VPN ゲートウェイ接続を確立する方法について説明します。 仮想ネットワークが属しているリージョンやサブスクリプションは異なっていてもかまいません。

この記事の手順は、クラシック (レガシ) デプロイ モデルに適用されるもので、現在のデプロイ モデルである Resource Manager には適用されません。 クラシック デプロイ モデルを使用してゲートウェイを作成することができなくなります。 代わりに、この記事の Resource Manager バージョンを参照してください。

重要

クラシック デプロイ モデル (サービス管理) 仮想ネットワーク用の新しい仮想ネットワーク ゲートウェイは、作成できなくなりました。 新しい仮想ネットワーク ゲートウェイを作成できるのは、Resource Manager 仮想ネットワーク用のみです。

Diagram showing classic VNet-to-VNet architecture.

Note

この記事は、クラシック (レガシ) デプロイ モデルのために書かれています。 代わりに、最新の Azure デプロイ モデルを使用することをお勧めします。 Resource Manager デプロイ モデルは、最新のデプロイ モデルであり、クラシック デプロイ モデルよりも多くのオプションと機能の互換性が提供されています。 これら 2 つのデプロイ モデルの違いについて理解するには、「デプロイ モデルとリソースの状態を理解する」を参照してください。

この記事の別のバージョンを使用したい場合は、左側のペインの目次を使用します。

VNet 間接続の概要

VPN Gateway を使用したクラシック デプロイ モデルでの仮想ネットワーク間 (VNet 間) の接続は、仮想ネットワークをオンプレミスのサイトの場所に接続することと似ています。 どちらの接続タイプでも、VPN ゲートウェイを使用して、IPsec/IKE を使った安全なトンネルが確保されます。

接続する VNet は、サブスクリプションやリージョンが異なっていてもかまいません。 マルチサイト構成と VNet 対 VNet 通信を組み合わせることができます。 そのため、クロスプレミス接続と仮想ネットワーク間接続とを組み合わせたネットワーク トポロジを確立することができます。

Diagram showing VNet-VNet connections.

仮想ネットワークを接続する理由

仮想ネットワークへの接続が必要なのは、次のような場合です。

  • リージョン間の geo 冗長性および geo プレゼンス

    • インターネット接続エンドポイントを介さず、安全な接続を使って独自の geo レプリケーションや geo 同期をセットアップすることができます。
    • Azure Load Balancer と Microsoft (またはサード パーティ) のクラスタリング テクノロジを使用し、複数の Azure リージョンをまたぐ geo 冗長性を備えた、可用性に優れたワークロードをセットアップすることができます。 たとえば、複数の Azure リージョンにまたがる SQL AlwaysOn 可用性グループをセットアップすることができます。

  • 特定の地域内で強固な分離境界を備えた多層アプリケーション

    • 同じリージョン内の相互に接続された複数の VNet を使って多層アプリケーションをセットアップすることができます。それぞれの層のアプリケーションが強固に分離され、安全な層間通信を実現することができます。

  • サブスクリプションや組織の境界を越えた通信を Azure 内で実現

    • Azure サブスクリプションを複数所有している場合、異なるサブスクリプションからのワークロードを仮想ネットワークを介して安全に接続することができます。
    • 企業やサービス プロバイダーが、安全な VPN テクノロジを使用した組織間の通信を Azure 内で実現できます。

VNet 間接続の詳細については、この記事の最後にある「VNet 間の考慮事項」を参照してください。

前提条件

ほとんどの手順でポータルを使用しますが、VNet 間の接続を確立する場合は、PowerShell を使う必要があります。 Azure portal を使用して接続を作成することはできません。ポータルでは共有キーを指定する方法がないためです。 クラシック デプロイ モデルを使って作業している場合、Azure Cloud Shell は使用できません。 代わりに、Azure サービス管理 (SM) PowerShell コマンドレットの最新バージョンを、お使いのコンピューターにローカルにインストールする必要があります。 これらのコマンドレットは、AzureRM または Az のコマンドレットとは異なります。 SM コマンドレットをインストールするには、サービス管理コマンドレットのインストールに関する記事を参照してください。 Azure PowerShell 全般の詳細については、Azure PowerShell のドキュメントを参照してください。

計画

仮想ネットワークの構成に使用する範囲を決めることは重要です。 この構成では、VNet のアドレス範囲が、互いにまたは接続先のすべてのローカル ネットワークと重複していないことを確認する必要があります。

VNet

この演習では、次のサンプル値を使用します。

TestVNet1 の値

名前: TestVNet1
アドレス空間: 10.11.0.0/16, 10.12.0.0/16 (省略可能)
サブネット名: 既定
サブネットのアドレス範囲: 10.11.0.0/24
リソース グループ: ClassicRG
場所: 米国東部
GatewaySubnet: 10.11.1.0/27

TestVNet4 の値

名前: TestVNet4
アドレス空間: 10.41.0.0/16, 10.42.0.0/16 (省略可能)
サブネット名: 既定
サブネットのアドレス範囲: 10.41.0.0/24
リソース グループ: ClassicRG
場所: 米国西部
GatewaySubnet: 10.41.1.0/27

接続

VNet 同士を接続する方法の例を次の表に示します。 範囲はあくまでも参考です。 仮想ネットワークの範囲をメモしておいてください。 この情報は後続の手順で必要になります。

この例では、TestVNet1 は "VNet4Local" という名前で作成するローカル ネットワーク サイトに接続します。 VNet4Local の設定には、TestVNet4 のアドレス プレフィックスが含まれています。 それぞれの VNet のローカル サイトが、もう一方の VNet になります。 この構成には、次の例の値が使用されます。

例

Virtual Network アドレス空間 場所 ローカル ネットワーク サイトへの接続
TestVNet1 TestVNet1
(10.11.0.0/16)
(10.12.0.0/16)		 米国東部 SiteVNet4
(10.41.0.0/16)
(10.42.0.0/16)
TestVNet4 TestVNet4
(10.41.0.0/16)
(10.42.0.0/16)		 米国西部 SiteVNet1
(10.11.0.0/16)
(10.12.0.0/16)

仮想ネットワークを作成する

この手順では、TestVNet1 と TestVNet4 の 2 つのクラシック仮想ネットワークを作成します。 この記事を演習として使用している場合、サンプル値を使用してください。

VNet を作成するときは、次の設定に注意してください。

  • [仮想ネットワーク アドレス空間] – [仮想ネットワーク アドレス空間] ページには、仮想ネットワークに使用するアドレス範囲を指定します。 これらが動的 IP アドレスとして、この仮想ネットワークにデプロイする VM や各種ロール インスタンスに割り当てられます。
    他の VNet や、この VNet の接続先となるオンプレミスの場所のアドレス空間と重複するアドレス空間を選択することはできません。

  • [場所] - 仮想ネットワークを作成するとき、仮想ネットワークを Azure の場所 (リージョン) に関連付けます。 たとえば、仮想ネットワークにデプロイされた VM を物理的に米国西部に配置する場合は、その場所を選択します。 仮想ネットワークを作成した後で、その仮想ネットワークに関連付けられた場所を変更することはできません。

VNet を作成した後、次の設定を追加できます。

  • アドレス空間 – この構成用に追加のアドレス空間は必要ありませんが、VNet を作成した後に追加のアドレス空間を追加することができます。

  • サブネット – この構成用に追加のサブネットは必要ありませんが、他のロール インスタンスとは別個のサブネットに VM を配置したい場合が考えられます。

  • [DNS サーバー] – DNS サーバー名と IP アドレスを入力します。 この設定で、DNS サーバーは作成されません。 この設定では、この仮想ネットワークの名前解決に使用する DNS サーバーを指定することができます。

クラシック仮想ネットワークを作成するには

  1. ブラウザーから Azure Portal に移動します。必要であれば Azure アカウントでサインインします。
  2. [+リソースの作成] を選択します。 [Marketplace を検索] フィールドに「仮想ネットワーク」と入力します。 検索結果の一覧から [仮想ネットワーク] を探して選択し、 [仮想ネットワーク] ページを開きます。
  3. [Virtual Network] ページの [作成] ボタンの下にある [Deploy with Resource Manager (change to Classic)](Resource Manager によるデプロイ (クラシックに変更)) を確認します。 VNet を作成する場合の既定は、Resource Manager です。 Resource Manager VNet を作成したいとは考えていません。 [(change to Classic)](クラシックに変更) を選択して、クラシック VNet を作成します。 次に、 [概要] タブを選択し、 [作成] を選択します。
  4. [仮想ネットワーク (クラシック) の作成] ページの [基本] タブで、VNet 設定を例の値のに構成します。
  5. [確認および作成] を選択して VNet を検証します。
  6. 検証が実行されます。 VNet が検証されたら、 [作成] を選択します。

この構成では DNS 設定は必須ではありませんが、VM 間で名前解決を行う場合は DNS が必要です。 値を指定しても新しい DNS サーバーは作成されません。 指定する DNS サーバーの IP アドレスは、接続先のリソースの名前を解決できる DNS サーバーの IP アドレスである必要があります。

仮想ネットワークを作成した後は、名前解決を処理するために、DNS サーバーの IP アドレスを追加できます。 仮想ネットワークの設定を開き、DNS サーバーを選択し、名前解決に使用する DNS サーバーの IP アドレスを追加します。

  1. ポータルで仮想ネットワークを見つけます。
  2. 仮想ネットワークのページで、 [設定] セクションの [DNS サーバー] を選択します。
  3. DNS サーバーを追加します。
  4. 設定を保存するには、ページの上部にある [保存] をクリックします。

サイトとゲートウェイを構成する

Azure では、各ローカル ネットワーク サイトで指定されている設定を使用して、VNet 間でトラフィックをルーティングする方法を決定します。 各 VNet は、トラフィックのルーティング先とする対応するローカル ネットワークをポイントする必要があります。 各ローカル ネットワーク サイトの参照に使用する名前を指定します。 わかりやすい名前を使用することをお勧めします。

たとえば、TestVNet1 は "VNet4Local" という名前で作成するローカル ネットワーク サイトに接続します。 VNet4Local の設定には、TestVNet4 のアドレス プレフィックスが含まれています。

それぞれの VNet のローカル サイトが、もう一方の VNet になることに注意してください。

Virtual Network アドレス空間 場所 ローカル ネットワーク サイトへの接続
TestVNet1 TestVNet1
(10.11.0.0/16)
(10.12.0.0/16)		 米国東部 SiteVNet4
(10.41.0.0/16)
(10.42.0.0/16)
TestVNet4 TestVNet4
(10.41.0.0/16)
(10.42.0.0/16)		 米国西部 SiteVNet1
(10.11.0.0/16)
(10.12.0.0/16)

サイトを構成するには

通常、ローカル サイトとはオンプレミスの場所を指します。 これには、接続の作成先となる VPN デバイスの IP アドレスのほか、VPN ゲートウェイ経由で VPN デバイスにルーティングされる IP アドレス範囲が含まれます。

  1. ご自分の VNet 用のページで、 [設定] の下の [サイト間接続] を選択します。

  2. [サイト間接続] ページで、 [+ 追加] を選択します。

  3. [VPN 接続とゲートウェイの構成] ページで、 [接続の種類] には [サイト間接続] が選択されたままにします。

    • [VPN ゲートウェイの IP アドレス]: これは、オンプレミス ネットワークの VPN デバイスのパブリック IP アドレスです。 他のサイトの VPN ゲートウェイの IP アドレスをまだ入手していないため、この演習では、ダミー アドレスを入力します。 たとえば、5.4.3.2 などです。 その後、他の VNet のゲートウェイを構成したら、この値を調整できます。

    • [クライアント アドレス空間]: このゲートウェイ経由で他の VNet にルーティングする IP アドレス範囲をリストします。 複数のアドレス領域の範囲を追加することができます。 ここで指定する範囲が、仮想ネットワークの接続先となる他のネットワークの範囲、または仮想ネットワーク自体のアドレスの範囲と重複しないようにしてください。

  4. ページの下部にある [確認と作成] を選択しないでください。 代わりに、[次へ: ゲートウェイ]> を選択します。

仮想ネットワーク ゲートウェイを構成するには

  1. [ゲートウェイ] ページで、次の値を選択します。

    • Size: これは、仮想ネットワーク ゲートウェイの作成に使用するゲートウェイ SKU です。 クラシック VPN ゲートウェイでは、古い (レガシ) ゲートウェイ SKU が使用されます。 レガシ ゲートウェイ SKU の詳細については、仮想ネットワーク ゲートウェイ SKU (古い SKU) の利用に関するページを参照してください。 この演習では、 [Standard] を選択できます。

    • ゲートウェイ サブネット: 指定したゲートウェイ サブネットのサイズは、作成する VPN ゲートウェイの構成によって異なります。 /29 のような小さいゲートウェイ サブネットを作成できますが、/27 または /28 を使用することをお勧めします。 これにより、より多くのアドレスを含む大きなサブネットが作成されます。 大規模なゲートウェイ サブネットを使用すると、将来の構成に対応するのに十分な IP アドレスを確保できます。

  2. ページの下部にある [確認と作成] を選択して、設定を検証します。 [作成] を選択してデプロイします。 選択した SKU によっては、仮想ネットワーク ゲートウェイを作成するまでに最大で 45 分かかる可能性があります。

  3. このゲートウェイが作成されている間、次の手順に進むことができます。

TestVNet4 設定を構成する

必要に応じて値を置き換えて、サイトとゲートウェイを作成する手順を繰り返し、TestVNet4 を構成します。 これを演習として行っている場合、サンプル値を使用してください。

ローカル サイトの更新

両方の VNet に対して仮想ネットワーク ゲートウェイを作成したら、VPN ゲートウェイの IP アドレスについてローカル サイトのプロパティを調整する必要があります。

VNet の名前 接続されているサイト ゲートウェイ IP アドレス
TestVNet1 VNet4Local TestVNet4 の VPN ゲートウェイ IP アドレス
TestVNet4 VNet1Local TestVNet1 の VPN ゲートウェイ IP アドレス

パート 1 - 仮想ネットワーク ゲートウェイのパブリック IP アドレスを取得する

  1. [リソース グループ] に移動し、仮想ネットワークを選択して、VNet に移動します。
  2. 仮想ネットワークのページの右側にある [Essentials] ペインで、 [ゲートウェイ IP アドレス] を見つけてクリップボードにコピーします。

パート 2 - ローカル サイトのプロパティを変更する

  1. [サイト間接続] で、接続を選択します。 たとえば、SiteVNet4 です。
  2. サイト間接続の [プロパティ] ページで、 [ローカル サイトの編集] を選択します。
  3. [VPN ゲートウェイの IP アドレス] フィールドに、前のセクションでコピーした VPN ゲートウェイの IP アドレスを貼り付けます。
  4. [OK] を選択します。
  5. システムでフィールドが更新されます。 この方法を使用して、このサイトにルーティングする IP アドレスを追加することもできます。

パート 3 - その他の VNet の手順を繰り返す

TestVNet4 について、手順を繰り返します。

構成値を取得する

Azure Portal でクラシック VNets を作成するときに表示される名前は、PowerShell に使用する完全な名前ではありません。 たとえば、Azure Portal に TestVNet1 という名前で表示されている VNet は、ネットワーク構成ファイルではそれよりもかなり長い名前である可能性があります。 リソース グループ "ClassicRG" の VNet の場合、名前は次のようになります。Group ClassicRG TestVNet1。 接続を作成するときは、ネットワーク構成ファイルに示されている値を使用することが重要です。

次の手順では、Azure アカウントに接続し、ネットワーク構成ファイルをダウンロードして表示し、接続に必要な値を取得します。

  1. Azure サービス管理 (SM) PowerShell コマンドレットの最新バージョンをダウンロードしてインストールします。 ほとんどの場合、ローカルに Resource Manager モジュールがインストールされていますが、サービス管理モジュールはありません。 サービス管理モジュールはレガシであるため、個別にインストールする必要があります。 詳細については、サービス管理用のコマンドレットをインストールすることに関するページを参照してください。

  2. 管理者特権で PowerShell コンソールを開き、アカウントに接続します。 接続するには、次の例を参照してください。 これらのコマンドは、PowerShell サービス管理モジュールを使用してローカルで実行する必要があります。 アカウントに接続します。 接続については、次の例を参考にしてください。

    Add-AzureAccount

  3. アカウントのサブスクリプションを確認します。

    Get-AzureSubscription

  4. 複数のサブスクリプションがある場合は、使用するサブスクリプションを選択します。

    Select-AzureSubscription -SubscriptionId "Replace_with_your_subscription_ID"

  5. コンピューター上にディレクトリを作成します。 たとえば、C:\AzureVNet などです

  6. ネットワーク構成ファイルをそのディレクトリにエクスポートします。 この例では、ネットワーク構成ファイルは C:\AzureNet にエクスポートされます。

    Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml

  7. テキスト エディターでファイルを開き、VNet とサイトの名前を確認します。 これらの名前は、接続を作成する際に使用する名前となります。
    VNet 名は VirtualNetworkSite name = で示されています
    サイト名は LocalNetworkSiteRef name = で示されています

接続を作成する

以上の手順がすべて完了したら、IPsec/IKE 事前共有キーを設定して接続を作成できます。 この一連の手順では、PowerShell を使用します。 クラシック デプロイ モデルの VNet 間接続を、Azure portal で構成することはできません。ポータルでは共有キーを指定することができないためです。

次の例では、共有キーがまったく同じであることに注目してください。 共有キーは常に一致する必要があります。 これらの例の値を、VNet やローカル ネットワーク サイトに使用する正確な名前で置き換えます。

  1. TestVNet1 から TestVNet4 への接続を作成します。 必ず値を変更してください。

    Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet1' `
-LocalNetworkSiteName 'value for _VNet4Local' -SharedKey A1b2C3D4

  2. TestVNet4 から TestVNet1 への接続を作成します。

    Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet4' `
-LocalNetworkSiteName 'value for _VNet1Local' -SharedKey A1b2C3D4

  3. 接続が初期化されるのを待ちます。 ゲートウェイが初期化されると、状態は "成功" になります。

    Error          :
HttpStatusCode : OK
Id             :
Status         : Successful
RequestId      :
StatusCode     : OK

FAQ と考慮事項

これらの考慮事項は、クラシック仮想ネットワークとクラシック仮想ネットワーク ゲートウェイに適用されます。

  • 仮想ネットワークが属しているサブスクリプションは異なっていてもかまいません。
  • 仮想ネットワークが属している Azure リージョン (場所) は異なっていてもかまいません。
  • クラウド サービスや負荷分散エンドポイントは、仮にそれらが相互に接続されていたとしても、仮想ネットワークの境界を越えることはできません。
  • 複数の仮想ネットワークを接続する場合は、VPN デバイスは必要ありません。
  • VNet 間接続でサポートされるのは、Azure Virtual Network の接続です。 仮想ネットワーク内にデプロイされていない仮想マシンやクラウド サービスの接続はサポートされていません。
  • VNet 対 VNet 通信には、動的ルーティング ゲートウェイが必要です。 Azure 静的ルーティング ゲートウェイはサポートされていません。
  • 仮想ネットワーク接続は、マルチサイト VPN と同時に使用することができます。 1 つの仮想ネットワーク VPN ゲートウェイに最大 10 本の VPN トンネルを確立し、他の仮想ネットワークまたはオンプレミス サイトに接続することが可能です。
  • 仮想ネットワークのアドレス空間とオンプレミスのローカル ネットワーク サイトのアドレス空間とが重複しないようにする必要があります。 アドレス空間が重複していると、仮想ネットワークの作成または netcfg 構成ファイルのアップロードの失敗の原因となります。
  • 仮想ネットワーク ペア間の冗長トンネルはサポートされていません。
  • VNet のすべての VPN トンネル (P2S VPN を含む) は、VPN ゲートウェイ上の使用可能な帯域幅を共有し、Azure 内の同じ VPN ゲートウェイ アップタイム SLA を共有します。
  • VNet 間のトラフィックは、Azure バックボーン経由で送信できます。

次のステップ

接続を確認します。 「VPN Gateway 接続の確認」を参照してください。