FAQ sur la passerelle VPN

Connexion à des réseaux virtuels

Puis-je me connecter à des réseaux virtuels dans différentes régions Azure ?

Oui. Il n’y a aucune contrainte de région. Un réseau virtuel peut se connecter à un autre réseau virtuel dans la même région ou dans une autre région Azure.

Puis-je me connecter à des réseaux virtuels avec différents abonnements ?

Oui.

Puis-je spécifier des serveurs DNS privés dans mon réseau virtuel lors de la configuration d’une passerelle VPN ?

Si vous avez spécifié un ou des serveurs DNS quand vous avez créé votre réseau virtuel, la passerelle VPN utilise les serveurs DNS que vous avez spécifiés. Si vous spécifiez un serveur DNS, vérifiez que votre serveur DNS peut résoudre les noms de domaine nécessaires pour Azure.

Puis-je me connecter à plusieurs sites à partir d'un seul réseau virtuel ?

Vous pouvez vous connecter à plusieurs sites à l'aide de Windows PowerShell et des API REST Azure. Consultez la rubrique FAQ sur la Connectivité multisite et de réseau virtuel à réseau virtuel .

La configuration d’une passerelle VPN en mode actif-actif engendre-t-elle des coûts supplémentaires ?

Non. Cependant, les coûts des adresses IP publiques supplémentaires seront facturés en conséquence. Consultez Tarification des adresses IP.

Quelles sont mes options de connexion entre différents locaux ?

Les connexions de passerelle de réseau virtuel intersites suivantes sont pris en charge :

• Site à Site : connexion VPN sur IPsec (IKE v1 et IKE v2). Ce type de connexion requiert un périphérique VPN ou le service RRAS. Pour plus d’informations, consultez Site à site.
• Point à site : connexion VPN sur SSTP (Secure Socket Tunneling Protocol) ou IKE v2. Cette connexion ne nécessite pas de périphérique VPN. Pour plus d’informations, consultez Point à site.
• Réseau virtuel à réseau virtuel : ce type de connexion est identique à une configuration site à site. La connexion de réseau virtuel à réseau virtuel est une connexion VPN sur IPsec (IKE v1 et IKE v2). Elle ne nécessite pas de périphérique VPN. Pour plus d’informations, consultez Configurer une connexion de réseau virtuel à réseau virtuel à l’aide du portail Azure.
• ExpressRoute : ExpressRoute est une connexion privée à Azure à partir de votre WAN, pas une connexion VPN qui passe par l’Internet public. Pour plus d’informations, consultez Vue d’ensemble technique d’ExpressRoute et la FAQ ExpressRoute.

Pour plus d’informations sur les connexions de passerelle VPN, consultez À propos de la passerelle VPN.

Quelle est la différence entre une connexion site à site et point à site ?

Les configurations Site à site (tunnel VPN IPsec/IKE) se trouvent entre votre emplacement local et Azure. Elles vous permettent donc de vous connecter à partir de n’importe quel ordinateur se trouvant sur votre serveur local vers une machine virtuelle ou une instance de rôle au sein de votre réseau virtuel, selon le mode de configuration du routage et les autorisations que vous choisissez. Il s’agit d’une excellente solution pour une connexion entre différents locaux toujours disponibles et elle convient parfaitement aux configurations hybrides. Ce type de connexion s’appuie sur une appliance VPN IPsec (matériel ou application logicielle), qui doit être déployée à la périphérie de votre réseau. Pour créer ce type de connexion, vous devez disposer d’une adresse IPv4 externe.

Les configurations Point à site (VPN sur SSTP) vous permettent de vous connecter à partir d’un seul ordinateur à partir de n’importe quel emplacement et vers n’importe quel emplacement sur votre réseau virtuel. Ces connexions utilisent le client VPN fourni avec Windows. Dans le cadre de la configuration de point à site, vous installez un certificat et un package de configuration de client VPN contenant les paramètres qui permettent à votre ordinateur de se connecter à n'importe quelle machine virtuelle ou instance de rôle du réseau virtuel. Cela est très intéressant lorsque vous souhaitez vous connecter à un réseau virtuel mais que vous ne vous trouvez pas en local. Il s’agit également d’une solution intéressante lorsque vous n’avez pas accès à du matériel VPN ou à une adresse IPv4 externe, tous deux étant nécessaires à une connexion site à site.

Vous pouvez configurer votre réseau virtuel pour utiliser la connexion site à site et point à site simultanément, à condition de créer votre connexion site à site à l’aide d’un type de réseau privé virtuel basé sur une route pour votre passerelle. Les types de réseau privé virtuel basé sur un itinéraire sont appelés des passerelles dynamiques dans le modèle de déploiement classique.

Confidentialité

Le service VPN stocke-t-il ou traite-t-il les données client ?

Non.

Passerelles de réseau virtuel

Une passerelle VPN est-elle une passerelle de réseau virtuel ?

Une passerelle VPN est un type de passerelle de réseau virtuel. Une passerelle VPN envoie le trafic chiffré entre votre réseau virtuel et votre emplacement local à travers une connexion publique. Vous pouvez également utiliser une passerelle VPN pour acheminer le trafic entre réseaux virtuels. Lorsque vous créez une passerelle VPN, vous utilisez la valeur -GatewayType « Vpn ». Pour plus d’informations, consultez À propos des paramètres de configuration de la passerelle VPN.

Pourquoi ne puis-je pas spécifier de types de VPN basés sur des stratégies et basés sur des itinéraires ?

À la date du 1er octobre 2023, vous ne pouvez pas créer de passerelle VPN basée sur des stratégies via le portail Azure. Toutes les nouvelles passerelles VPN seront créées automatiquement en tant que passerelles basées sur des routes. Si vous disposez déjà d’une passerelle basée sur des stratégies, vous n’avez pas besoin de mettre à niveau votre passerelle vers une passerelle basée sur des routes. Vous pouvez utiliser PowerShell/CLI pour créer les passerelles basées sur des stratégies.

Auparavant, les anciennes références SKU de passerelle ne prenaient pas en charge IKEv1 pour les passerelles basées sur des routes. À présent, la plupart des références SKU de passerelle actuelles prennent en charge à la fois IKEv1 et IKEv2.

Type de VPN de la passerelle	SKU de la passerelle	Versions de IKE prises en charge
Passerelle basée sur des stratégies	Basic	IKEv1
Passerelle basée sur des itinéraires	Basic	IKEv2
Passerelle basée sur des itinéraires	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 et IKEv2
Passerelle basée sur des itinéraires	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 et IKEv2

Puis-je mettre à jour ma passerelle VPN basée sur une stratégie en passerelle VPN basée sur l’itinéraire ?

Non. Un type de passerelle ne peut pas être modifié du type basé sur une stratégie en celui basé sur une route, ou vice versa. Pour modifier un type de passerelle, la passerelle doit être supprimée et recréée. Ce processus prend environ 60 minutes. Lorsque vous créez la nouvelle passerelle, vous ne pouvez pas conserver l’adresse IP de la passerelle d’origine.

1. Supprimez toutes les connexions associées à la passerelle.

2. Supprimez la passerelle en utilisant l’un des articles suivants :

   • Azure portal
   • Azure PowerShell
   • Azure PowerShell - Classic

3. Créez une nouvelle passerelle en utilisant le type de passerelle de votre choix, puis terminez la configuration du VPN. Pour connaître les étapes, consultez le tutoriel Site à Site.

Puis-je spécifier mes propres sélecteurs de trafic basés sur des stratégies ?

Oui, les sélecteurs de trafic peuvent être définis par l'attribut trafficSelectorPolicies sur une connexion via la commande PowerShell New-AzIpsecTrafficSelectorPolicy. Pour que le sélecteur de trafic spécifié prenne effet, vérifiez que l'option Utiliser des sélecteurs de trafic basés sur des stratégies est activée.

Les sélecteurs de trafic personnalisés configurés sont proposés uniquement lorsqu’une passerelle VPN Azure lance la connexion. Une passerelle VPN accepte tous les sélecteurs de trafic proposés par une passerelle distante (appareil VPN local). Ce comportement est cohérent entre tous les modes de connexion (Default, InitiatorOnly et ResponderOnly).

Ai-je besoin d’un « sous-réseau de passerelle » ?

Oui. Le sous-réseau de passerelle contient les adresses IP utilisées par les services de passerelle de réseau virtuel. Vous devez créer un sous-réseau de passerelle pour votre réseau virtuel afin de configurer une passerelle de réseau virtuel. Tous les sous-réseaux de passerelle doivent être nommés « GatewaySubnet » afin de fonctionner correctement. N’attribuez pas un autre nom au sous-réseau de passerelle, et ne déployez pas de machines virtuelles ou d’autres éléments vers le sous-réseau de passerelle.

Lorsque vous créez le sous-réseau de passerelle, vous spécifiez le nombre d’adresses IP que contient le sous-réseau. Les adresses IP dans le sous-réseau de passerelle sont allouées au service de passerelle. Certaines configurations nécessitent d’allouer davantage d’adresses IP aux services de passerelle. Assurez-vous que votre sous-réseau de passerelle contient suffisamment d’adresses IP pour pouvoir évoluer au rythme de votre croissance future et prendre en charge d’éventuelles nouvelles configurations de connexion. Bien qu’il soit possible de créer un sous-réseau de passerelle aussi petit que /29, nous vous recommandons de créer un sous-réseau de passerelle de taille /27 ou supérieure (/27, /26, /25, etc.). Prenez connaissance des recommandations relatives à la configuration que vous souhaitez créer et vérifiez que votre sous-réseau de passerelle suit ces recommandations.

Puis-je déployer des machines virtuelles ou des instances de rôle vers mon sous-réseau de passerelle ?

Non.

Puis-je obtenir mon adresse IP de passerelle VPN avant de la créer ?

Les ressources IP publiques de référence SKU Standard Azure doivent utiliser une méthode d’allocation statique. Ainsi, vous disposez de l’adresse IP publique de votre passerelle VPN dès que vous créez la ressource IP publique de référence SKU Standard que vous prévoyez d’utiliser pour celle-ci.

Puis-je demander une adresse IP publique statique pour ma passerelle VPN ?

Les ressources d'adresses IP publiques standard de SKU utilisent une méthode d'attribution statique. Vous devez désormais utiliser une IP publique de la référence SKU Standard lorsque vous créez une passerelle VPN. Cela s’applique à toutes les références SKU de passerelle, à l’exception de la référence SKU Essentiel. Le SKU de base de la passerelle ne prend actuellement en charge que des adresses IP publiques du SKU de base. Nous allons bientôt ajouter la prise en charge des adresses IP publiques de SKU Standard pour les références SKU de passerelle de base.

Pour les passerelles non zonales et non redondantes interzone créées précédemment (références SKU de passerelle sansAZ dans leur nom), l’attribution d’adresse IP dynamique est prise en charge, mais est progressivement supprimée. Lorsque vous utilisez une adresse IP dynamique, l’adresse IP ne change pas une fois qu’elle a été affectée à votre passerelle VPN. L’adresse IP de la passerelle VPN change uniquement lorsque la passerelle est supprimée, puis recréée. L’adresse IP publique de la passerelle VPN ne change pas lors du redimensionnement, de la réinitialisation ou des autres opérations de maintenance/mise à niveau internes de votre passerelle VPN.

Comment la mise hors service de la référence SKU De base de l’adresse IP publique affecte-t-elle mes passerelles VPN ?

Nous prenons des mesures pour garantir le fonctionnement continu des passerelles VPN déployées qui utilisent des adresses IP publiques de référence SKU de base. Si vous avez déjà des passerelles VPN avec des adresses IP publiques de référence SKU de base, vous n’avez rien besoin de faire.

Toutefois, il est important de noter que les IP publiques de la référence SKU Essentiel sont progressivement supprimées. Quand vous créez une passerelle VPN, vous devez désormais utiliser l’IP publique de la référence SKU Standard. Vous trouverez plus d’informations sur la suppression des adresses IP publiques de référence SKU de base ici.

Comment mon tunnel VPN est-il authentifié ?

Azure VPN utilise l'authentification PSK (clé prépartagée). Nous générons une clé prépartagée (PSK) lorsque nous créons le tunnel VPN. Vous pouvez modifier la PSK générée automatiquement pour votre VPN avec la cmdlet PowerShell ou l’API REST de clé prépartagée définie.

Puis-je utiliser l’API de clé prépartagée définie pour configurer ma passerelle VPN basée sur des itinéraires (routage statique) ?

Oui, l’applet de commande PowerShell et l’API de clé prépartagée définie permettent de configurer des réseaux VPN Azure basés sur des stratégies (statiques) et des réseaux VPN basés sur des itinéraires (dynamiques).

Puis-je utiliser les autres options d'authentification ?

Nous sommes limités à l’utilisation de clés prépartagées (PSK) pour l’authentification.

Comment puis-je indiquer quel trafic traverse la passerelle VPN ?

Modèle de déploiement de Resource Manager

• PowerShell : utilisez le paramètre « AddressPrefix » pour spécifier le trafic de la passerelle réseau locale.
• Portail Azure : Accédez à la passerelle de réseau local > Configuration > Espace d’adressage.

Modèle de déploiement classique

• Portail Azure : Accédez au réseau virtuel classique > Connexions VPN > Connexions VPN site à site > Nom du site local > Site local > Espace d’adressage du client.

Puis-je utiliser NAT-T sur mes connexions VPN ?

Oui, NAT Traversal (NAT-T) est pris en charge. La passerelle VPN Azure n’effectue AUCUNE fonctionnalité de type NAT sur les paquets internes vers/à partir des tunnels IPsec. Dans cette configuration, vérifiez que l’appareil local lance le tunnel IPSec.

Puis-je configurer mon propre serveur VPN dans Azure et l’utiliser pour me connecter à mon réseau local ?

Oui, vous pouvez déployer vos propres serveurs ou passerelles VPN dans Azure depuis Azure Marketplace ou en créant vos propres routeurs VPN. Vous devez configurer des routes définies par l’utilisateur dans votre réseau virtuel pour vous assurer que le trafic est routé correctement entre vos réseaux locaux et les sous-réseaux de votre réseau virtuel.

Pourquoi certains ports sont-ils ouverts sur ma passerelle de réseau virtuel ?

Ils sont nécessaires pour la communication avec l’infrastructure Azure. Ils sont protégés (verrouillés) par des certificats Azure. Sans les certificats appropriés, les entités externes (notamment les clients de ces passerelles) ne pourront avoir aucun effet sur ces points de terminaison.

Une passerelle de réseau virtuel est, fondamentalement, un périphérique multirésident avec une carte réseau qui exploite le réseau privé du client et une autre carte réseau connectée au réseau public. Les entités de l’infrastructure Azure ne peuvent pas se connecter aux réseaux privés des clients pour des raisons de conformité. Elles doivent donc utiliser des points de terminaison publics pour la communication avec l’infrastructure. Les points de terminaison publics sont analysés régulièrement par l’audit de sécurité Azure.

Puis-je créer une passerelle VPN avec la référence SKU de base de la passerelle dans le portail ?

Nombre La référence SKU de base n’est pas disponible dans le portail. Vous pouvez créer une passerelle VPN avec la référence SKU de base à l’aide d’Azure CLI ou de PowerShell.

Où puis-je trouver des informations sur les types de passerelles, les spécifications et le débit ?

Voir les articles suivants :

• À propos des paramètres de configuration de la passerelle VPN
• À propos des références SKU de passerelle

Utilisation déconseillée des références SKU héritées

Les références SKU Standard et Haute performance seront dépréciées le 30 septembre 2025. Vous pouvez consulter l’annonce ici. L’équipe produit mettra à disposition un chemin de migration pour ces références SKU d’ici le 30 novembre 2024. Pour plus d’informations, consultez l’article Références SKU héritées de passerelle VPN. Pour le moment, vous n’avez aucune action à effectuer.

Pourrai-je créer une référence SKU Standard/Hautes performances, une fois que leur utilisation aura été déconseillée à partir du 30 novembre 2023 ?

Non. À partir du 1er décembre 2023, vous ne pourrez plus créer de passerelles avec des références SKU Standard ou Hautes performances. Vous pourrez créer des passerelles à l’aide de VpnGw1 et VpnGw2 pour le même prix que les références SKU Standard et Hautes performances, listées respectivement sur notre page des tarifs.

Combien de temps mes passerelles existantes seront-elles prises en charge sur les références SKU Standard/Hautes performances ?

Toutes les passerelles existantes utilisant des références SKU Standard ou Hautes performances seront prises en charge jusqu’au 30 septembre 2025.

Dois-je migrer mes références SKU de passerelle Standard/Hautes performances tout de suite ?

Non, aucune action n’est nécessaire pour le moment. Vous pourrez migrer vos références SKU à partir de décembre 2024. Nous vous enverrons une communication avec une documentation détaillée sur les étapes de migration.

Vers quelle référence SKU puis-je migrer ma passerelle ?

Quand la migration des références SKU de passerelle sera disponible, vous pourrez migrer les références SKU de la façon suivante :

• Standard -> VpnGw1
• Hautes performances -> VpnGw2

Que se passe-t-il si je souhaite migrer vers une référence SKU AZ ?

Vous ne pouvez pas migrer votre référence SKU héritée vers une référence SKU AZ. Toutefois, notez que toutes les passerelles qui utiliseront encore des références SKU Standard ou Hautes performances après le 30 septembre 2025 seront migrées et mises à niveau automatiquement vers les références SKU suivantes :

• Standard -> VpnGw1AZ
• Hautes performances -> VpnGw2AZ

Vous pouvez utiliser cette stratégie pour migrer et mettre à niveau automatiquement vos références SKU vers une référence SKU AZ. Vous pourrez ensuite redimensionner votre référence SKU au sein de cette famille de références SKU, si nécessaire. Consultez notre page des tarifs pour connaître les tarifs des références SKU AZ. Pour plus d’informations sur le débit par référence SKU, consultez À propos des références SKU de passerelle.

Est-ce qu’il y aura une différence de tarif pour mes passerelles après la migration ?

Si vous migrez vos références SKU d’ici le 30 septembre 2025, il n’y aura aucune différence de tarif. Les références SKU VpnGw1 et VpnGw2 sont proposées au même prix que les références SKU Standard et Hautes performances, respectivement. Si vous n’effectuez pas la migration d’ici cette date, vos références SKU seront automatiquement migrées et mises à niveau vers des références SKU AZ. Dans ce cas, il y aura une différence de prix.

Cette migration aura-t-elle un impact sur les performances de mes passerelles ?

Oui, vous obtiendrez de meilleures performances avec VpnGw1 et VpnGw2. VpnGw1 à 650 Mbit/s fournit un débit x6,5, et VpnGw2 à 1 Gbit/s permet d’améliorer les performances x5 au même prix que les passerelles Standard et Hautes performances héritées, respectivement. Pour plus d’informations sur le débit par référence SKU, consultez À propos des références SKU de passerelle.

Que se passe-t-il si je ne migre pas les références SKU d’ici le 30 septembre 2025 ?

Toutes les passerelles qui utiliseront encore des références SKU Standard ou Hautes performances seront migrées et mises à niveau automatiquement vers les références SKU AZ suivantes :

• Standard -> VpnGw1AZ
• Hautes performances -> VpnGw2AZ

Une annonce finale sera communiquée avant le lancement de la migration sur les passerelles.

La référence SKU De base de la passerelle VPN va-t-elle également être mise hors service ?

Non, la référence SKU De base de la passerelle VPN est là pour durer. Vous pouvez créer une passerelle VPN à l’aide de la référence SKU de passerelle De base par PowerShell ou l’interface CLI. Actuellement, les références SKU de la passerelle De base de la passerelle VPN prennent uniquement en charge la ressource d’adresse IP publique de la référence SKU De base (qui est en voie de mise hors service). Nous travaillons à l’ajout de la prise en charge de la référence SKU de passerelle VPN De base pour la ressource d’adresse IP publique de la référence SKU Standard.

Connexions site à site et périphériques VPN

Que dois-je prendre en compte lors de la sélection d'un périphérique VPN ?

Nous avons validé un ensemble de périphériques VPN site à site standard en partenariat avec des fournisseurs de périphériques. Vous trouverez une liste de périphériques VPN compatibles, leurs instructions de configuration correspondantes ou des exemples, ainsi que les caractéristiques du périphérique dans l’article À propos des périphériques VPN et des paramètres IPsec/IKE pour les connexions de passerelle VPN site à site. Tous les périphériques des familles de périphériques répertoriées et reconnus comme compatibles doivent fonctionner avec Virtual Network. Pour aider à configurer votre périphérique VPN, reportez-vous à l'exemple de configuration de périphérique ou au lien qui correspond à la famille de périphériques appropriée.

Où puis-je trouver les paramètres de configuration des périphériques VPN ?

Pour télécharger des script de configuration de périphérique VPN :

En fonction du périphérique VPN dont vous disposez, vous pourrez peut-être télécharger un script de configuration de périphérique VPN. Pour plus d’informations, consultez la page Télécharger des script de configuration de périphérique VPN.

Pour plus d’informations sur la configuration, consultez les liens suivants :

• Pour plus d’informations sur les périphériques VPN compatibles, consultez la page Périphériques VPN.

• Avant de configurer votre périphérique VPN, identifiez également les éventuels Problèmes de compatibilité connus avec le matériel pour le périphérique VPN que vous souhaitez utiliser.

• Vous trouverez des liens vers les paramètres de configuration des périphériques sur la page Périphériques VPN validés. Les liens de configuration des périphériques sont fournis dans la mesure du possible. Il est toujours préférable de vérifier les dernières informations de configuration auprès du fabricant du périphérique. La liste répertorie les versions que nous avons testées. L’absence de votre système d’exploitation de cette liste n’exclut pas sa compatibilité. Pour savoir si la version du système d’exploitation de votre périphérique VPN est compatible, renseignez-vous auprès du fabricant de ce périphérique.

• Pour une vue d’ensemble de la configuration du périphérique VPN, consultez Vue d’ensemble de la configuration de périphériques VPN.

• Pour plus d’informations sur la modification des exemples de configuration des périphériques, consultez la page Modifier les exemples.

• Pour les exigences de chiffrement, consultez sur les exigences de chiffrement et les passerelles VPN Azure.

• Pour en savoir plus sur les paramètres IPsec/IKE, consultez À propos des périphériques VPN et des paramètres IPsec/IKE pour les connexions de passerelle VPN site à site. Cette section contient des informations sur la version IKE version, le groupe Diffie-Hellman, la méthode d’authentification, les algorithmes de chiffrement et de hachage, la durée de vie de l’association de sécurité, le paramètre PFS et la détection d’homologue mort, ainsi que des informations sur les autres paramètres dont vous avez besoin pour effectuer votre configuration.

• Pour les étapes de configuration de stratégie IPsec/IKE, consultez Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections (Configurer la stratégie IPsec/IKE pour les connexions VNet-à-VNet ou VPN S2S.

• Pour connecter plusieurs périphériques VPN basés sur des stratégies, consultez Connecter des passerelles VPN à plusieurs périphériques VPN basés sur des stratégies via PowerShell.

Comment dois-je modifier les exemples de configuration de périphérique VPN ?

Pour plus d’informations sur la modification des exemples de configuration des périphériques, consultez la page Modifier les exemples.

Où puis-je trouver les paramètres IPsec et IKE ?

En ce qui concerne les paramètres IPsec/IKE, consultez la page Paramètres.

Pourquoi mon tunnel VPN basé sur une stratégie tombe-t-il en panne lorsque le trafic est inactif ?

Il s’agit du comportement attendu pour les passerelles VPN basées sur une stratégie (également appelé routage statique). Lorsque le trafic via le tunnel est inactif pendant plus de 5 minutes, le tunnel est détruit. Lorsque le trafic recommence à circuler dans les deux sens, le tunnel est immédiatement rétabli.

Puis-je utiliser le logiciel des VPN logiciels pour me connecter à Azure ?

Nous prenons en charge les serveurs de routage et d'accès à distance (RRAS) Windows Server 2012 pour la configuration entre locaux de site à site.

D’autres solutions VPN logicielles fonctionnent avec notre passerelle tant qu'elles sont conformes aux implémentations IPsec standard. Contactez le fournisseur du logiciel pour obtenir des instructions de configuration et de prise en charge.

Puis-je me connecter à une passerelle VPN via une connexion point à site sur un site disposant d’une connexion site à site active ?

Oui, mais les adresses IP publiques du client point à site doivent être différentes de celles utilisées par le périphérique VPN site à site. Dans le cas contraire, la connexion point à site ne fonctionnera pas. Les connexions point à site avec IKEv2 ne peuvent pas être lancées à partir des mêmes adresses IP publiques où une connexion VPN site à site est configurée sur la même passerelle VPN Azure.

Point à site : authentification par certificat

Cette section s’applique au modèle de déploiement Resource Manager.

De combien de points de terminaison de client VPN pouvez-vous disposer dans votre configuration de point à site ?

Cela dépend de la référence SKU de passerelle. Pour plus d’informations sur le nombre de connexions prises en charge, consultez Références SKU de passerelle.

Quels systèmes d’exploitation clients puis-je utiliser avec une connexion point à site ?

Les systèmes d’exploitation clients pris en charge sont les suivants :

• Windows Server 2008 R2 (64 bits uniquement)
• Windows 8.1 (32 bits et 64 bits)
• Windows Server 2012 (64 bits uniquement)
• Windows Server 2012 R2 (64 bits uniquement)
• Windows Server 2016 (64 bits uniquement)
• Windows Server 2019 (64 bits uniquement)
• Windows Server 2022 (64 bits uniquement)
• Windows 10
• Windows 11
• macOS version 10.11 ou supérieure
• Linux (StrongSwan)
• iOS

Pouvez-vous parcourir les proxys et les pare-feu à l'aide de la fonction point à site ?

Azure prend en charge trois types d’options de VPN point à site :

• Protocole SSTP (Secure Socket Tunneling Protocol). SSTP est une solution SSL propriétaire de Microsoft qui peut pénétrer les pare-feu, car la plupart des pare-feu ouvrent le port TCP 443 sortant utilisé par SSL.

• OpenVPN. OpenVPN est une solution SSL qui peut pénétrer les pare-feu, car la plupart des pare-feu ouvrent le port TCP 443 sortant utilisé par SSL.

• VPN IKEv2. Le VPN IKEv2 est une solution VPN IPsec basée sur des normes qui utilise les ports UDP 500 et 4500 sortants ainsi que le protocole IP no 50. Les pare-feu n’ouvrent pas toujours ces ports. Il est donc possible que le VPN IKEv2 ne soit pas en mesure de parcourir les proxies et pare-feu.

Si vous redémarrez un ordinateur client configuré pour la connectivité de point à site, le VPN va-t-il se reconnecter automatiquement ?

La reconnexion automatique est une fonction du client utilisé. Windows prend en charge la reconnexion automatique en configurant la fonctionnalité du client Always On VPN.

Les connexions point à site prennent-elles en charge DDNS sur les clients VPN ?

DDNS n’est actuellement pas pris en charge dans les VPN point à site.

Puis-je avoir des configurations coexistantes site à site et point à site pour un même réseau virtuel ?

Oui. Pour le modèle de déploiement Resource Manager, vous devez disposer d’un type de VPN basé sur le routage pour votre passerelle. Pour le modèle de déploiement Classic, vous avez besoin d’une passerelle dynamique. Nous ne prenons pas en charge la configuration point à site pour les passerelles VPN à routage statique ou les passerelles VPN basée sur une stratégie.

Puis-je configurer un client point à site pour me connecter à plusieurs passerelles de réseaux virtuels en même temps ?

En fonction du logiciel VPN Client utilisé, vous pouvez vous connecter à plusieurs passerelles de réseaux virtuels, à condition que les réseaux virtuels qui y sont connectés n’aient pas d’espaces d’adressage en conflit entre eux ou avec le réseau à partir duquel le client se connecte. Azure VPN Client prend en charge de nombreuses connexions VPN, mais une seule connexion peut être connectée à un moment M.

Pouvez-vous configurer un client de point à site pour la connexion à plusieurs réseaux virtuels en même temps ?

Oui, les connexions client point à site à une passerelle de réseau virtuel déployée dans un réseau virtuel appairé à d’autres réseaux virtuels peuvent avoir accès à d’autres réseaux virtuels appairés. Les clients point à site sont en mesure de se connecter à des réseaux virtuels appairés tant que ceux-ci utilisent les fonctionnalités UseRemoteGateway/AllowGatewayTransit. Pour plus d’informations, consultez À propos du routage point à site.

Quel débit puis-je attendre des connexions site à site ou point à site ?

Il est difficile de maintenir le débit exact des tunnels VPN. IPsec et SSTP sont des protocoles VPN de chiffrement lourd. Le débit est également limité par la latence et la bande passante entre vos locaux et Internet. Pour une passerelle VPN ne disposant que des connexions VPN point à site IKEv2, le débit total que vous obtiendrez dépendra de la référence SKU de passerelle. Pour plus d’informations sur le débit, consultez Références SKU de passerelle.

Puis-je utiliser un client VPN logiciel pour une connexion point à site prenant en charge SSTP et/ou IKEv2 ?

Non. Vous ne pouvez utiliser le client VPN natif sur Windows que pour SSTP et pour le client VPN natif sur Mac pour IKEv2. Toutefois, vous pouvez utiliser le client OpenVPN sur toutes les plateformes pour vous connecter via le protocole OpenVPN. Consultez la liste des systèmes d’exploitation client pris en charge.

Puis-je modifier le type d’authentification pour une connexion point à site ?

Oui. Dans le portail, accédez à la page Passerelle VPN -> Configuration point à site. Pour Type d’authentification, sélectionnez les types d’authentification à utiliser. Notez qu’une fois que vous avez modifié un type d’authentification, il se peut que des clients actuels ne puissent pas se connecter tant qu’un nouveau profil de configuration de client VPN n’a pas été généré, téléchargé et appliqué à chaque client VPN.

Azure prend-elle en charge le VPN IKEv2 avec Windows ?

Le protocole IKEv2 est pris en charge sur Windows 10 et Server 2016. Toutefois, pour pouvoir utiliser le protocole IKEv2 dans certaines versions de système d’exploitation, vous devez installer les mises à jour et définir une valeur de clé de Registre localement. Les versions de système d’exploitation antérieures à Windows 10 ne sont pas prises en charge. Elles peuvent uniquement utiliser le protocole SSTP ou OpenVPN®.

Notes

Ces étapes ne sont pas nécessaires dans les builds de système d’exploitation Windows ultérieures à Windows 10 version 1709 et Windows Server 2016 version 1607.

Pour préparer Windows 10 ou Server 2016 pour IKEv2 :

1. Installez la mise à jour en fonction de la version de votre système d’exploitation :

   Version du SE	Date	Nombre/lien
   Windows Server 2016 Windows 10 version 1607	17 janvier 2018	KB4057142
   Windows 10 version 1703	17 janvier 2018	KB4057144
   Windows 10 version 1709	22 mars 2018	KB4089848

2. Définissez la valeur de clé de Registre. Créer ou de définir la clé REG_DWORD « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload » sur 1 dans le Registre.

Quelle est la limite du sélecteur de trafic IKEv2 pour les connexions point à site ?

Windows 10 version 2004 (publié en septembre 2021) a augmenté la limite de sélecteur de trafic à 255. Les versions antérieures de Windows ont une limite de sélecteur de trafic de 25.

La limite de sélecteurs de trafic dans Windows détermine le nombre maximal d’espaces d’adressage dans votre réseau virtuel et la somme maximale de vos réseaux locaux, connexions VNet-à-VNet et réseaux VNet appairés connectés à la passerelle. Les clients Windows point à site ne pourront pas se connecter via IKEv2 s’ils dépassent cette limite.

Que se passe-t-il lorsque je configure SSTP et IKEv2 pour les connexions VPN P2S ?

Lorsque vous configurez SSTP et IKEv2 dans un environnement mixte (composé d’appareils Windows et Mac), le client VPN Windows essaiera toujours le tunnel IKEv2 d’abord, mais il reviendra à SSTP si la connexion IKEv2 n’a pas abouti. MacOSX se connecte uniquement via le protocole IKEv2.

Lorsque SSTP et IKEv2 sont activés sur la passerelle, le pool d’adresses point à site est divisé statiquement entre les deux, de sorte que les clients utilisant des protocoles différents se voient attribuer des adresses IP de l’une ou l’autre sous-plage. Notez que la quantité maximale de clients SSTP est toujours de 128, même si la plage d’adresses est supérieure à /24, ce qui entraîne une plus grande quantité d’adresses disponibles pour les clients IKEv2. Pour les plages plus petites, le pool sera divisé par deux de manière égale. Les sélecteurs de trafic utilisés par la passerelle ne peuvent pas inclure le routage CIDR de la plage d’adresses point à site, uniquement les deux routages CIDR de sous-plage.

À part Windows et Mac, quelles autres plateformes sont prises en charge par Azure pour le réseau VPN P2S ?

Azure prend en charge Windows, Mac et Linux pour les VPN point à site (P2S).

J’ai déjà une passerelle VPN Azure déployée. Puis-je activer RADIUS et/ou le réseau VPN IKEv2 sur celle-ci ?

Oui, si la référence (SKU) de passerelle que vous utilisez prend en charge RADIUS ou IKEv2, vous pouvez activer ces fonctionnalités sur des passerelles que vous avez déjà déployées à l’aide de PowerShell ou du portail Azure. La référence (SKU) De base ne prend en charge ni RADIUS, ni IKEv2.

Comment supprimer la configuration d’une connexion P2S ?

Vous pouvez supprimer une configuration P2S avec Azure CLI et PowerShell en utilisant les commandes suivantes :

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Que dois-je faire si j’obtiens une incompatibilité de certificat lors de la connexion à l’aide de l’authentification par certificat ?

Décochez « Vérifier l’identité du serveur en validant le certificat », ou ajoutez le nom de domaine complet du serveur avec le certificat lors de la création manuelle d’un profil. Pour ce faire, exécutez rasphone à partir d’une invite de commandes et choisissez le profil dans la liste déroulante.

Ignorer la validation de l’identité du serveur n’est pas recommandé en général, mais avec l’authentification par certificat Azure, le même certificat est utilisé pour la validation du serveur dans le protocole de tunneling VPN (IKEv2/SSTP) et le protocole EAP. Étant donné que le certificat de serveur et le nom de domaine complet sont déjà validés par le protocole de tunneling VPN, il est redondant de les valider de nouveau dans EAP.

Puis-je utiliser ma propre AC racine PKI interne pour générer des certificats pour une connectivité point à site ?

Oui. Auparavant, seuls les certificats racines auto-signés pouvaient être utilisés. Vous pouvez toujours charger 20 certificats racine.

Puis-je utiliser des certificats Azure Key Vault ?

Non.

Quels outils puis-je utiliser pour créer des certificats ?

Vous pouvez utiliser votre solution de PKI d’entreprise (votre PKI interne), Azure PowerShell, MakeCert et OpenSSL.

Y a-t-il des instructions pour les paramètres de certificat ?

• PKI interne/Solution PKI d’entreprise : reportez-vous aux étapes de génération des certificats.

• Azure PowerShell : consultez l’article Azure PowerShell pour connaître la procédure.

• MakeCert : consultez l’article MakeCert pour connaître la procédure.

• OpenSSL :

  • Lors de l’exportation de certificats, veillez à convertir le certificat racine en Base64.

  • Pour le certificat client :

    • Lorsque vous créez la clé privée, spécifiez la longueur 4096.
    • Lors de la création du certificat, pour le paramètre -extensions, spécifiez usr_cert.

Point à site : authentification RADIUS

Cette section s’applique au modèle de déploiement Resource Manager.

De combien de points de terminaison de client VPN pouvez-vous disposer dans votre configuration de point à site ?

Cela dépend de la référence SKU de passerelle. Pour plus d’informations sur le nombre de connexions prises en charge, consultez Références SKU de passerelle.

Quels systèmes d’exploitation clients puis-je utiliser avec une connexion point à site ?

Les systèmes d’exploitation clients pris en charge sont les suivants :

• Windows Server 2008 R2 (64 bits uniquement)
• Windows 8.1 (32 bits et 64 bits)
• Windows Server 2012 (64 bits uniquement)
• Windows Server 2012 R2 (64 bits uniquement)
• Windows Server 2016 (64 bits uniquement)
• Windows Server 2019 (64 bits uniquement)
• Windows Server 2022 (64 bits uniquement)
• Windows 10
• Windows 11
• macOS version 10.11 ou supérieure
• Linux (StrongSwan)
• iOS

Pouvez-vous parcourir les proxys et les pare-feu à l'aide de la fonction point à site ?

Azure prend en charge trois types d’options de VPN point à site :

• Protocole SSTP (Secure Socket Tunneling Protocol). SSTP est une solution SSL propriétaire de Microsoft qui peut pénétrer les pare-feu, car la plupart des pare-feu ouvrent le port TCP 443 sortant utilisé par SSL.

• OpenVPN. OpenVPN est une solution SSL qui peut pénétrer les pare-feu, car la plupart des pare-feu ouvrent le port TCP 443 sortant utilisé par SSL.

• VPN IKEv2. Le VPN IKEv2 est une solution VPN IPsec basée sur des normes qui utilise les ports UDP 500 et 4500 sortants ainsi que le protocole IP no 50. Les pare-feu n’ouvrent pas toujours ces ports. Il est donc possible que le VPN IKEv2 ne soit pas en mesure de parcourir les proxies et pare-feu.

Si vous redémarrez un ordinateur client configuré pour la connectivité de point à site, le VPN va-t-il se reconnecter automatiquement ?

La reconnexion automatique est une fonction du client utilisé. Windows prend en charge la reconnexion automatique en configurant la fonctionnalité du client Always On VPN.

Les connexions point à site prennent-elles en charge DDNS sur les clients VPN ?

DDNS n’est actuellement pas pris en charge dans les VPN point à site.

Puis-je avoir des configurations coexistantes site à site et point à site pour un même réseau virtuel ?

Oui. Pour le modèle de déploiement Resource Manager, vous devez disposer d’un type de VPN basé sur le routage pour votre passerelle. Pour le modèle de déploiement Classic, vous avez besoin d’une passerelle dynamique. Nous ne prenons pas en charge la configuration point à site pour les passerelles VPN à routage statique ou les passerelles VPN basée sur une stratégie.

Puis-je configurer un client point à site pour me connecter à plusieurs passerelles de réseaux virtuels en même temps ?

En fonction du logiciel VPN Client utilisé, vous pouvez vous connecter à plusieurs passerelles de réseaux virtuels, à condition que les réseaux virtuels qui y sont connectés n’aient pas d’espaces d’adressage en conflit entre eux ou avec le réseau à partir duquel le client se connecte. Azure VPN Client prend en charge de nombreuses connexions VPN, mais une seule connexion peut être connectée à un moment M.

Pouvez-vous configurer un client de point à site pour la connexion à plusieurs réseaux virtuels en même temps ?

Oui, les connexions client point à site à une passerelle de réseau virtuel déployée dans un réseau virtuel appairé à d’autres réseaux virtuels peuvent avoir accès à d’autres réseaux virtuels appairés. Les clients point à site sont en mesure de se connecter à des réseaux virtuels appairés tant que ceux-ci utilisent les fonctionnalités UseRemoteGateway/AllowGatewayTransit. Pour plus d’informations, consultez À propos du routage point à site.

Quel débit puis-je attendre des connexions site à site ou point à site ?

Il est difficile de maintenir le débit exact des tunnels VPN. IPsec et SSTP sont des protocoles VPN de chiffrement lourd. Le débit est également limité par la latence et la bande passante entre vos locaux et Internet. Pour une passerelle VPN ne disposant que des connexions VPN point à site IKEv2, le débit total que vous obtiendrez dépendra de la référence SKU de passerelle. Pour plus d’informations sur le débit, consultez Références SKU de passerelle.

Puis-je utiliser un client VPN logiciel pour une connexion point à site prenant en charge SSTP et/ou IKEv2 ?

Non. Vous ne pouvez utiliser le client VPN natif sur Windows que pour SSTP et pour le client VPN natif sur Mac pour IKEv2. Toutefois, vous pouvez utiliser le client OpenVPN sur toutes les plateformes pour vous connecter via le protocole OpenVPN. Consultez la liste des systèmes d’exploitation client pris en charge.

Puis-je modifier le type d’authentification pour une connexion point à site ?

Oui. Dans le portail, accédez à la page Passerelle VPN -> Configuration point à site. Pour Type d’authentification, sélectionnez les types d’authentification à utiliser. Notez qu’une fois que vous avez modifié un type d’authentification, il se peut que des clients actuels ne puissent pas se connecter tant qu’un nouveau profil de configuration de client VPN n’a pas été généré, téléchargé et appliqué à chaque client VPN.

Azure prend-elle en charge le VPN IKEv2 avec Windows ?

Le protocole IKEv2 est pris en charge sur Windows 10 et Server 2016. Toutefois, pour pouvoir utiliser le protocole IKEv2 dans certaines versions de système d’exploitation, vous devez installer les mises à jour et définir une valeur de clé de Registre localement. Les versions de système d’exploitation antérieures à Windows 10 ne sont pas prises en charge. Elles peuvent uniquement utiliser le protocole SSTP ou OpenVPN®.

Notes

Ces étapes ne sont pas nécessaires dans les builds de système d’exploitation Windows ultérieures à Windows 10 version 1709 et Windows Server 2016 version 1607.

Pour préparer Windows 10 ou Server 2016 pour IKEv2 :

1. Installez la mise à jour en fonction de la version de votre système d’exploitation :

   Version du SE	Date	Nombre/lien
   Windows Server 2016 Windows 10 version 1607	17 janvier 2018	KB4057142
   Windows 10 version 1703	17 janvier 2018	KB4057144
   Windows 10 version 1709	22 mars 2018	KB4089848

2. Définissez la valeur de clé de Registre. Créer ou de définir la clé REG_DWORD « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload » sur 1 dans le Registre.

Quelle est la limite du sélecteur de trafic IKEv2 pour les connexions point à site ?

Windows 10 version 2004 (publié en septembre 2021) a augmenté la limite de sélecteur de trafic à 255. Les versions antérieures de Windows ont une limite de sélecteur de trafic de 25.

La limite de sélecteurs de trafic dans Windows détermine le nombre maximal d’espaces d’adressage dans votre réseau virtuel et la somme maximale de vos réseaux locaux, connexions VNet-à-VNet et réseaux VNet appairés connectés à la passerelle. Les clients Windows point à site ne pourront pas se connecter via IKEv2 s’ils dépassent cette limite.

Que se passe-t-il lorsque je configure SSTP et IKEv2 pour les connexions VPN P2S ?

Lorsque vous configurez SSTP et IKEv2 dans un environnement mixte (composé d’appareils Windows et Mac), le client VPN Windows essaiera toujours le tunnel IKEv2 d’abord, mais il reviendra à SSTP si la connexion IKEv2 n’a pas abouti. MacOSX se connecte uniquement via le protocole IKEv2.

Lorsque SSTP et IKEv2 sont activés sur la passerelle, le pool d’adresses point à site est divisé statiquement entre les deux, de sorte que les clients utilisant des protocoles différents se voient attribuer des adresses IP de l’une ou l’autre sous-plage. Notez que la quantité maximale de clients SSTP est toujours de 128, même si la plage d’adresses est supérieure à /24, ce qui entraîne une plus grande quantité d’adresses disponibles pour les clients IKEv2. Pour les plages plus petites, le pool sera divisé par deux de manière égale. Les sélecteurs de trafic utilisés par la passerelle ne peuvent pas inclure le routage CIDR de la plage d’adresses point à site, uniquement les deux routages CIDR de sous-plage.

À part Windows et Mac, quelles autres plateformes sont prises en charge par Azure pour le réseau VPN P2S ?

Azure prend en charge Windows, Mac et Linux pour les VPN point à site (P2S).

J’ai déjà une passerelle VPN Azure déployée. Puis-je activer RADIUS et/ou le réseau VPN IKEv2 sur celle-ci ?

Oui, si la référence (SKU) de passerelle que vous utilisez prend en charge RADIUS ou IKEv2, vous pouvez activer ces fonctionnalités sur des passerelles que vous avez déjà déployées à l’aide de PowerShell ou du portail Azure. La référence (SKU) De base ne prend en charge ni RADIUS, ni IKEv2.

Comment supprimer la configuration d’une connexion P2S ?

Vous pouvez supprimer une configuration P2S avec Azure CLI et PowerShell en utilisant les commandes suivantes :

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

L’authentification RADIUS est-elle prise en charge sur toutes les références SKU de passerelle VPN Azure ?

L’authentification RADIUS est prise en charge sur toutes les références SKU à l’exception de la référence SKU de base.

Pour les références SKU héritées, l’authentification RADIUS est prise en charge sur les références SKU Standard et Hautes performances. Elle n’est pas prise en charge sur la référence SKU de passerelle De base.

L’authentification RADIUS est-elle prise en charge pour le modèle de déploiement classique ?

Non. L’authentification RADIUS n’est pas prise en charge pour le modèle de déploiement classique.

Quel est le délai d’expiration des demandes RADIUS envoyées au serveur RADIUS ?

Les demandes RADIUS sont définies pour expirer après 30 secondes. Les valeurs de délai d’expiration définies par l’utilisateur ne sont pas prises en charge actuellement.

Les serveurs RADIUS tiers sont-ils pris en charge ?

Oui, les serveurs RADIUS tiers sont pris en charge.

Quels sont les besoins en connectivité pour s’assurer que la passerelle Azure est en mesure d’atteindre un serveur RADIUS local ?

Une connexion VPN site à site au site local est nécessaire, avec les routes appropriées configurées.

Le trafic vers un serveur RADIUS local (à partir de la passerelle VPN Azure) peut-il être routé via une connexion ExpressRoute ?

Non. Il ne peut être routé que via une connexion site à site.

Y a-t-il une modification du nombre de connexions SSTP prises en charge avec l’authentification RADIUS ? Quel est le nombre maximal de connexions SSTP et IKEv2 prises en charge ?

Il n’y a pas de modification quant au nombre maximal de connexions SSTP prises en charge sur une passerelle avec l’authentification RADIUS. Il reste à 128 pour SSTP, mais dépend de la référence SKU de passerelle pour IKEv2. Pour plus d’informations sur le nombre de connexions prises en charge, consultez Références SKU de passerelle.

Quelle est la différence entre l’authentification par certificat à l’aide d’un serveur RADIUS et à l’aide de l’authentification par certificat Azure native (en chargeant un certificat approuvé dans Azure) ?

Dans l’authentification par certificat RADIUS, la demande d’authentification est transférée à un serveur RADIUS qui gère la validation du certificat réel. Cette option est utile si vous souhaitez intégrer une infrastructure d’authentification par certificat que vous possédez déjà via RADIUS.

Lorsque vous utilisez Azure pour l’authentification par certificat, la passerelle VPN Azure effectue la validation du certificat. Vous devez charger la clé publique de votre certificat sur la passerelle. Vous pouvez également spécifier la liste des certificats révoqués qui ne doivent pas être autorisés à se connecter.

L’authentification RADIUS fonctionne-t-elle avec les réseaux VPN IKEv2 et SSTP ?

Oui, l’authentification RADIUS est prise en charge pour les réseaux VPN IKEv2 et SSTP.

L’authentification RADIUS fonctionne-t-elle avec le client OpenVPN ?

L’authentification RADIUS est prise en charge sur le protocole OpenVPN.

Connexions multi-sites et réseau virtuel à réseau virtuel

Le FAQ relatif aux connexions de réseau virtuel à réseau virtuel s’applique aux connexions de passerelle VPN. Pour plus d’informations sur le peering de réseaux virtuels, voir Peering de réseaux virtuels.

Le trafic entre réseaux virtuels est-il facturé par Azure ?

Lorsque vous utilisez une connexion de passerelle VPN, le trafic de réseau virtuel à réseau virtuel au sein d’une même région est gratuit dans les deux sens. Le trafic de réseau virtuel à réseau virtuel de sortie entre différentes régions est facturé au tarif du transfert de données sortantes entre réseaux virtuels en fonction des régions sources. Pour plus d’informations, consultez la page Tarification Passerelle VPN. Si vous vous connectez vos réseaux virtuels à l’aide du peering de réseaux virtuels, plutôt qu’à l’aide d’une passerelle VPN, consultez la tarification de réseau virtuel.

Le trafic de réseau virtuel à réseau virtuel transite-t-il sur Internet ?

Non. Le trafic de réseau virtuel à réseau virtuel transite sur la dorsale principale de Microsoft Azure, et non sur Internet.

Puis-je établir une connexion de réseau virtuel à réseau virtuel sur des tenants Microsoft Entra ?

Oui, les connexions de réseau virtuel à réseau virtuel avec des passerelles VPN Azure fonctionnent sur des tenants Microsoft Entra.

Le trafic de réseau virtuel à réseau virtuel est-il sécurisé ?

Oui, il est protégé par le chiffrement IPsec/IKE.

Ai-je besoin d’un périphérique VPN pour interconnecter des réseaux virtuels ?

Non. L’interconnexion de plusieurs réseaux virtuels Azure ne requiert pas de périphérique VPN, sauf si une connectivité intersite est nécessaire.

Mes réseaux virtuels doivent-ils se trouver dans la même région ?

Non. Les réseaux virtuels peuvent être situés dans des régions (emplacements) identiques ou différentes.

Si les réseaux virtuels ne figurent pas dans le même abonnement, les abonnements doivent-ils être associés au même locataire Active Directory ?

Non.

Puis-je utiliser la connexion de réseau virtuel à réseau virtuel pour connecter des réseaux virtuels dans des instances Azure séparées ?

Non. La connexion de réseau virtuel à réseau virtuel prend en charge la connexion de réseaux virtuels au sein de la même instance Azure. Par exemple, vous ne pouvez pas créer une connexion entre une instance Azure mondiale et des instances Azure du gouvernement chinois, allemand ou américain. Pour ces scénarios, envisagez l’utilisation d’une connexion VPN de site à site.

Puis-je utiliser une connexion de réseau virtuel à réseau virtuel en plus de connexions multisites ?

Oui. Une connectivité réseau virtuelle peut être utilisée en même temps que des VPN multisites.

À combien de sites locaux et de réseaux virtuels peut se connecter un réseau virtuel ?

Consultez le tableau Conditions requises de la passerelle.

Puis-je utiliser une connexion de réseau virtuel à réseau virtuel pour connecter des machines virtuelles ou des services cloud en dehors d’un réseau virtuel ?

Non. La connexion de réseau virtuel à réseau virtuel prend en charge la connexion de réseaux virtuels. Elle ne prend pas en charge la connexion de machines virtuelles ou de services cloud qui ne se trouvent pas dans un réseau virtuel.

Un service cloud ou un point de terminaison d’équilibrage de charge peut-il s’étendre sur différents réseaux virtuels ?

Non. Un service cloud ou un point de terminaison d’équilibrage de charge ne peut pas s’étendre sur différents réseaux virtuels, même si ces derniers sont interconnectés.

Puis-je utiliser un type de réseau VPN basé sur des stratégies pour les connexions de réseau virtuel à réseau virtuel ou multisites ?

Non. Les connexions de réseau virtuel à réseau virtuel et multisites nécessitent des passerelles VPN Azure avec des types de VPN basés sur des itinéraires (dits auparavant de routage dynamique).

Puis-je connecter un réseau virtuel avec un type de réseau VPN basé sur des itinéraires à un autre réseau virtuel avec un type de réseau VPN basé sur des stratégies ?

Non, les deux réseaux virtuels DOIVENT utiliser des réseaux VPN basés sur des itinéraires (dits auparavant de routage dynamique).

Les tunnels VPN se partagent-ils la bande passante ?

Oui. Tous les tunnels VPN du réseau virtuel partagent la bande passante disponible sur la passerelle VPN Azure, ainsi que le même contrat SLA concernant le temps d’activité des passerelles VPN dans Azure.

Les tunnels redondants sont pris en charge ?

Les tunnels redondants entre deux réseaux virtuels sont pris en charge lorsqu’une passerelle de réseau virtuel est configurée comme active/active.

Des espaces d’adressage peuvent-ils se chevaucher pour les configurations de réseau virtuel à réseau virtuel ?

Non. Il ne peut pas y avoir de chevauchement entre des plages d’adresses IP.

Des espaces d’adressage peuvent-ils se chevaucher entre les réseaux virtuels connectés et les sites locaux ?

Non. Il ne peut pas y avoir de chevauchement entre des plages d’adresses IP.

Comment faire pour activer le routage entre ma connexion VPN de site à site et mon ExpressRoute ?

Si vous souhaitez activer le routage entre votre branche connectée à ExpressRoute et votre branche connectée à une connexion VPN de site à site, vous devez configurer Azure Route Server.

Puis-je utiliser une passerelle VPN Azure pour faire transiter le trafic entre mes sites locaux ou vers un autre réseau virtuel ?

Modèle de déploiement de Resource Manager
Oui. Pour en savoir plus, voir BGP.

Modèle de déploiement classique
Le transit du trafic via la passerelle VPN Azure est possible à l’aide du modèle de déploiement Classic, mais il s’appuie sur les espaces d’adressage définis de manière statique dans le fichier de configuration réseau. Le protocole BGP n’est pas encore pris en charge avec les réseaux virtuels Azure et les passerelles VPN utilisant le modèle de déploiement classique. Sans BGP, la définition manuelle des espaces d’adressage de transit peut entraîner des erreurs et n’est pas recommandée.

Azure génère-t-il la même clé prépartagée IPsec/IKE pour toutes les connexions VPN d'un même réseau virtuel ?

Non, Azure génère par défaut différentes clés prépartagées pour différentes connexions VPN. Toutefois, vous pouvez utiliser l’applet de commande PowerShell ou l’API REST Set VPN Gateway Key pour définir la valeur de clé de votre choix. La clé DOIT contenir uniquement des caractères ASCII imprimables, à l’exception de l’espace, du trait d’union (-) ou du tilde (~).

Puis-je obtenir plus de bande passante avec un plus grand nombre de réseaux VPN site à site que si j’utilise un seul réseau virtuel ?

Non, tous les tunnels VPN, y compris les VPN point à site, partagent la même passerelle VPN Azure et la bande passante disponible.

Puis-je configurer plusieurs tunnels entre mon réseau virtuel et mon site local à l'aide d’un VPN multisite ?

Oui, mais vous devez configurer BGP sur les deux tunnels, au même emplacement.

La passerelle VPN Azure respecte-t-elle les préfixes de chemin AS pour influencer les décisions de routage entre plusieurs connexions à mes sites locaux ?

Oui, la passerelle VPN Azure respecte les préfixes de chemin AS pour faciliter les décisions de routage lorsque le protocole BGP est activé. Un chemin AS plus court est préférable dans la sélection du chemin BGP.

Puis-je utiliser la propriété RoutingWeight pendant la création d’une connexion VPN VirtualNetworkGateway ?

Non, ce paramètre est réservé aux connexions de passerelle ExpressRoute. Si vous voulez influencer les décisions de routage entre plusieurs connexions, vous devez utiliser l’ajout de chemin AS.

Puis-je utiliser des réseaux VPN point à site avec mon réseau virtuel comportant plusieurs tunnels VPN ?

Oui, les réseaux VPN point à site peuvent être utilisés avec les passerelles VPN se connectant à plusieurs sites locaux et à d’autres réseaux virtuels.

Puis-je me connecter à un réseau virtuel avec les VPN IPsec sur mon circuit ExpressRoute ?

Oui, ceci est pris en charge. Pour plus d’informations, consultez Configurer des connexions ExpressRoute et VPN site à site pour qu’elles coexistent pour un réseau virtuel.

Stratégie IPsec/IKE

La stratégie personnalisée IPsec/IKE est-elle prise en charge sur toutes les références de passerelle VPN Azure ?

La stratégie IPsec/IKE personnalisée est prise en charge sur toutes les références SKU Azure, à l’exception de la référence SKU De base.

Combien de stratégies puis-je spécifier pour une connexion ?

Vous pouvez uniquement spécifier une combinaison de stratégies pour une connexion donnée.

Puis-je spécifier une stratégie partielle pour une connexion ? (Par exemple, uniquement les algorithmes IKE, et non IPsec)

Non, vous devez spécifier tous les algorithmes et paramètres pour IKE (mode principal) et IPsec (mode rapide). Vous n’êtes pas en droit de spécifier de stratégie partielle.

Quels sont les algorithmes et les forces de clé pris en charge dans la stratégie personnalisée ?

Le tableau suivant liste les algorithmes de chiffrement et les puissances de clé pris en charge que vous pouvez configurer. Vous devez sélectionner une option pour chaque champ.

IPsec/IKEv2	Options
Chiffrement IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128
Intégrité IKEv2	SHA384, SHA256, SHA1, MD5
Groupe DH	DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Aucun
Chiffrement IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Aucun
Intégrité IPsec	GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Groupe PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Aucun
Durée de vie de l’AS en mode rapide	(Facultatif : les valeurs par défaut sont utilisées si aucun valeur n’est indiquée) Secondes (entier ; min 300 /par défaut 27 000 secondes) Kilo-octets (entier ; min 1024 /par défaut 102 400 000 Ko)
Sélecteur de trafic	UsePolicyBasedTrafficSelectors** ($True/$False ; facultatif, $False par défaut si aucune valeur n’est indiquée)
Expiration DPD	Secondes (entier ; min. 9/max. 3600 ; 45 secondes par défaut)

• La configuration de votre périphérique VPN local doit correspondre aux algorithmes et paramètres suivants, spécifiés dans la stratégie IPsec/IKE Azure ou les contenir :

  • Algorithme de chiffrement IKE (Mode principal / Phase 1)
  • Algorithme d’intégrité IKE (Mode principal / Phase 1)
  • Groupe DH (Mode principal / Phase 1)
  • Algorithme de chiffrement IPsec (Mode rapide / Phase 2)
  • Algorithme d’intégrité IPsec (Mode rapide / Phase 2)
  • Groupe PFS (Mode rapide / Phase 2)
  • Sélecteur de trafic (si UsePolicyBasedTrafficSelectors est utilisé)
  • Les durées de vie de l’AS sont uniquement des spécifications locales et elles n’ont pas besoin de correspondre.

• Si GCMAES est utilisé pour l’algorithme de chiffrement IPsec, vous devez sélectionner le même algorithme GCMAES et la même longueur de clé pour l’intégrité IPsec. Par exemple, en utilisant GCMAES128 pour les deux.

• Dans le tableau des algorithmes et des clés :

  • IKE correspond au Mode principal ou à la Phase 1.
  • IPsec correspond au Mode rapide ou à la Phase 2.
  • Groupe DH spécifie le groupe Diffie-Hellman utilisé dans le Mode principal ou à la Phase 1.
  • Le Groupe PFS spécifie le Groupe Diffie-Hellmen utilisé dans le Mode rapide ou la Phase 2.

• La durée de vie de l’association de sécurité en mode principal IKE est fixée à 28 800 secondes pour les passerelles VPN Azure.

• « UsePolicyBasedTrafficSelectors » est un paramètre facultatif sur la connexion. La définition du paramètre UsePolicyBasedTrafficSelectors sur $True sur une connexion a pour effet de configurer la passerelle VPN Azure pour se connecter à un pare-feu VPN basé sur une stratégie en local. Si vous activez UsePolicyBasedTrafficSelectors, vous devez vous assurer que votre périphérique VPN dispose des sélecteurs de trafic correspondant définis avec toutes les combinaisons de préfixes de réseau local (passerelle réseau locale) à destination et à partir des préfixes du réseau virtuel Azure, plutôt que de manière indifférenciée. La passerelle VPN Azure accepte le sélecteur de trafic proposé par la passerelle VPN distante indépendamment de ce qui est configuré sur la passerelle VPN Azure.

  Par exemple, si les préfixes de votre réseau local sont 10.1.0.0/16 et 10.2.0.0/16 et si les préfixes de votre réseau virtuel sont 192.168.0.0/16 et 172.16.0.0/16, vous devez spécifier les sélecteurs de trafic suivants :

  • 10.1.0.0/16 <====> 192.168.0.0/16
  • 10.1.0.0/16 <====> 172.16.0.0/16
  • 10.2.0.0/16 <====> 192.168.0.0/16
  • 10.2.0.0/16 <====> 172.16.0.0/16

  Pour plus d’informations sur les sélecteurs de trafic basés sur une stratégie, voir Connecter plusieurs périphériques VPN basés sur une stratégie locale.

• Expiration DPD – La valeur par défaut est de 45 secondes sur les passerelles VPN Azure. Le fait de définir le délai d’expiration sur des périodes plus courtes entraîne un renouvellement de clé IKE de manière plus agressive, qui a pour effet que la connexion apparaît déconnectée dans certains cas. Cela peut ne pas être souhaitable si vos emplacements locaux sont plus éloignés de la région Azure dans laquelle réside la passerelle VPN, ou si la condition de liaison physique risque d’entraîner une perte de paquet. La recommandation générale consiste à définir un délai d’expiration compris entre 30 et 45 secondes.

Pour en savoir plus, consultez la section relative à la connexion de plusieurs appareils VPN basés sur des stratégies locales.

Quels groupes Diffie-Hellman sont pris en charge ?

Le tableau suivant liste les groupes Diffie-Hellman correspondants pris en charge par la stratégie personnalisée :

Groupe Diffie-Hellman	DHGroup	PFSGroup	Longueur de clé
1	DHGroup1	PFS1	MODP 768 bits
2	DHGroup2	PFS2	MODP 1 024 bits
14	DHGroup14 DHGroup2048	PFS2048	MODP 2 048 bits
19	ECP256	ECP256	ECP 256 bits
20	ECP384	ECP384	ECP 384 bits
24	DHGroup24	PFS24	MODP 2 048 bits

Reportez-vous à RFC3526 et RFC5114 pour plus d’informations.

La stratégie personnalisée remplace-t-elle les jeux de stratégie IPsec/IKE par défaut pour les passerelles VPN Azure ?

Oui, une fois qu’une stratégie personnalisée est spécifiée pour une connexion, la passerelle VPN Azure utilisera uniquement la stratégie pour la connexion, à la fois en tant qu’initiateur IKE et que répondeur IKE.

Si je supprime une stratégie IPsec/IKE personnalisée, la connexion devient-elle non protégée ?

Non, la connexion restera protégée par IPsec/IKE. Dès que vous supprimez la stratégie personnalisée d’une connexion, la passerelle VPN Azure revient à la liste par défaut de propositions IPsec/IKE et relance la négociation IKE avec votre appareil VPN local.

L’ajout ou la mise à jour d’une stratégie IPsec/IKE risquent-ils de perturber ma connexion VPN ?

Oui, cela pourrait entraîner une courte interruption (de quelques secondes), puisque la passerelle VPN Azure va éliminer la connexion existante et relancer la négociation IKE pour rétablir le tunnel IPsec avec les nouveaux algorithmes de chiffrement et paramètres. Vérifiez que votre appareil VPN local est également configuré avec les algorithmes et les puissances de clé correspondants pour réduire l’interruption.

Puis-je utiliser des stratégies différentes pour des connexions distinctes ?

Oui. Une stratégie personnalisée est appliquée sur une base par connexion. Vous pouvez créer et appliquer des stratégies IPsec/IKE différentes pour des connexions distinctes. Vous pouvez également choisir d’appliquer des stratégies personnalisées pour un sous-ensemble de connexions. Les autres connexions utiliseront les jeux de stratégie IPsec/IKE par défaut d’Azure.

Puis-je également utiliser la stratégie personnalisée pour une connexion entre des réseaux virtuels ?

Oui, vous pouvez appliquer la stratégie personnalisée pour des connexions IPsec entre différents sites locaux ou des connexions entre des réseaux virtuels.

Dois-je spécifier la même stratégie pour les ressources de connexion entre des réseaux virtuels ?

Oui. Un tunnel entre des réseaux virtuels se compose de deux ressources de connexion dans Azure, une pour chaque direction. Assurez-vous que les deux ressources de connexion ont la même stratégie, sinon la connexion de réseau virtuel à réseau virtuel ne pourra pas être établie.

Quelle est la valeur du délai d’expiration DPD par défaut ? Est-ce que je peux spécifier un autre délai d’expiration DPD ?

Le délai d’expiration DPD par défaut est de 45 secondes. Vous pouvez spécifier une autre valeur de délai d’expiration DPD entre 9 et 3 600 secondes sur chaque connexion IPsec ou VNet à VNet.

Notes

La valeur par défaut est de 45 secondes sur les passerelles VPN Azure. Le fait de définir le délai d’expiration sur des périodes plus courtes entraîne un renouvellement de clé IKE de manière plus agressive, qui a pour effet que la connexion apparaît déconnectée dans certains cas. Cela n’est peut-être pas souhaitable si vos emplacements locaux sont plus loin de la région Azure dans laquelle réside la passerelle VPN, ou quand la condition de liaison physique risque d’entraîner une perte de paquets. La recommandation générale est de définir le délai d’expiration entre 30 et 45 secondes.

La stratégie IPsec/IKE est-elle compatible avec une connexion ExpressRoute ?

Non. La stratégie IPsec/IKE est uniquement compatible avec les connexions S2S VPN et entre des réseaux virtuels via les passerelles VPN Azure.

Comment créer des connexions avec le type de protocole IKEv1 ou IKEv2 ?

Les connexions IKEv1 peuvent être créées sur toutes les références SKU de type VPN RouteBased, à l’exception de la référence SKU De base, la référence SKU Standard et autres références SKU héritées. Vous pouvez spécifier un type de protocole de connexion IKEv1 ou IKEv2 lors de la création de connexions. Si vous ne spécifiez pas de type de protocole de connexion, IKEv2 est utilisé comme option par défaut là où c’est applicable. Pour plus d’informations, consultez la documentation de l’applet de commande PowerShell. Pour les types SKU et la prise en charge de IKEv1/IKEv2, consultez Connecter des passerelles à des appareils VPN basés sur des stratégies.

Le transit entre les connexions IKEv1 et IKEv2 est-il autorisé ?

Oui. Le transit entre les connexions IKEv1 et IKEv2 est pris en charge.

Puis-je avoir des connexions de site à site IKEv1 sur les références SKU de base de type VPN RouteBased ?

Non. La référence SKU De base ne le prend pas en charge.

Puis-je changer le type de protocole de connexion une fois la connexion créée (IKEv1 en IKEv2 et vice versa) ?

Non. Une fois la connexion créée, les protocoles IKEv1/IKEv2 ne peuvent pas être changés. Vous devez supprimer et recréer une connexion avec le type de protocole souhaité.

Pourquoi ma connexion IKEv1 se reconnecte-t-elle fréquemment ?

Si votre connexion IKEv1 de routage statique ou basée sur la route est déconnectée à intervalles réguliers, cela est probablement dû au fait que les passerelles VPN ne prennent pas en charge les recréations de clé sur place. En cas de recréation de clé du mode principal, vos tunnels IKEv1 se déconnectent et leur reconnexion prend jusqu’à 5 secondes. La valeur d’expiration du délai d’attente de négociation du mode principal détermine la fréquence de recréation de clé. Pour empêcher ces reconnexions, vous pouvez passer à l’utilisation d’IKEv2, qui prend en charge les recréations de clé sur place.

Si votre connexion se reconnecte à des moments aléatoires, suivez notre guide de résolution des problèmes.

Où trouver les informations et les étapes de configuration ?

Pour plus d’informations et pour connaître les étapes de configuration, consultez les articles suivantes.

• Configurer la stratégie IPsec/IKE pour les connexions S2S ou VNet à VNet - Portail Azure
• Configurer la stratégie IPsec/IKE pour des connexions S2S ou de réseau virtuel à réseau virtuel : Azure PowerShell

BGP et routage

Le protocole BGP est-il pris en charge sur toutes les références de passerelle VPN Azure ?

Le protocole BGP est pris en charge sur toutes les références SKU de passerelle VPN Azure, à l’exception de la référence SKU De base.

Est-ce que je peux utiliser BGP avec les passerelles VPN Azure Policy ?

Non, BGP est pris en charge uniquement sur les passerelles VPN basées sur des routes.

Est-ce que je peux utiliser des numéros ASN (Autonomous System Numbers) ?

Vous pouvez utiliser vos propres ASN publics ou privés pour vos réseaux locaux et vos réseaux virtuels Azure. Vous ne pouvez pas utiliser les plages réservées par Azure ou l’IANA.

Les ASN suivants sont réservés par Azure ou l’IANA :

• Numéros ASN réservés par Azure :

  • ASN publics : 8074, 8075, 12076
  • ASN privés : 65515, 65517, 65518, 65519, 65520

• ASN réservés par l’IANA :

  • 23456, 64496-64511, 65535-65551 et 429496729.

Vous ne pouvez pas spécifier ces ASN pour vos périphériques VPN locaux quand vous les connectez à des passerelles VPN Azure.

Est-ce que je peux utiliser des ASN 32 bits (4 octets) ?

Oui, la passerelle VPN prend désormais en charge les ASN 32 bits (4 octets). Pour configurer en utilisant un ASN au format décimal, utilisez PowerShell, Azure CLI ou le kit SDK Azure.

Quels sont les ASN privés que je peux utiliser ?

Les plages utilisables d’ASN privés sont les suivantes :

• 64512-65514 et 65521-65534

Ces ASN ne sont pas réservés par IANA ou Azure et peuvent donc être affectés à votre passerelle VPN Azure.

Quelle adresse la passerelle VPN utilise pour l’IP de pair BGP ?

Par défaut, la passerelle VPN alloue une seule adresse IP de la plage GatewaySubnet pour les passerelles VPN de type actif/passif, ou deux adresses IP pour les passerelles VPN actif-actif. Ces adresses sont allouées automatiquement lorsque vous créez la passerelle VPN. Vous pouvez obtenir l’adresse IP BGP qui a été effectivement allouée en utilisant PowerShell ou en la localisant dans le portail Azure. Dans PowerShell, utilisez Get-AzVirtualNetworkGateway et recherchez la propriété bgpPeeringAddress. Dans le portail Azure, dans la page Configuration de la passerelle, recherchez la propriété Configurer l’ASN BGP.

Si vos routeurs VPN locaux utilisent des adresses IP APIPA (169.254.x.x) comme adresses IP BGP, vous devez spécifier une ou plusieurs adresse IP BGP Azure APIPA sur votre passerelle VPN Azure. La passerelle VPN Azure sélectionne les adresses APIPA à utiliser avec le pair BGP APIPA local spécifié dans la passerelle de réseau local ou l’adresse IP privée pour un pair BGP local non-APIPA. Pour plus d’informations, consultez Configurer BGP.

Quelles sont les conditions requises concernant les adresses IP de pair BGP sur mon périphérique VPN ?

Votre adresse de pair BGP locale ne doit pas être identique à l’adresse IP publique de votre périphérique VPN ni issue de l’espace d’adressage VNet de la passerelle VPN. Utilisez une adresse IP différente sur le périphérique VPN de votre adresse IP BGP homologue. Il peut s’agir d’une adresse affectée à l’interface de bouclage sur l’appareil (soit une adresse IP normale, soit une adresse APIPA). Si votre appareil utilise une adresse APIPA pour BGP, vous devez spécifier une ou plusieurs adresses IP BGP APIPA sur votre passerelle VPN Azure, comme décrit dans Configurer BGP. Spécifiez ces adresses sur la passerelle de réseau local correspondante représentant l’emplacement.

Que dois-je spécifier comme préfixes d’adresse pour la passerelle de réseau local lorsque j’utilise BGP ?

Important

Il y a un changement par rapport à la spécification précédemment documentée. Si vous utilisez BGP pour une connexion, laissez le champ Espace d’adressage vide pour la ressource de passerelle de réseau local correspondante. La passerelle VPN Azure ajoute en interne une route hôte à l’IP de pair BGP local sur le tunnel IPsec. N’ajoutez pas la route /32 dans le champ Espace d’adressage. C’est redondant et si vous utilisez une adresse APIPA comme IP BGP du périphérique VPN local, vous ne pouvez pas l’ajouter à ce champ. Si vous ajoutez d’autres préfixes dans le champ Espace d’adressage, ceux-ci sont ajoutés comme routes statiques sur la passerelle VPN Azure, en plus des routes apprises via BGP.

Est-ce que je peux utiliser le même ASN pour les réseaux VPN locaux et les réseaux virtuels Azure ?

Non, vous devez attribuer des ASN différents à vos réseaux locaux et vos réseaux virtuels Azure si vous les interconnectez avec le protocole BGP. L’ASN 65515 est attribué aux passerelles VPN Azure par défaut, et ce, que le protocole BGP soit activé ou non pour la connectivité entre les sites locaux. Vous pouvez remplacer cette valeur par défaut en attribuant un ASN différent quand vous créez la passerelle VPN, ou changer l’ASN après avoir créé la passerelle. Vous devez affecter vos ASN locaux aux passerelles de réseau local Azure correspondantes.

Quels préfixes d’adresse les passerelles VPN Azure publieront-elles pour moi ?

Les passerelles publient les routes suivantes sur vos périphériques BGP locaux :

• Vos préfixes d’adresse de réseau virtuel.
• Les préfixes d’adresse de chaque passerelle de réseau local connectée à la passerelle VPN Azure.
• Les routes apprises des autres sessions de peering BGP connectées à la passerelle VPN Azure, à l’exception de la route par défaut ou des routes qui se chevauchent avec un préfixe de réseau virtuel.

Combien de préfixes est-ce que je peux publier sur la passerelle VPN Azure ?

La passerelle VPN Azure prend en charge jusqu’à 4 000 préfixes. La session BGP s’arrête si le nombre de préfixes dépasse la limite.

Puis-je publier l’itinéraire par défaut (0.0.0.0/0) vers les passerelles VPN Azure ?

Oui. Notez que cela force tout le trafic de sortie de réseau virtuel vers votre site local. Cela empêche également les machines virtuelles du réseau virtuel d’accepter la communication publique directement depuis Internet, par exemple RDP ou SSH depuis Internet vers les machines virtuelles.

Est-ce que je peux publier les mêmes préfixes que ceux de mon adresse de réseau virtuel ?

Non, la publication des mêmes préfixes que ceux de votre adresse de réseau virtuel sera bloquée ou filtrée par Azure. Toutefois, vous pouvez publier un préfixe qui soit un sur-ensemble de ce qe vous avez dans votre réseau virtuel.

Par exemple, votre réseau virtuel peut utiliser l’espace d’adresse 10.0.0.0/16 et vous pouvez publier 10.0.0.0/8. Par contre, vous ne pouvez pas publier 10.0.0.0/16 ou 10.0.0.0/24.

Est-ce que je peux utiliser BGP avec mes connexions entre des réseaux virtuels ?

Oui, vous pouvez utiliser BGP pour les connexions entre sites locaux et entre réseaux virtuels.

Puis-je combiner des connexions BGP et non-BGP pour mes passerelles VPN Azure ?

Oui. Vous pouvez combiner des connexions BGP et non-BGP pour la même passerelle VPN Azure.

La passerelle VPN Azure prend-elle en charge le routage de transit BGP ?

Oui, le routage de transit BGP est pris en charge. Cependant, les passerelles VPN Azure ne publient pas les routes par défaut sur les autres pairs BGP. Pour activer le routage de transit via plusieurs passerelles VPN Azure, vous devez activer BGP sur toutes les connexions intermédiaires entre réseaux virtuels. Pour plus d’informations, consultez À propose de BGP.

Est-ce que je peux créer plusieurs tunnels entre une passerelle VPN Azure et mon réseau local ?

Oui, vous pouvez établir plusieurs tunnels VPN de site à site (S2S) entre une passerelle VPN Azure et votre réseau local. Notez que tous ces tunnels sont comptabilisés dans le nombre total de tunnels pour vos passerelles VPN Azure et que vous devez activer BGP sur les deux tunnels.

Par exemple, si vous établissez deux tunnels redondants entre votre passerelle VPN Azure et l’un de vos réseaux locaux, 2 tunnels sont utilisés sur le quota total de votre passerelle VPN Azure.

Est-ce que je peux avoir plusieurs tunnels entre deux réseaux virtuels Azure avec BGP ?

Oui, mais au moins une des passerelles de réseau virtuel doit être dans une configuration active-active.

Est-ce que je peux utiliser BGP pour un VPN S2S dans une configuration de coexistence Azure ExpressRoute et S2S ?

Oui.

Que dois-je ajouter à mon périphérique VPN local pour la session de peering BGP ?

Ajoutez une route hôte de l’adresse IP de pair BGP Azure sur votre périphérique VPN. Cette route pointe vers le tunnel VPN S2S IPsec. Par exemple, si l’IP de pair VPN Azure est 10.12.255.30, ajoutez une route hôte pour 10.12.255.30 avec une interface de tronçon suivant de l’interface de tunnel IPsec correspondante sur votre périphérique VPN.

La passerelle de réseau virtuel prend-elle en charge BFD pour les connexions S2S avec BGP ?

Non. La détection de transfert bidirectionnel (BFD) est un protocole que vous pouvez utiliser avec BGP pour détecter les temps d’arrêt voisins plus vite que si vous utilisez des connexions actives (keepalives) BGP standard. BFD utilise des temporisations inférieures à la seconde conçues pour fonctionner dans les environnements LAN, mais pas sur l’Internet public ou les connexions de réseau étendu.

Pour les connexions sur l’Internet public, le fait d’avoir des paquets en retard ou même abandonnés n’est pas rare, donc introduire ces minuteurs agressifs peut ajouter une instabilité. Cette instabilité risque d’entraîner le blocage des routes par BGP. Comme alternative, vous pouvez configurer votre appareil local avec des minuteurs inférieurs à l’intervalle de conservation de 60 secondes par défaut et le minuteur de suspension de 180 secondes. Vous obtiendrez un temps de convergence plus rapide. Toutefois, les retardateurs inférieurs à l’intervalle « keepalive » de 60 secondes par défaut ou au retardateur de 180 secondes par défaut ne sont pas fiables. Il est recommandé de conserver les retardateurs au niveau ou au-dessus des valeurs par défaut.

Les passerelles VPN Azure lancent-elles des connexions ou des sessions de peering BGP ?

La passerelle lance des sessions de Peering BGP sur les adresses IP de pair BGP locales spécifiées dans les ressources de passerelle de réseau local en utilisant les adresses IP privées sur les passerelles VPN. Il en est ainsi, que les adresses IP BGP locales se trouvent dans la plage APIPA ou soient des adresses IP privées standard. Si vos appareils VPN locaux utilisent des adresses APIPA comme adresse IP BGP, vous devez configurer votre speaker BGP pour lancer les connexions.

Puis-je configurer un tunneling forcé ?

Oui. Consultez Configurer un tunneling forcé.

NAT

Le protocole NAT est-il pris en charge sur toutes les références SKU de passerelle VPN Azure ?

NAT est pris en charge sur VpnGw2~5 et VpnGw2AZ~5AZ.

Puis-je utiliser NAT sur des connexions de réseau virtuel à réseau virtuel ou P2S ?

Non.

Combien de règles NAT puis-je utiliser sur une passerelle VPN ?

Vous pouvez créer jusqu’à 100 règles NAT (règles d’entrée et de sortie combinées) sur une passerelle VPN.

Puis-je utiliser/dans un nom de règle NAT ?

Non. Vous recevrez une erreur.

NAT s’applique-t-il à toutes les connexions sur une passerelle VPN ?

NAT s’applique aux connexions avec des règles NAT. Si une connexion n’a pas de règle NAT, NAT ne s’applique pas à cette connexion. Sur la même passerelle VPN, des connexions avec NAT et d’autres connexions sans NAT peuvent fonctionner ensemble.

Quels types de NAT sont pris en charge sur les passerelles VPN Azure ?

Seules la NAT statique 1:1 et la NAT dynamique sont prises en charge. NAT64 n’est PAS pris en charge.

NAT fonctionne-t-il sur des passerelles VPN de type actif/actif ?

Oui. NAT fonctionne sur les passerelles VPN de type actif/actif et actif/passif. Chaque règle NAT est appliquée à une unique instance de la passerelle VPN. Dans les passerelles active-active, créez une règle NAT distincte pour chaque instance de passerelle à travers le champ « ID de configuration IP ».

NAT fonctionne-t-il avec les connexions BGP ?

Oui, vous pouvez utiliser BGP avec NAT. Voici quelques points importants à prendre en compte :

• Sélectionnez Activer la traduction d’itinéraire BGP sur la page de configuration des règles NAT pour vous assurer que les itinéraires appris et les itinéraires publiés sont traduits en préfixes d’adresse post-NAT (mappages externes) en fonction des règles NAT associées aux connexions. Vous devez vous assurer que les routeurs BGP locaux publient les préfixes exacts tels qu’ils sont définis dans les règles IngressSNAT.

• Si le routeur VPN local utilise une adresse non APIPA standard et qu’elle est en conflit avec l’espace d’adressage du réseau virtuel ou d’autres espaces réseaux locaux, vérifiez que la règle IngressSNAT traduit l’adresse IP de l’homologue BGP en une adresse unique et non superposée, puis insérez l’adresse post-NAT dans le champ Adresse IP de l’homologue BGP de la passerelle de réseau local.

• NAT n’est pas pris en charge avec les adresses APIPA BGP.

Dois-je créer les règles DNAT correspondantes pour la règle SNAT ?

Non. Une règle SNAT unique définit la traduction dans les deux directions d’un réseau particulier :

• Une règle IngressSNAT définit la traduction des adresses IP source entrantes dans la passerelle VPN Azure à partir du réseau local. Elle gère également la traduction des adresses IP de destination qui quittent le réseau virtuel vers le même réseau local.

• Une règle EgressSNAT définit la traduction des adresses IP source de réseau virtuel sortantes de la passerelle VPN Azure vers les réseaux locaux. Elle gère également la traduction des adresses IP de destination pour les paquets arrivant dans le réseau virtuel via ces connexions à l’aide de la règle EgressSNAT.

• Dans les deux cas, aucune règle DNAT n’est nécessaire.

Que dois-je faire si mon réseau virtuel ou l’espace d’adressage de la passerelle de réseau local comporte au moins deux préfixes ? Puis-je Appliquer NAT à tous ? Ou à un sous-ensemble seulement ?

Vous devez créer une règle NAT pour chaque préfixe dont vous avez besoin pour la traduction d’adresses réseau, car chaque règle NAT ne peut inclure qu’un seul préfixe d’adresse pour NAT. Par exemple, si l’espace d’adressage de la passerelle de réseau local est 10.0.1.0/24 et 10.0.2.0/25, vous pouvez créer deux règles comme indiqué ci-dessous :

• IngressSNAT règle 1: mapper 10.0.1.0/24 à 100.0.1.0/24
• IngressSNAT règle 2 : mapper 10.0.2.0/25 à 100.0.2.0/25

Les deux règles doivent correspondre aux longueurs des préfixes d’adresse correspondants. La même chose s’applique aux règles EgressSNAT pour l’espace d’adressage du réseau virtuel.

Important

Si vous ne liez qu’une seule règle à la connexion ci-dessus, l’autre espace d'adressage ne sera PAS traduit.

Quelles plages d’adresses IP puis-je utiliser pour le mappage externe ?

Vous pouvez utiliser n’importe quelle plage d’adresses IP appropriée que vous souhaitez pour le mappage externe, y compris des adresses IP publiques et privées.

Puis-je utiliser différentes règles EgressSNAT pour traduire mon espace d’adressage de réseau virtuel en différents préfixes sur différents réseaux locaux ?

Oui, vous pouvez créer plusieurs règles EgressSNAT pour le même espace d’adressage de réseau virtuel et appliquer les règles EgressSNAT à différentes connexions.

Puis-je utiliser la même règle IngressSNAT sur différentes connexions ?

Oui, c’est généralement le cas lorsque les connexions sont destinées au même réseau local pour assurer la redondance. Vous ne pouvez pas utiliser la même règle d’entrée si les connexions concernent des réseaux locaux différents.

Ai-je besoin de règles d’entrée et de sortie sur une connexion NAT ?

Vous avez besoin de règles d’entrée et de sortie sur la même connexion lorsque l’espace d’adressage du réseau local chevauche l’espace d’adressage du réseau virtuel. Si l’espace d’adressage du réseau virtuel est unique sur tous les réseaux connectés, vous n’avez pas besoin de la règle EgressSNAT sur ces connexions. Vous pouvez utiliser les règles d’entrée pour éviter un chevauchement d’adresses sur les réseaux locaux.

Que dois-je choisir comme « ID de configuration IP » ?

« ID de configuration IP » est simplement le nom de l’objet de configuration IP que vous souhaitez que la règle NAT utilise. Avec ce paramètre, vous choisissez simplement l’adresse IP publique de la passerelle qui s’applique à la règle NAT. Si vous n’avez spécifié aucun nom personnalisé au moment de la création de la passerelle, l’adresse IP principale de la passerelle est affectée à la configuration IP « par défaut » et l’adresse IP secondaire est affectée à la configuration IP « activeActive ».

Connectivité entre locaux et machines virtuelles

Si ma machine virtuelle est dans un réseau virtuel et que j'ai une connexion entre différents locaux, comment dois-je me connecter à la machine virtuelle ?

Vous disposez de plusieurs options. Si vous avez activé le protocole RDP pour votre machine virtuelle, vous pouvez vous connecter à cette dernière à l’aide de l’adresse IP privée. Dans ce cas, vous allez spécifier l’adresse IP privée et le port auquel vous souhaitez vous connecter (généralement 3389). Vous devez configurer le port sur votre machine virtuelle pour le trafic.

Vous pouvez également vous connecter à votre machine virtuelle en adresse IP privée à partir d’une autre machine virtuelle qui se trouve sur le même réseau virtuel. Vous ne pouvez pas vous connecter en RDP à votre machine virtuelle à l’aide d’une adresse IP privée si vous vous connectez à partir d’un emplacement en dehors de votre réseau virtuel. Par exemple, si vous avez configuré un réseau virtuel point à site et que vous n’établissez pas de connexion à partir de votre ordinateur, vous ne pouvez pas vous connecter à la machine virtuelle par une adresse IP privée.

Si ma machine virtuelle est dans un réseau virtuel avec connectivité entre différents locaux, tout le trafic de ma machine virtuelle passe-t-il par cette connexion ?

Non. Seul le trafic qui possède une IP de destination contenue dans les plages d'adresse IP du réseau local du réseau virtuel que vous avez spécifié passera par la passerelle de réseau virtuel. Le trafic avec une IP de destination qui se trouve dans le réseau virtuel reste dans le réseau virtuel. Tout autre trafic est envoyé par le biais de l'équilibreur de charge aux réseaux publics, ou si le tunneling forcé est utilisé, il est envoyé via la passerelle VPN Azure.

Résolution d’une connexion RDP à une machine virtuelle

Si vous rencontrez des problèmes de connexion à une machine virtuelle sur votre connexion VPN, vérifiez les éléments suivants :

• Vérifiez que votre connexion VPN aboutit.
• Vérifiez que vous vous connectez à l’adresse IP privée de la machine virtuelle.
• Si vous pouvez vous connecter à la machine virtuelle à l’aide de l’adresse IP privée, mais pas à l’aide du nom d’ordinateur, vérifiez que vous avez correctement configuré DNS. Pour plus d’informations sur le fonctionnement de la résolution de noms pour les machines virtuelles, consultez Résolution de noms pour les machines virtuelles.

Lorsque vous vous connectez de point à site, vérifiez les éléments supplémentaires suivants :

• Utilisez « ipconfig » pour vérifier l’adresse IPv4 attribuée à l’adaptateur Ethernet sur l’ordinateur à partir duquel vous vous connectez. Si l’adresse IP est comprise dans la plage d’adresses du réseau virtuel auquel vous vous connectez, ou dans la plage d’adresses de votre VPNClientAddressPool, cette situation est désignée sous le terme d’espaces d’adressage qui se chevauchent. Lorsque vos espaces d’adressage se chevauchent de cette façon, le trafic réseau n’atteint pas Azure et reste sur le réseau local.
• Vérifiez que le package de configuration du client VPN a été généré après que les adresses IP du serveur DNS ont été spécifiées pour le réseau virtuel. Si vous avez mis à jour les adresses IP du serveur DNS, générez et installez un package de configuration du client VPN.

Pour plus d’informations sur la résolution d’une connexion RDP, consultez Résoudre des problèmes de connexion Bureau à distance à une machine virtuelle.

Maintenance de passerelle contrôlée par le client

Quels sont les services inclus dans l’étendue de la configuration de la maintenance des passerelles réseau ?

L’étendue des passerelles réseau inclut des ressources de passerelle dans les services de mise en réseau. Il existe quatre types de ressources dans l’étendue des passerelles réseau :

• Passerelle de réseau virtuel dans le service ExpressRoute.
• Passerelle de réseau virtuel dans le service de passerelle VPN.
• Passerelle VPN (site à site) dans le service Virtual WAN.
• Passerelle ExpressRoute dans le service Virtual WAN.

Quelle maintenance est prise en charge ou non par la maintenance contrôlée par le client ?

Les services Azure passent par des mises à jour de maintenance périodiques pour améliorer les fonctionnalités, la fiabilité, les performances et la sécurité. Une fois que vous avez configuré une fenêtre de maintenance pour vos ressources, la maintenance du système d’exploitation invité et du service est effectuée pendant cette fenêtre. Les mises à jour de l’hôte, au-delà des mises à jour de l’hôte (tel que TOR, Power, etc.) et des mises à jour de sécurité critiques, ne sont pas couvertes par la maintenance contrôlée par le client.

Puis-je recevoir une notification préalable de la maintenance ?

À ce stade, la notification préalable ne peut pas être activée pour la maintenance des ressources de passerelle réseau.

Puis-je configurer une fenêtre de maintenance inférieure à cinq heures ?

À ce stade, vous devez configurer une fenêtre minimale de cinq heures dans le fuseau horaire de votre choix.

Puis-je configurer une fenêtre de maintenance autre que la planification quotidienne ?

À ce stade, vous devez configurer une fenêtre de maintenance quotidienne.

Existe-t-il des cas où je ne peux pas contrôler certaines mises à jour ?

La maintenance contrôlée par le client prend en charge les mises à jour du système d’exploitation invité et du service. Ces mises à jour concernent la plupart des éléments de maintenance qui préoccupent les clients. Certains autres types de mises à jour, y compris les mises à jour de l’hôte, sortent du cadre de la maintenance contrôlée par le client.

En outre, s’il existe un problème de sécurité de gravité élevé susceptible de mettre en danger nos clients, Azure peut avoir besoin de remplacer le contrôle client de la fenêtre de maintenance et d’envoyer (push) la modification. Il s’agit d’occurrences rares qui ne seraient utilisées que dans des cas extrêmes.

Les ressources de configuration de maintenance doivent-elles se trouver dans la même région que la ressource de passerelle ?

Oui

Quelles références SKU de passerelle peuvent être configurées pour utiliser la maintenance contrôlée par le client ?

Toutes les références SKU de passerelle (à l’exception de la référence SKU de base pour la passerelle VPN) peuvent être configurées pour utiliser la maintenance contrôlée par le client.

Combien de temps faut-il pour que la stratégie de configuration de maintenance devienne effective une fois qu’elle est affectée à la ressource de passerelle ?

Les passerelles réseau peuvent mettre jusqu’à 24 heures pour suivre la planification de maintenance après que la stratégie de maintenance a été associée à la ressource de passerelle.

Existe-t-il des limitations sur l’utilisation de la maintenance contrôlée par le client en fonction de l’adresse IP publique de la référence SKU de base ?

Oui. Les ressources de passerelle qui utilisent une adresse IP publique de référence SKU de base peuvent uniquement avoir des mises à jour de service en suivant la planification de maintenance contrôlée par le client. Pour ces passerelles, la maintenance du système d’exploitation invité ne suit pas le calendrier de maintenance contrôlé par le client en raison des limitations de l’infrastructure.

Comment planifier des fenêtres de maintenance lors de l’utilisation d’un VPN et d’ExpressRoute dans un scénario de coexistence ?

Lorsque vous travaillez avec VPN et ExpressRoute dans un scénario de coexistence ou chaque fois que vous avez des ressources agissant en tant que sauvegardes, nous vous recommandons de configurer des fenêtres de maintenance distinctes. Cette approche garantit que la maintenance n’affecte pas vos ressources de sauvegarde en même temps.

J’ai planifié une fenêtre de maintenance pour une date ultérieure pour l’une de mes ressources. Les activités de maintenance seront-elles suspendues sur cette ressource jusqu’à ce moment-là ?

Non, les activités de maintenance ne seront pas suspendues sur votre ressource pendant la période précédant la fenêtre de maintenance planifiée. Pendant les jours non couverts dans votre planification de maintenance, la maintenance continue comme d’habitude sur la ressource.

Comment en savoir plus sur la maintenance de passerelle contrôlée par le client ?

Pour en savoir plus, reportez-vous à l’article de maintenance de passerelle contrôlée par le client de passerelle VPN.

Étapes suivantes

• Pour plus d’informations sur la passerelle VPN, consultez À propos de la passerelle VPN.
• Pour plus d’informations sur les paramètres de configuration de la passerelle VPN, consultez À propos des paramètres de configuration de la passerelle VPN.

« OpenVPN » est une marque d’OpenVPN Inc.