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 资源管理器功能和优点的更多内容。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.

作为 VNet 迁移的一部分,VPN 网关将从经典部署模型迁移到 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
  • 使用 VPN 网关的两个 Vnet 之间的 VNet 到 VNet 连接VNet to VNet connectivity between two VNets using VPN gateways
  • 多个 Vnet 连接到同一本地位置Multiple 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.

备注

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. 可以在连接资源中使用“Vnet 到 Vnet”连接类型直接实现两个 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 网关和两个 Vnet 到 Vnet 类型的连接的 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. 这就是传输 VNet 连接,其中第一个 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 网关迁移支持后,请转到在支持的平台上将 IaaS 资源从经典模型迁移到 Resource Manager 模型开始学习。After learning about VPN gateway migration support, go to platform-supported migration of IaaS resources from classic to Resource Manager to get started.