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

[アーティクル]
11/14/2024

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 ゲートウェイの検索

PowerShell を使用してクラシック VPN ゲートウェイを検索するには、Azure PowerShell Service Management モジュールをインストールする必要があります。ここから開始: Azure PowerShell Service Management モジュールのインストール。クラシックリソースを表示するには、共同管理者または所有者のアクセス許可が必要です。 Az コマンドレットを使用してクラシックリソースにアクセスすることはできません。

Azure portal を使用してクラシック VPN ゲートウェイを検索するには、ポータルを開き、"仮想ネットワーク (クラシック)" を検索します。クラシック仮想ネットワークを選択し、ゲートウェイブレードに移動して、クラシック仮想ネットワークゲートウェイを見つけます。

サポートされるシナリオ

最も一般的な 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 の 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 リソースの移行に関する記事をご覧ください。

次の方法で共有