Migration de la passerelle VPN du modèle Classic vers le modèle Resource Manager

Les passerelles VPN peuvent désormais être migrées, du modèle de déploiement classique vers le modèle de déploiement Resource Manager. Pour plus d’informations, consultez le modèle de déploiement Resource Manager. Dans cet article, nous expliquons comment migrer des déploiements classiques vers le modèle Resource Manager.

Important

Vous ne pouvez plus créer de passerelles de réseau virtuel pour les réseaux virtuels classiques de modèle de déploiement (management des services). Les nouvelles passerelles de réseau virtuel peuvent être créées uniquement pour des réseaux virtuels Resource Manager.

Les passerelles VPN commencent par une migration de réseau virtuel classique vers Resource Manager. Cette migration est effectuée par les clients, un réseau virtuel à la fois. Il n’existe pas d’exigences supplémentaires en termes d’outils ou de conditions préalables pour commencer la migration de réseau virtuel. Les étapes de migration sont identiques à celles de la procédure de migration de réseau virtuel existante et sont documentées à la page de migration des ressources IaaS.

À aucun moment l’accès aux données n’est interrompu pendant la migration de réseau virtuel, et les charges de travail existantes continuent donc de fonctionner sans perte de connectivité locale. L’adresse IP publique associée à la passerelle VPN ne change pas pendant le processus de migration. Cela veut dire que vous n’avez pas besoin de reconfigurer votre routeur local à l’issue de la migration.

Une fois la migration de réseau virtuel terminée, Azure tente d’effectuer le reste de la migration de la passerelle vers Resource Manager. Si la migration de la passerelle ne réussit pas, les clients peuvent être informés de supprimer leur passerelle VPN (déploiement classique) et de créer une passerelle VPN (Resource Manager). Si le client n’entreprend aucune action, la passerelle VPN existante (déploiement classique) peut être mise hors service. Les clients peuvent consulter les FAQ pour obtenir des informations supplémentaires et réduire les temps d’arrêt pendant la migration de réseau virtuel classique vers Resource Manager.

Le modèle Resource Manager est différent du modèle classique. Il est constitué de passerelles de réseau virtuel, de passerelles de réseau local et de ressources de connexion. Ces éléments représentent respectivement la passerelle VPN proprement dite, le site local représentant l’espace d’adressage local et la connectivité entre les deux. À l’issue de la migration, les passerelles ne sont pas disponibles dans le modèle classique et toutes les opérations de gestion au niveau des passerelles de réseau virtuel, des passerelles de réseau local et des objets de connexion doivent être effectuées selon le modèle Resource Manager.

Localisation d’une passerelle VPN classique

Pour localiser une passerelle VPN classique via PowerShell, vous devez installer le module Management des Services Azure PowerShell. Commencez par ici : Installation du module Management des Services Azure PowerShell. Pour afficher les ressources classiques, vous aurez besoin d’autorisations de coadministrateur ou de propriétaire. Vous ne pouvez pas utiliser les applets de commande Az pour accéder aux ressources classiques.

Pour localiser une passerelle VPN classique via le portail Azure, ouvrez le portail et recherchez « Réseau virtuel (classique) ». Sélectionnez votre réseau virtuel classique et accédez au panneau de passerelle pour rechercher votre passerelle de réseau virtuel classique.

Scénarios pris en charge

La plupart des scénarios de connectivité VPN courants sont couverts par la migration du modèle Classic vers le modèle Resource Manager. Les scénarios pris en charge sont les suivants :

• Connectivité de point à site
• Connectivité site à site avec la passerelle VPN connectée à un emplacement local
• Connectivité entre deux réseaux virtuels en utilisant des passerelles VPN
• Plusieurs réseaux virtuels connectés à un même emplacement local
• Connectivité multisite
• Réseaux virtuels compatibles avec le tunneling forcé

Les scénarios qui ne sont pas pris en charge incluent :

• Réseau virtuel doté d’une passerelle ExpressRoute et d’une passerelle VPN qui n’est actuellement pas prise en charge.
• Scénarios de transit dans lesquels des extensions de machine virtuelle sont connectées à des serveurs locaux. Les limitations de connectivité VPN de transit sont détaillées aux sections suivantes.

Notes

La validation CIDR est plus stricte dans le modèle Resource Manager que dans le modèle classique. Avant de commencer la migration, vérifiez que les plages d’adresses classiques données sont conformes au format CIDR valide avant de commencer la migration. Le routage CIDR peut être validé à l’aide de l’un des validateurs CIDR courants. La migration de réseaux virtuels ou de sites locaux avec des plages CIDR non valides se traduit par un état d’échec.

Migration de connectivité de réseau virtuel à réseau virtuel

Dans le modèle de déploiement classique, la connectivité de réseau virtuel à réseau virtuel était obtenue en créant une représentation sous forme de site local du réseau virtuel connecté. Les clients étaient contraints de créer deux sites locaux qui représentaient les deux réseaux virtuels qui devaient être connectés entre eux. Ceux-ci étaient ensuite connectés aux réseaux virtuels correspondants à l’aide d’un tunnel IPsec pour établir la connectivité entre les deux réseaux virtuels. Ce modèle présente des difficultés en termes de gestion dans le sens où les modifications apportées à la plage d’adresses d’un réseau virtuel doivent aussi être répercutées dans la représentation sous forme de site local correspondant. Dans le modèle Resource Manager, cette solution de contournement n’est plus nécessaire. La connexion entre les deux réseaux virtuels peut être directement obtenue en utilisant le type de connexion « Vnet2Vnet » dans la ressource de connexion.

Pendant la migration VNet, nous détectons que l’entité connectée à la passerelle VPN du VNet actuel est un autre VNet. Nous veillons à ce que lorsque la migration des deux VNet a été réalisée, vous ne voyiez plus deux sites locaux représentant l’autre VNet. Le modèle classique à deux passerelles VPN, deux sites locaux et deux connexions entre eux est transformé en modèle Resource Manager à deux passerelles VPN et deux connexions de type Vnet2Vnet.

Connectivité VPN de transit

Vous pouvez configurer des passerelles VPN dans une topologie de façon à établir une connectivité locale pour un réseau virtuel en le connectant à un autre réseau virtuel directement connecté en local. Il s’agit d’une connectivité VPN de transit dans laquelle les instances présentes dans le premier réseau virtuel sont connectées à des ressources locales par transit vers la passerelle VPN du réseau virtuel connecté directement connecté en local. Pour mettre en place cette configuration dans le modèle de déploiement classique, vous devez créer un site local avec des préfixes agrégés représentant à la fois le réseau virtuel connecté et l’espace d’adressage local. Ce site local représentatif est ensuite connecté au réseau virtuel pour obtenir une connectivité de transit. Le modèle classique présente aussi des défis comparables en matière de gestion, car les modifications apportées à la plage d’adresses locale doivent aussi être répercutées sur le site local représentant l’agrégat du réseau virtuel et de l’emplacement local. L’introduction de la prise en charge du protocole BGP dans les passerelles prises en charge par Resource Manager facilite la gestion dans la mesure où les passerelles connectées peuvent déterminer les itinéraires au niveau local sans modification manuelle des préfixes.

Sachant que nous transformons la connectivité de réseau virtuel à réseau virtuel sans nécessiter de sites locaux, le scénario de transit perd la connectivité locale pour le réseau virtuel qui est indirectement connecté en local. Les effets de la perte de connectivité peuvent être atténués des deux façons suivantes, une fois la migration terminée :

• Activation du protocole BGP sur les passerelles VPN qui sont connectées entre elles et en local. L’activation du protocole BGP a pour effet de restaurer la connectivité sans aucune autre modification de la configuration, car les itinéraires sont déterminés et annoncés entre les passerelles de réseau virtuel. Notez que l’option BGP est uniquement disponible sur les références (SKU) standard et supérieures.
• Établissement d’une connexion explicite du réseau virtuel concerné vers la passerelle de réseau local qui représente l’emplacement local. Cela passe aussi par la modification de la configuration du routeur local pour créer et configurer le tunnel IPsec.

Étapes suivantes

Maintenant que vous en savez plus sur la prise en charge de la migration de passerelle VPN, consultez Migration de ressources IaaS d’un environnement Classic vers Resource Manager pour bien démarrer.