将 VPN 网关从经典部署模型迁移到 Resource Manager 部署模型VPN Gateway classic to Resource Manager migration

现在可以将 VPN 网关从经典部署模型迁移到 Resource Manager 部署模型。VPN Gateways can now be migrated from classic to Resource Manager deployment model. 可以阅读有关 Azure Resource Manager 功能和优点的更多内容。You can read more about Azure Resource Manager features and benefits. 本文详细介绍如何从经典部署模型迁移到更新的基于 Resource Manager 的部署模型。In this article, we detail how to migrate from classic deployments to newer Resource Manager based model.

VPN 网关将作为 VNet 迁移的一部分从经典部署模型迁移到 Resource Manager 部署模型。VPN Gateways are migrated as part of VNet migration from classic to Resource Manager. 此迁移是按一次一个 VNet 完成的。This migration is done one VNet at a time. 就迁移的工具和先决条件而言,没有任何其他要求。There is no additional requirement in terms of tools or prerequisites to migration. 迁移步骤与现有 VNet 迁移步骤相同,并且已在 IaaS 资源迁移页进行了编档。Migration steps are identical to existing VNet migration and are documented at IaaS resources migration page. 在迁移期间数据路径不会关闭,因此在迁移过程中现有的工作负荷继续正常运行,并且本地连接不会丢失。There is no data path downtime during migration and thus existing workloads would continue to function without loss of on-premises connectivity during migration. 在迁移过程中,与 VPN 网关关联的公共 IP 地址不会更改。The public IP address associated with the VPN gateway does not change during the migration process. 这意味着在迁移完成后不需要重新配置本地路由器。This implies that you will not need to reconfigure your on-premises router once the migration is completed.

Resource Manager 中的模型与经典模型不同,它由虚拟网络网关、本地网络网关和连接资源组成。The model in Resource Manager is different from classic model and is composed of virtual network gateways, local network gateways and connection resources. 这些分别表示 VPN 网关本身、表示本地地址空间的本地站点和这两者之间的连接。These represent the VPN gateway itself, the local-site representing on premises address space and connectivity between the two respectively. 迁移完成后,网关将无法在经典模型中使用,对虚拟网络网关、本地网络网关和连接对象的所有管理操作必须使用 Resource Manager 模型执行。Once migration is completed your gateways would not be available in classic model and all management operations on virtual network gateways, local network gateways, and connection objects must be performed using Resource Manager model.

支持的方案Supported scenarios

经典部署模型到 Resource Manager 部署模型的迁移涵盖了最常见的 VPN 连接方案。Most common VPN connectivity scenarios are covered by classic to Resource Manager migration. 支持的方案包括:The supported scenarios include -

  • 点到站点连接Point to site connectivity
  • 使用连接到本地位置的 VPN 网关的站点到站点连接Site to site connectivity with VPN Gateway connected to on premises location
  • 两个 VNet 之间使用 VPN 网关的 VNet 到 VNet 连接VNet to VNet connectivity between two VNets using VPN gateways
  • 连接到同一本地位置的多个 VNetMultiple VNets connected to same on premises location
  • 多站点连接Multi-site connectivity
  • 已启用强制隧道的 VNetForced tunneling enabled VNets

不支持的方案包括:Scenarios which are not supported include -

  • 当前不支持使用 ExpressRoute 网关和 VPN 网关的 VNet。VNet with both ExpressRoute Gateway and VPN Gateway is not currently supported.
  • 其中的 VM 扩展连接到本地服务器的传输方案。Transit scenarios where VM extensions are connected to on-premises servers. 下文会详细介绍传输 VPN 连接限制。Transit VPN connectivity limitations are detailed below.

备注

相比经典模型中的 CIDR 验证,Resource Manager 模型中的 CIDR 验证更为严格。CIDR validation in Resource Manager model is more strict than the one in classic model. 在迁移之前,请确保给定的经典地址范围符合有效的 CIDR 格式,再开始迁移。Before migrating ensure that classic address ranges given conform to valid CIDR format before beginning the migration. 可以使用任何常见的 CIDR 验证程序验证 CIDR。CIDR can be validated using any common CIDR validators. 迁移时,具有无效 CIDR 范围的 VNet 或本地站点会导致失败状态。VNet or local sites with invalid CIDR ranges when migrated would result in failed state.

VNet 到 VNet 连接迁移VNet to VNet connectivity migration

经典模型中的 VNet 到 VNet 连接是通过创建已连接 VNet 的本地站点表示形式来实现的。VNet to VNet connectivity in classic was achieved by creating a local site representation of the connected VNet. 客户需要创建两个本地站点来表示需连接在一起的两个 VNet。Customers were required to create two local sites which represented the two VNets which needed to be connected together. 然后,使用 IPsec 隧道将这两个本地站点连接到相应的 VNet,以便在这两个 VNet 之间建立连接。These were then connected to the corresponding VNets using IPsec tunnel to establish connectivity between the two VNets. 由于一个 VNet 中的任何地址范围更改还必须在相应的本地站点表示形式中进行相应维护,因此此模型在可管理性方面具有挑战性。This model has manageability challenges since any address range changes in one VNet must also be maintained in the corresponding local site representation. 在 Resource Manager 模型中不再需要此解决方法。In Resource Manager model this workaround is no longer needed. 可以使用连接资源中的“Vnet2Vnet”连接类型直接实现两个 VNet 之间的连接。The connection between the two VNets can be directly achieved using 'Vnet2Vnet' connection type in Connection resource.

VNet 到 VNet 迁移的屏幕截图。

在 VNet 迁移期间我们检测到当前 VNet 的 VPN 网关所连接的实体是另一个 VNet,并确保这两个 VNet 的迁移完成后,不会再看到表示另一个 VNet 的两个本地站点。During VNet migration we detect that the connected entity to current VNet's VPN gateway is another VNet and ensure that once migration of both VNets is completed, you would no longer see two local sites representing the other VNet. 两个 VPN 网关、两个本地站点以及它们之间的两个连接的经典模型会转换为具有两个 VPN 网关和两个 Vnet2Vnet 类型的连接的 Resource Manager 模型。The classic model of two VPN gateways, two local sites and two connections between them is transformed to Resource Manager model with two VPN gateways and two connections of type Vnet2Vnet.

传输 VPN 连接Transit VPN connectivity

可以在拓扑中配置 VPN 网关,以便 VNet 的本地连接可以通过连接到直接连接到本地的另一个 VNet 来实现。You can configure VPN gateways in a topology such that on-premises connectivity for a VNet is achieved by connecting to another VNet that is directly connected to on-premises. 这是传输 VPN 连接,其中第一个 VNet 中的实例通过传输到直接连接到本地的已连接 VNet 中的 VPN 网关来连接到本地资源。This is transit VPN connectivity where instances in first VNet are connected to on-premises resources via transit to the VPN gateway in connected VNet that is directly connected to on-premises. 若要在经典部署模型中实现此配置,需要创建具有聚合前缀的本地站点来同时表示已连接的 VNet 和本地地址空间。To achieve this configuration in classic deployment model, you would need to create a local site which has aggregated prefixes representing both the connected VNet and on-premises address space. 然后将此表述性本地站点连接到 VNet,以实现传输连接。This representational local site is then connected to the VNet to achieve transit connectivity. 此经典模型在可管理性方面也具有类似的挑战性,因为也必须在表示 VNet 和本地的聚合的本地站点上维护本地地址范围中的任何更改。This classic model also has similar manageability challenges since any change in on-premises address range must also be maintained on the local site representing the aggregate of VNet and on-premises. 在 Resource Manager 支持的网关中引入 BGP 支持可简化可管理性,因为连接的网关可以从本地了解路由,而不用手动修改前缀。Introduction of BGP support in Resource Manager supported gateways simplifies manageability since the connected gateways can learn routes from on premises without manual modification to prefixes.

传输路由方案的屏幕截图。

由于我们转换 VNet 到 VNet 连接而无需本地站点,对于间接连接到本地的 VNet,传输方案将失去本地连接。Since we transform VNet to VNet connectivity without requiring local sites, the transit scenario loses on-premises connectivity for VNet that is indirectly connected to on-premises. 完成迁移后,可以按照以下两种方式缓解丢失连接的情况:The loss of connectivity can be mitigated in the following two ways, after migration is completed -

  • 在连接在一起和连接到本地的 VPN 网关上启用 BGP。Enable BGP on VPN gateways that are connected together and to on-premises. 由于路由是在 VPN 网关之间学习和播发的,所以启用 BGP 可还原连接,而且无需更改任何其他配置。Enabling BGP restores connectivity without any other configuration change since routes are learned and advertised between VPN gateways. 请注意,BGP 选项仅在“标准”和更高版本的 SKU 上可用。Note that BGP option is only available on Standard and higher SKUs.
  • 从受影响的 VNet 到表示本地位置的本地网络网关建立显式连接。Establish an explicit connection from affected VNet to the local network gateway representing on-premises location. 这还需要更改本地路由器的配置,才能创建和配置 IPsec 隧道。This would also require changing configuration on the on-premises router to create and configure the IPsec tunnel.

后续步骤Next steps

了解 VPN 网关迁移支持后,请转到平台支持的从经典部署模型到 Resource Manager 部署模型的 IaaS 资源迁移来开始使用。After learning about VPN gateway migration support, go to platform-supported migration of IaaS resources from classic to Resource Manager to get started.