Migración de VPN Gateway (clásico) a Resource Manager

Las instancias de VPN Gateway ahora se pueden migrar del modelo de implementación clásico al modelo de implementación de Resource Manager. Para más información, consulte Modelo de implementación de Resource Manager. En este artículo, se aborda cómo migrar desde implementaciones clásicas al modelo de Resource Manager.

Importante

Ya no puede crear nuevas puertas de enlace de red virtual para redes virtuales del modelo de implementación clásica (administración de servicios). Las nuevas puertas de enlace de red virtual solo se pueden crear para redes virtuales de Resource Manager.

Las instancias de VPN Gateway se migran como parte de la migración de red virtual del modelo clásico al de Resource Manager. Esta migración se realiza con una red virtual cada vez. No hay requisitos adicionales en términos de herramientas o requisitos previos para migrar. Los pasos de migración son idénticos a los de la migración de red virtual existente y están documentados en la página de migración de recursos de IaaS.

No existe ningún tiempo de inactividad para la ruta de acceso de datos durante la migración y, por tanto, las cargas de trabajo existentes siguen funcionando sin que se pierda la conectividad local durante la migración. La dirección IP pública asociada a la puerta de enlace de VPN no cambia durante el proceso de migración. Esto significa que no tendrá que volver a configurar el enrutador local una vez completada la migración.

El modelo de Resource Manager es diferente del modelo clásico y se compone de puertas de enlace de red virtual, puertas de enlace de red local y recursos de conexión. Estos representan la puerta de enlace de VPN en sí y el sitio local representa el espacio de direcciones local y la conectividad entre ambos respectivamente. Después de completar la migración, las puertas de enlace no estarán disponibles en el modelo clásico y todas las operaciones de administración en puertas de enlace de red virtual, puertas de enlace de red local y objetos de conexión se deben llevar a cabo mediante el modelo de Resource Manager.

Escenarios admitidos

Los escenarios de conectividad VPN más habituales están cubiertos en la migración del modelo clásico al de Resource Manager. Entre los escenarios admitidos, se incluyen los siguientes:

• Conectividad de punto a sitio
• Conectividad de sitio a sitio con conexión de VPN Gateway a una ubicación local
• Conectividad de red virtual a red virtual entre dos redes virtuales con puertas de enlace de VPN
• Varias redes virtuales conectadas a la misma ubicación local
• Conectividad multisitio
• Redes virtuales con la tunelización forzada habilitada

Entre los escenarios que no se admiten se incluyen:

• Actualmente, no se admite la red virtual con una puerta de enlace de ExpressRoute y una puerta de enlace de VPN.
• Escenarios de tránsito donde las extensiones de máquina virtual están conectadas a servidores locales. Las limitaciones de conectividad de VPN de tránsito se detallan en las secciones siguientes.

Nota

La validación de CIDR en el modelo de Resource Manager es más estricta que la del modelo clásico. Antes de comenzar la migración, asegúrese de que los intervalos de direcciones clásicas proporcionados se ajusten al formato CIDR válido. Se puede validar CIDR mediante alguno de los validadores de CIDR habituales. Si se migran sitios locales o redes virtuales con intervalos de CIDR no válidos, se producirá un estado de error.

Migración de la conectividad de red virtual a red virtual

La conectividad de red virtual a red virtual del modelo de implementación clásico se lograba mediante la creación de una representación en el sitio local de la red virtual conectada. Los clientes tenían que crear dos sitios locales que representaban las dos redes virtuales que debían estar conectadas entre sí. Después, estos sitios se conectaban a las redes virtuales correspondientes mediante un túnel IPsec para establecer la conectividad entre ambas redes virtuales. Este modelo presenta problemas de facilidad de uso, ya que cualquier cambio en el intervalo de direcciones de una red virtual se debe mantener también en la representación en el sitio local correspondiente. En el modelo de Resource Manager, esta solución ya no es necesaria. La conexión entre ambas redes virtuales se puede lograr directamente mediante el tipo de conexión "Vnet2Vnet" (de red virtual a red virtual) en el recurso de conexión.

Durante la migración de red virtual, detectamos que la entidad conectada a la instancia de VPN Gateway de la red virtual actual es otra red virtual. Aseguramos que, después de finalizar la migración de ambas red virtuales, ya no verá dos sitios locales representando la otra red virtual. El modelo clásico con dos instancias de VPN Gateway, dos sitios locales y dos conexiones entre ellos se transforma en el modelo de Resource Manager con dos instancias de VPN Gateway y dos conexiones de tipo Vnet2Vnet.

Conectividad de VPN de tránsito

Puede configurar puertas de enlace de VPN en una topología de forma que la conectividad local para una red virtual se logre mediante la conexión a otra red virtual que esté conectada directamente a un sitio local. Se trata de la conectividad de VPN de tránsito, en la que las instancias en la primera red virtual se conectan a recursos locales mediante el tránsito a la puerta de enlace de VPN en la red virtual conectada que está en conexión directa con el sitio local. Para lograr esta configuración en el modelo de implementación clásica, debe crear un sitio local que cuente con prefijos agregados que representen tanto la red virtual conectada como el espacio de direcciones local. Este sitio local de representación se conecta después a la red virtual para lograr la conectividad de tránsito. Este modelo clásico también presenta problemas de facilidad de uso similares, ya que cualquier cambio en el intervalo de direcciones local también debe mantenerse en el sitio local que representa la agregación de la red virtual y el sitio local. La introducción de la compatibilidad con BGP en las puertas de enlace admitidas por Resource Manager simplifica el uso, ya que las puertas de enlace conectadas pueden aprender rutas desde el sitio local sin necesidad de modificar los prefijos manualmente.

Debido a que transformamos la conectividad de red virtual a red virtual sin necesidad de sitios locales, el escenario de tránsito pierde la conectividad local para la red virtual que está conectada de forma indirecta al sitio local. Se puede mitigar la pérdida de conectividad de estas dos maneras, una vez completada la migración:

• Habilite BGP en las puertas de enlace de VPN que están conectadas entre sí y con la ubicación local. Al habilitarse BGP, se restaura la conectividad sin realizar ningún otro cambio de configuración, ya que las rutas se aprenden y anuncian entre las puertas de enlace de red virtual. Tenga en cuenta que la opción de BGP solo está disponible en los SKU Estándar y superiores.
• Establezca una conexión explícita desde la red virtual afectada hacia la puerta de enlace de red local que representa la ubicación local. Esto también podría requerir que se cambie la configuración del enrutador local para crear y configurar el túnel IPsec.

Pasos siguientes

Después de leer sobre la compatibilidad con la migración de puerta de enlace de VPN, vaya a la página sobre la migración de recursos de IaaS admitida por la plataforma del modelo clásico al de Resource Manager para empezar.