次の方法で共有

VPN Gateway クラシックから Resource Manager への移行

  • [アーティクル]

VPN ゲートウェイをクラシック デプロイ モデルから Resource Manager デプロイ モデルに移行できるようになりました。 詳細については、「Resource Manager デプロイ モデル」を参照してください。 この記事では、クラシック デプロイから Resource Manager モデルへの移行方法について説明します。

重要

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

VPN ゲートウェイは、クラシックから Resource Manager への VNet 移行から始まります。 この移行では、一度に 1つの VNet が顧客によって移行されます。 VNet の移行を開始するためのツールや前提条件の点では、追加の要件はありません。 移行手順は既存の VNet の移行と同じで、「IaaS リソースの移行に関するページ」に記載されています。

VNet の移行中にデータ パスのダウンタイムはないため、既存のワークロードは、移行中にオンプレミス接続が失われることなく、引き続き動作します。 VPN ゲートウェイに関連付けられているパブリック IP アドレスは、移行プロセス中も変化しません。 そのため、移行完了後にオンプレミスのルーターを再構成する必要はありません。

VNet の移行が完了すると、Azure は残りのゲートウェイの Resource Manager への移行を完了しようとします。 ゲートウェイの移行が成功しない場合は、VPN Gateway (クラシック デプロイ) を削除し、新しい VPN ゲートウェイ (Resource Manager) を作成するように通知される場合があります。 顧客によるアクションがない場合、既存の VPN Gateway (クラシック デプロイ) が使用停止になる可能性があります。 顧客は、FAQ にアクセスして追加情報を確認し、クラシックから Resource Manager への移行中のダウンタイムを最小限に抑えることができます。

Resource Manager モデルはクラシック モデルと異なり、仮想ネットワーク ゲートウェイ、ローカル ネットワーク ゲートウェイ、接続リソースで構成されています。 これらは、それぞれ VPN Gateway、 オンプレミスのアドレス空間であるローカルサイト、 2 つの間の接続を表します。 移行が完了すると、ゲートウェイはクラシック モデルでは利用できなくなり、仮想ネットワーク ゲートウェイ、ローカル ネットワーク ゲートウェイ、接続オブジェクトのすべての管理操作は、Resource Manager モデルを使って行う必要があります。

サポートされるシナリオ

最も一般的な VPN 接続のシナリオは、クラシックからリソース マネージャーへの移行で対応されています。 次のようなシナリオがサポートされます。

  • ポイント対サイト接続
  • オンプレミスの場所に接続している VPN ゲートウェイを使用したサイト間接続
  • VPN ゲートウェイを使用している 2 つの VNet 間の接続
  • 同じオンプレミスの場所に接続している複数の VNet
  • マルチサイト接続
  • 強制トンネリングが有効になっている VNet

サポートされていないシナリオは次のとおりです。

  • ExpressRoute ゲートウェイと VPN ゲートウェイの両方を備えた VNet は、現在サポートされていません。
  • VM 拡張機能がオンプレミスのサーバーに接続している場合のトランジット シナリオ。 トランジット VPN 接続の制限は次のセクションで詳細に説明されています。

Note

Resource Manager モデルの CIDR 検証は、クラシック モデルの検証よりも厳密になっています。 移行の前に、クラシックのアドレス範囲が、移行の開始前の有効な CIDR 形式に準拠していることを確認します。 CIDR は、一般的な CIDR バリデーターを使用して検証できます。 移行時の無効な CIDR 範囲の VNet やローカル サイトは、エラー状態になります。

VNet 間接続の移行

クラシック デプロイ モデルでの VNet 間接続は、接続された VNet を表すローカル サイトを作成することで実現されていました。 互いに接続する必要のある 2 つの VNet を表す 2 つのローカル サイトを作成する必要がありました。 これらのローカル サイトは、対応する VNet に IPsec トンネルを使用して接続され、2 つの VNet 間の接続が確立されていました。 このモデルには管理性の問題があります。1 つの VNet 内のアドレス範囲の変更が、対応するローカル サイトの表現にも反映される必要があるためです。 Resource Manager モデルでは、これの回避策は必要なくなりました。 2 つの VNet 間の接続は、接続リソース中の 'Vnet2Vnet' という接続の種類を使用することにより直接確立できます。

VNet 間の移行を表す図。

VNet の移行中に、現在の VNet の VPN ゲートウェイに接続されているエンティティが別の VNet であることが検出されます。 両方の VNet の移行が完了すると、他方の VNet を表す 2 つのローカル サイトがなくなることが保証されています。 2 つの VPN ゲートウェイ、2 つのローカル サイト、それらを結ぶ 2 つの接続というクラシック モデルは、2 つの VPN ゲートウェイと種類が Vnet2Vnet である 2 つの接続を持つ Resource Manager モデルに変換されます。

トランジット VPN 接続

オンプレミスに直接接続している別の VNet に接続することによって、VNet へのオンプレミス接続を確立する、というトポロジで、VPN Gateway を構成できます。 これはトランジット VPN 接続であり、1 つ目の VNet のインスタンスは、直接オンプレミスに接続されている接続先 Vnet 上にある VPN ゲートウェイへのトランジットによってオンプレミス リソースに接続されます。 クラシック デプロイ モデルでこの構成を実現するには、接続先の VNet とオンプレミス両方のアドレス空間を表す集計プレフィックスを持つローカル サイトを作成する必要があります。 その後、そのローカル サイトを VNet に接続してトランジット接続が確立されていました。 クラシック モデルには類似した管理性の問題もあります。オンプレミスのアドレス範囲の変更が、VNet とオンプレミスの集計を表すローカル サイトにも反映されなければならないからです。 Resource Manager がサポートされるゲートウェイで BGP のサポートが導入されたことにより、管理が簡素化されます。接続されているゲートウェイがオンプレミスからルートを学習することができ、プレフィックスの手動修正がなくなるからです。

トランジット ルーティングのシナリオを表す図。

ローカル サイト を必要とせずに、VNet 間接続を変換するため、トランジット シナリオでは、間接的にオンプレミスに接続されていた VNet のオンプレミス接続が失われることになります。 接続が失われることの影響は、移行の完了後に、次の 2 つの方法で軽減することができます。

  • 互いに接続された状態で、オンプレミスの場所に接続されている VPN ゲートウェイで BGP を有効にします。 BGP を有効にすると、ルートは学習され VNet ゲートウェイ間で通知され合うため、他の構成の変更なしに接続が復元されます。 BGP オプションは、Standard 以上の SKU でのみ利用できることに注意してください。
  • 影響を受ける VNet から、オンプレミスの場所を表すローカル ネットワーク ゲートウェイへの明示的な接続を確立します。 これには、オンプレミスのルーターの構成を変更して、IPsec トンネルを作成、構成する必要もあります。

次のステップ

VPN Gateway の移行サポートについて学習した後は、プラットフォームでサポートされる、クラシックから Azure Resource Manager への IaaS リソースの移行に関する記事をご覧ください。