Partager via

FAQ sur la passerelle VPN

  • Article

Cet article répond aux questions fréquemment posées sur les connexions intersite de passerelle VPN Azure, les connexions de configuration hybride et les passerelles de réseau virtuel (VNet). Il contient des informations complètes sur les paramètres de configuration de point à site (P2S), de site à site (S2S) et de réseau virtuel à réseau virtuel, notamment les protocoles IPsec (Internet Protocol Security) et IKE (Internet Key Exchange).

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 Azure ou dans une autre région.

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 spécifiez un serveur ou des serveurs DNS (Domain Name System) lorsque vous créez votre réseau virtuel, la passerelle de réseau privé virtuel (VPN) utilise ces serveurs DNS. Vérifiez que vos serveurs DNS spécifiés peuvent 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 section FAQ 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 de toute adresse IP publique supplémentaire seront facturés en conséquence. Consultez Tarification des adresses IP.

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

La passerelle VPN Azure prend en charge les connexions de passerelle intersite suivantes :

Pour plus d’informations sur les connexions de passerelle VPN, consultez Qu’est-ce que la passerelle VPN Azure ?.

Quelle est la différence entre les connexions de site à site et de point à site ?

  • Les configurations Site à site (tunnel VPN IPsec/IKE) se trouvent entre votre emplacement local et Azure. Vous pouvez vous connecter depuis l’un de vos ordinateurs locaux à toute machine virtuelle (VM) ou instance de rôle au sein de votre réseau virtuel, selon la façon dont vous choisissez de configurer le routage et les autorisations. 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 (périphérique matériel ou appliance logicielle). L’appliance 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. Elle utilise le client VPN intégré Windows.

    Dans le cadre de la configuration de point à site, vous installez un certificat et un package de configuration du client VPN. Le package contient les paramètres qui permettent à votre ordinateur de se connecter à n’importe quelle machine virtuelle ou instance de rôle au sein du réseau virtuel.

    Cette configuration est utile lorsque vous souhaitez vous connecter à un réseau virtuel, mais 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 de site à site et de point à site simultanément, à condition de créer votre connexion de site à site en utilisant un type de VPN basé sur l’itinéraire pour votre passerelle. Les types de VPN basé sur l’itinéraire sont appelés passerelles dynamiques dans le modèle de déploiement classique.

Une mauvaise configuration du DNS personnalisé interrompt-elle l’opération normale d’une passerelle VPN ?

Pour fonctionner normalement, la passerelle VPN doit établir une connexion sécurisée avec le plan de contrôle Azure, facilitée par des IP publiques. Cette connexion repose sur la résolution des points d'accès à la communication par le biais d'URL publics. Par défaut, les réseaux virtuels Azure utilisent le service Azure DNS intégré (168.63.129.16) pour résoudre ces URL publiques. Ce comportement par défaut permet de garantir une communication fluide entre la passerelle VPN et le plan de contrôle Azure.

Lorsque vous implémentez un DNS personnalisé au sein d’un réseau virtuel, il est essentiel de configurer un redirecteur DNS qui pointe vers Azure DNS (168.63.129.16). Cette configuration permet de maintenir une communication ininterrompue entre la passerelle VPN et le plan de contrôle. Ne pas configurer de redirection DNS vers Azure DNS peut empêcher Microsoft d'effectuer des opérations et de la maintenance sur la passerelle VPN Azure, ce qui constitue un risque pour la sécurité.

Pour permettre de garantir une fonctionnalité correcte et un état sain de votre passerelle VPN, envisagez l’une des configurations DNS suivantes dans le réseau virtuel :

  • Revenir à Azure DNS par défaut en supprimant le DNS personnalisé dans les paramètres de réseau virtuel (configuration recommandée).
  • Ajouter votre configuration DNS personnalisée à un redirecteur DNS qui pointe vers Azure DNS (168.63.129.16). En fonction des règles et de la nature spécifiques de votre DNS personnalisé, cette configuration peut ne pas résoudre le problème comme prévu.

Deux clients VPN connectés en point à site à la même passerelle VPN peuvent-ils communiquer ?

Non. Les clients VPN connectés en point à site à la même passerelle VPN ne peuvent pas communiquer entre eux.

Lorsque deux clients VPN sont connectés à la même passerelle VPN point à site, la passerelle VPN peut acheminer automatiquement le trafic entre eux en déterminant l’adresse IP attribuée à chaque client depuis le pool d’adresses. Cependant, si les clients VPN sont connectés à différentes passerelles VPN, le routage entre les clients VPN n’est pas possible, car les passerelles VPN n’ont pas connaissance de l’adresse IP attribuée au client par une autre passerelle.

Les connexions VPN point à site peuvent-elles être affectées par une vulnérabilité potentielle appelée « TunnelVision » ?

Microsoft est conscient des rapports relatifs à une technique réseau qui contourne l’encapsulation VPN. Il s’agit d’un problème à l’échelle du secteur. Il affecte tout système d’exploitation qui implémente un client DHCP (Dynamic Host Configuration Protocol) conformément à sa spécification RFC et prend en charge les itinéraires de l’option DHCP 121, y compris Windows.

Comme le notent les recherches, les mesures d’atténuation incluent l’exécution du VPN à l’intérieur d’une machine virtuelle qui obtient un bail d’un serveur DHCP virtualisé pour empêcher le serveur DHCP du réseau local d’installer des itinéraires. Vous trouverez plus d’informations sur cette vulnérabilité dans la Base de données de vulnérabilité nationale NIST.

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 ?

Depuis le 1er octobre 2023, vous ne pouvez pas créer de passerelle VPN basée sur la stratégie via le Portail Azure. Toutes les nouvelles passerelles VPN sont créées automatiquement en tant que passerelles basées sur l’itinéraire. 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 itinéraires. Vous pouvez utiliser Azure PowerShell ou l’interface de ligne de commande Azure pour créer des passerelles basées sur la stratégie.

Auparavant, les niveaux de produit (SKU) de passerelle plus anciens ne prenaient pas en charge IKEv1 pour les passerelles basées sur l’itinéraire. À 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, vous devez la supprimer et en recréer une en procédant comme suit. 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 :

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

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

Oui, vous pouvez définir des sélecteurs de trafic en utilisant l’attribut trafficSelectorPolicies sur une connexion via la commande Azure PowerShell New-AzIpsecTrafficSelectorPolicy. Pour que le sélecteur de trafic spécifié prenne effet, veillez à activer les sélecteurs de trafic basés sur la stratégie.

Les sélecteurs de trafic configurés personnalisés sont proposés uniquement lorsqu’une passerelle VPN 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 uniforme pour tous les modes de connexion (Default, InitiatorOnlyet 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 pour 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 vous 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.). Vérifiez que votre sous-réseau de passerelle existant répond aux exigences de la configuration que vous souhaitez créer.

Puis-je déployer des machines virtuelles ou des instances de rôle sur 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. 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. À partir de maintenant, vous devez utiliser une IP publique de la référence SKU Standard lorsque vous créez une passerelle VPN. Cette exigence s’applique à toutes les références SKU de passerelle, à l’exception de la référence SKU Essentiel. La référence SKU Essentiel ne prend actuellement en charge que les adresses IP publiques de référence SKU Essentiel. Nous travaillons à l’ajout de la prise en charge des adresses IP publiques de référence SKU Standard pour la référence SKU Essentiel.

Pour les passerelles non zonales et non redondantes interzone créées précédemment (références SKU de passerelle sans AZ 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. La seule fois où l’adresse IP de la passerelle VPN change, c’est quand la passerelle est supprimée, puis recréée. L’adresse IP publique ne change pas lors du redimensionnement, de la réinitialisation ou d’autres opérations de maintenance ou de mise à niveau internes de votre passerelle VPN.

Comment le retrait des adresses IP publiques de référence SKU de base affecte-t-il 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 Essentiel jusqu’à la mise hors service des adresses IP de base en septembre 2025. Avant cette mise hors service, nous fournirons aux clients une voie de migration des adresse IP de base vers les adresses IP standard.

Toutefois, les adresses IP publiques de référence SKU Essentiel sont supprimées progressivement. Quand vous créez une passerelle VPN, vous devez désormais utiliser l’adresse IP publique de la référence SKU Standard. Vous trouverez des détails sur la mise hors service des adresses IP publiques de référence SKU Essentiel dans l’Annonce des Mises à jour Azure.

Comment mon tunnel VPN est-il authentifié ?

La passerelle VPN Azure utilise l’authentification par clé pré-partagée (PSK). Nous générons une PSK lorsque nous créons le tunnel VPN. Vous pouvez modifier la PSK générée automatiquement par vous-même à l’aide de l’API REST Set Pre-Shared Key ou de la cmdlet PowerShell.

Puis-je utiliser l’API REST Set Pre-Shared Key pour configurer ma passerelle VPN basée sur la stratégie (routage statique) ?

Oui. Vous pouvez utiliser l’API REST Set Pre-Shared Key et la cmdlet PowerShell pour configurer des VPN Azure basés sur la stratégie (statiques) et des VPN de routage basés sur l’itinéraire (dynamiques).

Puis-je utiliser les autres options d'authentification ?

Nous sommes limités à l’utilisation de clés pré_partagées pour l’authentification.

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

Pour le modèle de déploiement Azure Resource Manager :

  • Azure PowerShell : utilisez AddressPrefix pour spécifier le trafic de la passerelle réseau locale.
  • Portail Azure : accédez à Passerelle de réseau local>Configuration>Espace d'adressage.

Pour le modèle de déploiement classique :

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

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

Oui, le parcours de traduction d'adresses réseau (NAT-T) est également pris en charge. La passerelle VPN Azure n’effectue AUCUNE fonctionnalité de type NAT sur les paquets internes vers/depuis les tunnels IPsec. Dans cette configuration, vérifiez que le périphérique 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 la Place de marché Azure ou en créant vos propres routeurs VPN. Vous devez configurer des itinéraires définis par l’utilisateur dans votre réseau virtuel pour vous assurer que le trafic est correctement acheminé 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. Les certificats Azure permettent de les protéger en les verrouillant. Sans les certificats appropriés, les entités externes, incluant 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 multi-hébergé. Une carte réseau exploite le réseau privé du client, et une carte réseau est exposé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 communiquer avec l’infrastructure. Un audit de sécurité Azure analyse régulièrement les points de terminaison publics.

Puis-je créer une passerelle VPN en utilisant la référence SKU Essentiel dans le portail ?

Non. La référence SKU de base n’est pas disponible dans le portail. Vous pouvez créer une passerelle VPN de référence SKU Essentiel en utilisant l’interface de ligne de commande Azure CLI ou Azure PowerShell.

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

Voir les articles suivants :

Dépréciation des références SKU plus anciennes

Les références SKU Standard et Haute performance seront dépréciées le 30 septembre 2025. Vous pouvez afficher l’annonce sur le Site des Mises à jour Azure. 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.

Puis-je créer une passerelle qui utilise une référence SKU Standard ou Haute performance après l’annonce de dépréciation le 30 novembre 2023 ?

Non. Depuis le 1er décembre 2023, vous ne pouvez pas créer de passerelles qui utilisent des références SKU Standard ou Haute performance. Vous pouvez créer des passerelles qui utilisent les références SKU VpnGw1 et VpnGw2 pour le même prix que les références SKU Standard et Haute performance, listées respectivement sur la page de tarification.

Combien de temps mes passerelles existantes seront-elles prises en charge sur les références SKU Standard et Haute performance ?

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

Dois-je migrer mes passerelles à partir de la référence SKU Standard ou Haute performance dès à présent ?

Non, aucune action n’est nécessaire pour le moment. Vous pourrez migrer vos passerelles à 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 vers VpnGw1
  • Haute performance vers 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 déconseillée vers une référence SKU AZ. Toutefois, toutes les passerelles qui utiliseront encore la référence SKU Standard ou Haute performance après le 30 septembre 2025 seront migrées et mises à niveau automatiquement vers les références SKU AZ comme suit :

  • Standard vers VpnGw1AZ
  • Haute performance vers 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. Pour connaître la tarification de la référence SKU AZ, consultez la page de tarification. 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 un meilleur niveau de performance avec VpnGw1 et VpnGw2. Actuellement, VpnGw1 à 650 Mbits/s fournit une amélioration des performances de 6,5x pour le même prix que la référence SKU Standard. VpnGw2 à 1 Gbit/s offre une amélioration des performances de 5x pour le même prix que la référence SKU Haute performance. Pour plus d’informations sur le débit des références SKU, consultez À propos des références SKU de passerelle.

Que se passe-t-il si je n’effectue pas la migration d’ici le 30 septembre 2025 ?

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

  • Standard vers VpnGw1AZ
  • Haute performance vers VpnGw2AZ

Nous enverrons des communications avant de lancer la migration sur toute passerelle.

La référence SKU Essentiel de passerelle VPN est-elle également mise hors service ?

Non, la référence SKU Essentiel de passerelle VPN n’est pas mise hors service. Vous pouvez créer une passerelle VPN en utilisant la référence SKU Essentiel via Azure PowerShell ou l’interface de ligne de commande Azure.

Actuellement, la référence SKU Essentiel de passerelle VPN ne prend en charge que la ressource d’adresse IP publique de référence SKU Essentiel (qui est en voie de mise hors service). Nous travaillons à l’ajout de la prise en charge de la ressource d’adresse IP publique de référence SKU Standard par la référence SKU Essentiel de passerelle VPN.

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 pouvez trouve une liste des périphériques VPN compatibles connus, leurs instructions, ou des exemples, de configuration correspondantes, ainsi que les caractéristiques du périphérique dans l’article À propos des périphériques VPN.

Tous les périphériques des familles de périphériques répertoriées et reconnus comme compatibles doivent fonctionner avec les réseaux virtuels. 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 ?

Selon le périphérique VPN dont vous disposez, vous pouvez éventuellement 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.

Les liens suivants fournissent d’autres informations de configuration :

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

Consultez Exemples de configuration des périphériques.

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

Consultez Paramètres IPsec/IKE par défaut.

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

Ce comportement est attendu pour les passerelles VPN basées sur la 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 distant Windows Server 2012 pour la configuration de site à site entre différents locaux.

D’autres solutions VPN logicielles fonctionnent avec notre passerelle tant qu'elles sont conformes aux implémentations IPsec standard du secteur. Pour obtenir des instructions de configuration et de support, contactez le fournisseur du logiciel.

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 que le périphérique VPN site à site utilise. Dans le cas contraire, la connexion de point à site ne fonctionnera pas. Les connexions point à site avec IKEv2 ne peuvent pas être initiées depuis les mêmes adresses IP publiques où une connexion VPN site à site est configurée sur la même passerelle VPN.

Connexions point à site

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 pris 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 ultérieure
  • Linux (strongSwan)
  • iOS

Puis-je parcourir les serveurs proxy et les pare-feu en utilisant la capacité point à site ?

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

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

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

  • VPN IKEv2 : solution VPN IPsec basée sur des normes qui utilise les ports UDP sortants 500 et 4500 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 proxys et pare-feu.

Si je redémarre un ordinateur client avec une configuration point à site, le réseau VPN va-t-il se reconnecter automatiquement ?

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

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

Le DNS dynamique (DDNS) n’est actuellement pas pris en charge dans les VPN point à site.

Des configurations de site à site et de point à site peuvent-elles coexister pour le 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 l’itinéraire 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 de routage statique ni les passerelles VPN basées sur la stratégie.

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

Selon le logiciel client VPN que vous utilisez, il est possible que vous puissiez vous connecter à plusieurs passerelles de réseau virtuel. Mais c’est le cas uniquement si les réseaux virtuels auxquels vous vous connectez n’ont pas d’espaces d’adressage en conflit entre eux ou avec le réseau depuis lequel le client se connecte. Bien que le client VPN Azure prenne en charge de nombreuses connexions VPN, vous ne pouvez avoir qu’une seule connexion à un moment donné.

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

Oui. Les connexions client de point à site à une passerelle VPN déployée dans un réseau virtuel appairé avec d’autres réseaux virtuels peuvent avoir accès aux autres réseaux virtuels appairés, tant qu’ils respectent certains critères de configuration. Pour qu’un client point à site ait accès à un réseau virtuel appairé, le réseau virtuel appairé (le réseau virtuel sans passerelle) doit être configuré avec l’attribut Utiliser les passerelles distantes. Le réseau virtuel avec la passerelle VPN doit être configuré avec Autoriser le transit de passerelle. Pour plus d'informations, consultez À propos du routage VPN point à site.

Quel débit puis-je attendre des connexions de 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. La latence et la bande passante entre vos locaux et Internet peuvent également limiter le débit.

Pour une passerelle VPN ne disposant que de connexions VPN point à site IKEv2, le débit total que vous obtiendrez dépend 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 ou IKEv2 ?

Non. Vous ne pouvez utiliser le client VPN natif sur Windows que pour SSTP, et 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 à Passerelle VPN>Configuration point à site. Pour Type d’authentification, sélectionnez le type d’authentification à utiliser.

Une fois que vous avez modifié le type d’authentification, les clients actuels peuvent ne pas être en mesure de se connecter tant qu’un nouveau profil de configuration du client VPN n’a pas été généré, téléchargé et appliqué à chaque client VPN.

Quand dois-je générer un nouveau package de configuration pour le profil client VPN ?

Lorsque vous apportez des modifications aux paramètres de configuration de la passerelle VPN P2S, comme l’ajout d’un type de tunnel ou la modification d’un type d’authentification, vous devez générer un nouveau package de configuration pour le profil client VPN. Le nouveau package inclut les paramètres mis à jour dont les clients VPN ont besoin pour se connecter à la passerelle P2S. Après avoir généré le package, utilisez les paramètres des fichiers pour mettre à jour les clients VPN.

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

Le protocole IKEv2 est pris en charge sur Windows 10 et Windows 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 et peuvent utiliser uniquement SSTP ou le protocole OpenVPN.

Remarque

Cette procédure n’est pas nécessaire pour les builds de système d’exploitation Windows plus récentes que la version 1709 de Windows 10 et la version 1607 de Windows Server 2016.

Pour préparer Windows 10 ou Windows 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éez ou définissez la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD dans le registre sur 1.

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électeur 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, de connexions réseau virtuel à réseau virtuel et de réseaux virtuels appairés connectés à la passerelle. Les clients Windows point à site ne peuvent pas se connecter via IKEv2 s’ils dépassent cette limite.

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

La limite de sélecteur de trafic pour OpenVPN est de 1000 itinéraires.

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é de périphériques Windows et Mac, le profil VPN Windows essaie toujours le tunnel IKEv2 en premier. Le client revient à SSTP si la connexion IKEv2 ne réussit pas. MacOS se connecte uniquement via IKEv2.

Lorsque SSTP et IKEv2 sont tous deux activés sur la passerelle, le pool d’adresses point à site est fractionné statiquement entre les deux, de sorte que les clients utilisant des protocoles différents sont des adresses IP de l’une ou l’autre sous-plage. Le nombre maximal de clients SSTP est toujours 128, même si la plage d’adresses est supérieure à /24. Le résultat est un plus grand nombre d’adresses disponibles pour les clients IKEv2. Pour les plages plus petites, le pool est divisé en deux parties égales. Les sélecteurs de trafic que la passerelle utilise peuvent ne pas inclure le bloc CIDR (Classless Inter-Domain Routing) pour la plage d’adresses de point à site, mais inclure le bloc CIDR pour les deux sous-plages.

Quelles plateformes sont prises en charge par Azure pour le VPN P2S ?

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

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

Oui. Oui, si la référence SKU des passerelles que vous utilisez prend en charge RADIUS ou IKEv2, vous pouvez activer ces fonctionnalités sur des passerelles déjà déployées en utilisant Azure PowerShell ou le Portail Azure. La référence (SKU) De base ne prend en charge ni RADIUS, ni IKEv2.

Pourquoi suis-je déconnecté de mon client Azure VPN ? Que puis-je faire pour réduire la fréquence des déconnexions ?

Vous pouvez voir un des messages suivants :

  • Dans Azure VPN Client pour Windows ver. 3.4.0.0 : « Votre authentification auprès de Microsoft Entra a expiré. Vous devez vous réauthentifier dans Entra pour acquérir un jeton. Le délai d’expiration de l’authentification peut être ajusté par votre administrateur. »
  • Dans VPN Azure Client pour macOS ver. 2.7.101 : « Votre authentification auprès de Microsoft Entra a expiré. Vous devez donc vous réauthentifier pour obtenir un nouveau jeton. Réessayez de vous connecter. Les stratégies d’authentification et le délai d’expiration sont configurés par votre administrateur dans le locataire Entra. »

La connexion point à site se déconnecte, car le jeton d’actualisation actuel dans le client Azure VPN, acquis auprès d’Entra ID, a expiré ou est devenu non valide. Ce jeton est renouvelé environ toutes les heures. Les administrateurs de locataire Entra peuvent étendre la fréquence des connexions en ajoutant des stratégies d’accès conditionnel. Collaborez avec les administrateurs de votre locataire Entra pour étendre l’intervalle d’expiration du jeton d’actualisation.

Pour plus d’informations, consultez Erreur du client VPN : Votre authentification auprès de Microsoft Entra a expiré.

Comment supprimer la configuration d’une connexion P2S ?

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

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

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

Connexions point à site avec authentification par certificat

Que dois-je faire si j’obtiens une incompatibilité de certificat pour une connexion d’authentification de certificat point à site ?

Décochez la case Vérifier l’identité du serveur en validant le certificat. Vous pouvez également ajouter le nom de domaine complet (FQDN) du serveur avec le certificat lorsque vous créez un profil manuellement. Pour ce faire, exécutez rasphone depuis une invite de commandes et sélectionnez le profil dans la liste déroulante.

Nous vous déconseillons de contourner la validation de l’identité du serveur en général. Toutefois, avec l’authentification par certificat Azure, le même certificat est utilisé pour la validation du serveur dans le protocole de tunneling VPN (IKEv2 ou SSTP) et le protocole EAP (Extensible Authentication Protocol). Le protocole de tunneling VPN validant déjà le certificat de serveur et le FQDN, il est redondant de les valider à nouveau dans EAP.

Capture d’écran qui montre les propriétés de l’authentification point à site.

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

Oui. Auparavant, vous ne pouviez utiliser que des certificats racines auto-signé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 d’infrastructure à clé publique (PKI) d’entreprise, qui est votre PKI interne, Azure PowerShell, MakeCert et OpenSSL.

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

Pour les formats de fichier .cer et .pfx, consultez :

Pour le format de fichier .pem, veuillez consulter :

Connexions point à site avec authentification RADIUS

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 antérieures, l’authentification RADIUS est prise en charge sur les références SKU Standard et Haute performance.

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

Non.

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 actuellement pas prises en charge.

Les serveurs RADIUS tiers sont-ils pris en charge ?

Oui.

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

Une connexion VPN site à site au site local est nécessaire, avec les itinéraires appropriés configurés.

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

Non. Il ne peut être routé que via une connexion de 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 de 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 À propos des références SKU de passerelle.

Quelle est la différence entre l’authentification par certificat via un serveur RADIUS et l’authentification par certificat natif Azure via le chargement d’un certificat approuvé ?

Dans l’authentification par certificat RADIUS, la demande d’authentification est transférée à un serveur RADIUS qui gère la validation du certificat. 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 prend-elle en charge l’intégration NPS (Network Policy Server) pour l’authentification multifacteur ?

Si votre authentification multifacteur est basée sur du texte (par exemple, SMS ou code de vérification d’application mobile) et exige que l’utilisateur entre un code ou du texte dans l’interface utilisateur du client VPN, l’authentification ne réussit pas et n’est pas un scénario pris en charge. Veuillez consulter Intégrer l’authentification RADIUS de la passerelle VPN Azure avec un serveur NPS pour l’authentification multifacteur.

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

Oui, l’authentification RADIUS est prise en charge par 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

Les informations de réseau virtuel à réseau virtuel de cette section s’appliquent 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 Tarification de la passerelle VPN Azure. Si vous connectez vos réseaux virtuels à l’aide du peering de réseaux virtuels, plutôt qu’à l’aide d’une passerelle VPN, consultez Tarification de réseau virtuel Azure.

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. Oui, les connexions de réseau virtuel à réseau virtuel qui utilisent des passerelles VPN fonctionnent sur des locataires Microsoft Entra.

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

Les chiffrements IPsec et IKE aident à protéger le trafic de réseau virtuel à réseau virtuel.

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 vous avez besoin d’une connectivité intersite.

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 se trouvent pas dans le même abonnement, les abonnements doivent-ils être associés au même locataire Microsoft Entra ?

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 de connexion entre une instance Azure globale et les instances Azure du gouvernement chinois, allemand ou américain. Pour ces scénarios, envisagez l’utilisation d’une connexion VPN site à site.

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

Oui. Vous pouvez utiliser une connectivité réseau virtuelle 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 Exigences de passerelle.

Puis-je utiliser une connexion de réseau virtuel à réseau virtuel pour connecter des machines virtuelles ou des services cloud hors 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 plusieurs réseaux virtuels, même si ces derniers sont interconnectés.

Puis-je utiliser un type de réseau VPN basé sur la stratégie 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 l’itinéraire (auparavant routage dynamique).

Puis-je connecter un réseau virtuel avec un type de réseau VPN basé sur l’itinéraire à un autre réseau virtuel avec un type de réseau VPN basé sur la stratégie ?

Non. Les deux réseaux virtuels doivent utiliser des réseaux VPN basés sur l’itinéraire (auparavant 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 et le même contrat de niveau de service pour la durée de fonctionnement de la passerelle 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 site à site et mon ExpressRoute ?

Si vous souhaitez activer le routage entre votre branche connectée à ExpressRoute et votre branche connectée à un VPN site à site, vous devez configurer Serveur de routes Azure.

Puis-je utiliser une passerelle VPN 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. Consultez la section BGP et routage pour plus d’informations.

  • Modèle de déploiement classique

    Le transit du trafic via une passerelle VPN est possible quand vous utilisez le modèle de déploiement Classique, 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 (Border Gateway Protocol) n’est actuellement pas pris en charge avec les réseaux virtuels Azure et les passerelles VPN via 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 mes connexions VPN du 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’API REST de clé de passerelle VPN définie ou la cmdlet PowerShell pour définir la valeur clé que vous préférez. La clé ne doit contenir que 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 et la bande passante disponible.

Puis-je configurer plusieurs tunnels entre mon réseau virtuel et mon site local en utilisant 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. Vous pouvez utiliser les réseaux VPN point à site 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 la coexistence de connexions site à site et ExpressRoute.

Stratégie IPsec/IKE

Toutes les références SKU de passerelle VPN Azure prennent-elles en charges les stratégies personnalisées IPsec/IKE ?

Toutes les références SKU de passerelle VPN Azure prennent en charge les stratégies personnalisées IPsec/IKE, à l’exception de la référence SKU Essentiel.

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

Vous ne pouvez spécifier qu’une seule combinaison de stratégies pour une connexion.

Puis-je spécifier une stratégie partielle sur une connexion (par exemple, seuls les algorithmes IKE, mais pas 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 points forts clés pris en charge par 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’accès partagé en mode rapide (Facultatif. Valeurs par défaut en l’absence de spécification)
Secondes (entier, 300 au minimum, 27 000 par défaut)
Kilooctets (entier, 1 024 au minimum, 102 400 000 par défaut)
Sélecteur de trafic UsePolicyBasedTrafficSelectors ($True ou $False, mais facultatif, $False par défaut en l’absence de spécification)
Expiration DPD Secondes (entier, 9 au minimum, 3 600 au maximum, 45 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 Azure IPsec ou IKE, 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 vous utilisez UsePolicyBasedTrafficSelectors)
    • Durées de vie de l’association de sécurité (spécifications locales qui n’ont pas besoin de correspondre)

  • Si vous utilisez GCMAES 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, utilisez 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.
    • Le 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-Hellman 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 de la connexion. Si vous affectez la valeur $True à UsePolicyBasedTrafficSelectors sur une connexion, cela permet de configurer la passerelle VPN pour qu’elle se connecte à un pare-feu VPN basé sur des stratégies locales.

    Si vous activez UsePolicyBasedTrafficSelectors, vérifiez que votre périphérique VPN dispose des sélecteurs de trafic correspondants, définis avec toutes les combinaisons de préfixes de votre réseau local (passerelle réseau locale) à destination ou en provenance des préfixes de réseau virtuel Azure, et non de manière indifférenciée. La passerelle VPN accepte n’importe quel sélecteur de trafic proposé par la passerelle VPN distante, indépendamment de ce qui est configuré sur la passerelle VPN.

    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 des stratégies, consultez Connecter une passerelle VPN à plusieurs périphériques VPN locaux basés sur des stratégies.

  • La définition du délai d’expiration sur des périodes plus courtes oblige IKE à générer de nouvelles clés de chiffrement de manière plus intensive. La connexion peut alors sembler déconnectée dans certains cas. Cette situation n’est peut-être pas souhaitable si vos emplacements locaux sont plus éloignés de la région Azure dans laquelle se trouve la passerelle VPN, ou si l’état de la liaison physique est susceptible d’entraîner une perte de paquets. Nous vous recommandons généralement de définir le délai d’attente entre 30 et 45 secondes.

Pour en savoir plus, consultez Connecter une passerelle VPN à plusieurs périphériques VPN locaux basés sur la stratégie.

Quels sont les groupes Diffie-Hellman pris charge par la stratégie personnalisée ?

Le tableau suivant répertorie 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

Pour plus d’informations, consultez RFC3526 et RFC5114.

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

Oui. Après avoir spécifié une stratégie personnalisée sur une connexion, la passerelle VPN Azure utilise uniquement cette stratégie sur la connexion, à la fois en tant qu’initiateur IKE et répondeur IKE.

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

Non, IPsec/IKE permet toujours de protéger la connexion. Après avoir supprimé la stratégie personnalisée d’une connexion, la passerelle VPN revient à la liste par défaut des propositions IPsec/IKE et redémarre l’établissement d’une liaison IKE avec votre périphérique 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), car la passerelle VPN va éliminer la connexion existante et relancer l’établissement d’une liaison IKE pour rétablir le tunnel IPsec avec les nouveaux algorithmes de chiffrement et paramètres. Vérifiez que votre périphérique 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 utiliser une stratégie personnalisée sur les connexions de réseau virtuel à réseau virtuel ?

Oui. Vous pouvez appliquer une stratégie personnalisée pour les connexions IPsec entre différents sites ou les connexions de réseau virtuel à réseau virtuel.

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. Vérifiez que les deux ressources de connexion ont la même stratégie. Sinon, la connexion de réseau virtuel à réseau virtuel ne sera pas é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 sur les passerelles VPN. Vous pouvez spécifier une autre valeur de délai d’expiration DPD, entre 9 et 3 600 secondes sur chaque connexion IPsec ou réseau virtuel à réseau virtuel.

Remarque

La définition du délai d’expiration sur des périodes plus courtes oblige IKE à générer de nouvelles clés de chiffrement de manière plus intensive. La connexion peut alors sembler déconnectée dans certains cas. Cette situation n’est peut-être pas souhaitable si vos emplacements locaux sont plus éloignés de la région Azure dans laquelle se trouve la passerelle VPN, ou si l’état de la liaison physique est susceptible d’entraîner une perte de paquets. Nous vous recommandons généralement de définir le délai d’attente entre 30 et 45 secondes.

Une stratégie IPsec/IKE personnalisée fonctionne-elle sur les connexions ExpressRoute ?

Non. Une stratégie IPsec/IKE n’est compatible qu’avec les connexions S2S VPN et de réseau virtuel à réseau virtuel via les passerelles VPN.

Comment faire pour créer des connexions avec les types de protocole IKEv1 ou IKEv2 ?

Vous pouvez créer des connexions IKEv1 sur toutes les références SKU de type de VPN basé sur l’itinéraire, à l’exception de la référence SKU Essentiel, de la référence SKU Standard et des autres références SKU antérieures.

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 cmdlets Azure PowerShell.

Pour plus d’informations sur les types de référence SKU et la prise en charge de IKEv1 et IKEv2, consultez Connecter une passerelle VPN à plusieurs périphériques VPN locaux basés sur la stratégie.

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

Oui.

Puis-je avoir des connexions de site à site IKEv1 sur la référence SKU Essentiel pour le type de VPN basé sur l’itinéraire ?

Non. La référence SKU Essentiel ne prend pas en charge cette configuration.

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

Non. Après avoir créé la connexion, vous ne pourrez pas modifier les protocoles IKEv1 et IKEv2. Vous devez la 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 l’itinéraire se déconnecte à intervalles réguliers, cela est probablement dû au fait que vos 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’expiration de la négociation du mode principal détermine la fréquence des recréations 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 le Guide de résolution des problèmes.

Où puis-je trouver plus d’informations et des étapes pour la configuration ?

Voir les articles suivants :

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 Essentiel.

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.

Quels ASN puis-je utiliser ?

Vous pouvez utiliser vos propres ASN (Autonomous System Numbers) publics ou privés pour vos réseaux locaux et vos réseaux virtuels Azure.

Vous ne pouvez pas utiliser les ASN réservés suivants :

  • Réservés par Azure :

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

  • Réservés par l’IANA :

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

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

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

Oui, la passerelle VPN Azure prend désormais en charge les ASN 32 bits (4 octets). Pour configurer en utilisant un ASN au format décimal, utilisez Azure PowerShell, l’interface de ligne de commande Azure ou le kit de développement logiciel (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

Ni l’IANA ni Azure ne réservent ces ASN. Vous pouvez donc les affecter à votre passerelle VPN.

Quelle adresse la passerelle VPN Azure utilise-t-elle pour l’IP d’homologue BGP ?

Par défaut, la passerelle VPN alloue une seule adresse IP de la plage GatewaySubnet pour les passerelles VPN de type active/passive, ou deux adresses IP pour les passerelles VPN de type active/active. Ces adresses sont allouées automatiquement lorsque vous créez la passerelle VPN.

Vous trouverez l’adresse IP BGP allouée à l’aide d’Azure PowerShell ou du 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 (Automatic Private IP Addressing) (169.254.x.x) comme adresses IP BGP, vous devez spécifier une ou plusieurs adresse IP BGP Azure APIPA sur votre passerelle VPN. 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 pour passerelle VPN Azure.

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

Votre adresse d’homologue BGP locale ne doit pas être identique à l’adresse IP publique de votre périphérique VPN ni issue de l’espace d’adressage de réseau virtuel 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 périphérique utilise une adresse APIPA pour BGP, vous devez spécifier une ou plusieurs adresses IP BGP APIPA sur votre passerelle VPN, comme décrit dans Configurer BGP pour les passerelles VPN Azure. Spécifiez ces adresses sur la passerelle de réseau local correspondante qui représente 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.

La passerelle VPN Azure ajoute en interne une route hôte à l’IP de pair BGP local sur le tunnel IPsec. N’ajoutez pas l’itinéraire /32 dans le champ Espace d’adressage, car il est redondant. Si vous utilisez une adresse APIPA comme adresse 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 itinéraires statiques sur la passerelle VPN Azure, en plus des itinéraires appris 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 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 attribuer vos ASN locaux aux passerelles de réseau local Azure correspondantes.

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

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

  • préfixes d’adresse de votre réseau virtuel ;
  • Les préfixes d’adresse de chaque passerelle de réseau local connectée à la passerelle VPN Azure
  • Les itinéraires appris des autres sessions d’homologation BGP connectés à la passerelle VPN Azure, à l’exception de l’itinéraire par défaut ou des itinéraires 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’à 4000 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 ?

Oui. N’oubliez pas que la publication de l’itinéraire par défaut 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 (Remote Desktop Protocol) ou SSH (Secure Shell) 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. Azure bloque ou filtre la publication des préfixes identiques à l’un de vos préfixes d’adresse de réseau virtuel. Toutefois, vous pouvez publier un préfixe qui est un sur-ensemble de ce que vous avez dans votre réseau virtuel.

Par exemple, si votre réseau virtuel utilise l’espace d’adressage 10.0.0.0/16, 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. Oui, le routage de transit BGP est pris en charge. Cependant, les passerelles VPN ne publient pas les itinéraires par défaut vers les autres homologues BGP. Pour activer le routage de transit sur plusieurs passerelles VPN, vous devez activer BGP sur toutes les connexions intermédiaires entre les réseaux virtuels. Pour plus d’informations, consultez À propos de BGP et de la passerelle VPN.

Puis-je créer plusieurs tunnels entre une passerelle VPN et mon réseau local ?

Oui, vous pouvez établir plusieurs tunnels VPN site à site entre une passerelle VPN et votre réseau local. 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 et l’un de vos réseaux locaux, 2 tunnels sont utilisés sur le quota total de votre passerelle VPN.

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.

Puis-je peux utiliser BGP pour un VPN site à site dans une configuration de coexistence Azure ExpressRoute et VPN site à site ?

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 (Bidirectional Forwarding Detection/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 intervalles actifs (keepalives) BGP standard. BFD utilise des minuteurs secondaires conçus pour fonctionner dans les environnements LAN, mais pas avec les connexions WAN ou sur l’Internet public.

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é peut entraîner la modification des itinéraires BGP.

Comme alternative, vous pouvez configurer votre périphérique local avec des minuteurs inférieurs à l’intervalle de conservation de 60 secondes par défaut et plus court que le minuteur de conservation de 180 secondes. Cette configuration entraîne un temps de convergence plus court. Toutefois, les minuteurs inférieurs à l’intervalle de conservation de 60 secondes par défaut ou plus courts que le minuteur de conservation de 180 secondes par défaut ne sont pas fiables. Nous vous recommandons de conserver les minuteurs aux valeurs par défaut ou au-dessus.

Les passerelles VPN lancent-elles des connexions ou des sessions d’homologation BGP ?

La passerelle lance des sessions d’homologation BGP sur les adresses IP d’homologue 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. Ce processus est indépendamment du fait que les adresses IP BGP locales se trouvent dans la plage APIPA ou soient des adresses IP privées normales. Si vos périphériques 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 vers VpnGw25 et sur VpnGw2AZ vers VpnGw5AZ.

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 une barre oblique (/) 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 qui ont 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, vous pouvez avoir certaines connexions avec NAT et d’autres connexions sans NAT qui fonctionnent ensemble.

Quels types de NAT les passerelles VPN prennent-elles en charge ?

Les passerelles VPN prennent uniquement en charge NAT statique 1:1 et NAT dynamique. Elles ne prennent pas en charge NAT64.

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 en mode actif/actif, créez une règle NAT distincte pour chaque instance de passerelle via 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 :

  • 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, sélectionnez Activer la traduction d’itinéraire BGP sur la page de configuration des règles NAT. Les routeurs BGP locaux doivent publier les préfixes exacts tels que définis dans les règles IngressSNAT.

  • Si le routeur VPN local utilise une adresse normale, non APIPA, et qu’il entre en collision avec l’espace d’adressage du réseau virtuel ou d’autres espaces réseau locaux, assurez-vous que la règle IngressSNAT traduit l’adresse IP de l’homologue BGP en adresse unique et sans chevauchement. Placez 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 de traduction d’adresses réseau source unique (SNAT) définit la traduction pour 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 depuis le 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 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 les connexions qui ont la règle EgressSNAT.

Dans les deux cas, vous n’avez pas besoin de règles de traduction d’adresses réseau de destination (DNAT).

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 à l’ensemble d’entre eux ou simplement à un sous-ensemble ?

Vous devez créer une règle NAT pour chaque préfixe, 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 :

  • Règle IngressSNAT 1 : mapper 10.0.1.0/24 à 192.168.1.0/24.
  • Règle IngressSNAT 2 : mapper 10.0.2.0/25 à 192.168.2.0/25.

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

Important

Si vous ne liez qu’une règle à la connexion précédente, l’autre espace d’adressage ne sera pas traduit.

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

Vous pouvez utiliser toute plage d’adresses IP appropriée 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 vers différents préfixes pour les réseaux locaux ?

Oui. 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. Vous utilisez généralement la même règle IngressSNAT lorsque les connexions se trouvent pour le même réseau local, pour assurer une 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 des deux 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 quand 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 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 active/active.

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 ?

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 spécifiez 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 en utilisant une adresse IP privée si vous vous connectez depuis un emplacement hors 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 dont l’adresse IP de destination est contenue dans les plages d’adresses IP de réseau local du réseau virtuel que vous avez spécifiées passe 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. Le reste du trafic est envoyé via l’équilibreur de charge aux réseaux publics. Ou, si vous utilisez le tunneling forcé, le trafic est envoyé via la passerelle VPN.

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 en utilisant l’adresse IP privée, mais pas le nom de l’ordinateur, vérifiez que vous avez correctement configuré le 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 ressources dans les réseaux virtuels Azure.

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 depuis lequel 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 du pool d'adresses de votre client VPN, il s’agit d’espaces d’adressage qui se chevauchent. Lorsque votre espace d’adressage est en chevauchement de cette façon, le trafic réseau n’atteint pas Azure. Il reste sur le réseau local.
  • Vérifiez que le package de configuration du client VPN a été généré après avoir spécifié les adresses IP du serveur DNS 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 la configuration de maintenance pour l’étendue 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 Azure Virtual WAN
  • Passerelle ExpressRoute dans le service Virtual WAN

Quelle maintenance est prise en charge 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é. Après avoir configuré une fenêtre de maintenance pour vos ressources, la maintenance du système d’exploitation invité et la maintenance du service sont effectuées lorsque cette fenêtre est ouverte. La maintenance contrôlée par le client ne couvre pas les mises à jour de l’hôte (au-delà des mises à jour de l’hôte pour Marche/Arrêt, par exemple) et les mises à jour de sécurité critiques.

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

À ce stade, vous ne pouvez pas recevoir de notification avancée pour la maintenance des ressources de la 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 qu’une 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. D’autres types de mises à jour, notamment les mises à jour de l’hôte, sortent du cadre de la maintenance contrôlée par le client.

Si un problème de sécurité de gravité élevée peut mettre en danger les clients, Azure peut avoir besoin de remplacer le contrôle client de la fenêtre de maintenance et d’envoyer (push) une modification. Ces changements sont des occurrences rares, que nous utilisons uniquement 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 puis-je configurer pour utiliser la maintenance contrôlée par le client ?

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

Combien de temps faut-il pour qu’une stratégie de configuration de maintenance prenne effet 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 Essentiel ?

Oui. La maintenance contrôlée par le client ne fonctionne pas pour les ressources qui utilisent des adresses IP publiques de référence SKU Essentiel, sauf dans le cas des mises à jour du service. Pour ce qui est de ces passerelles, la maintenance du système d’exploitation invité ne suit pas le calendrier de maintenance contrôlée par le client en raison de 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 lorsque vous avez des ressources qui agissent comme des sauvegardes, nous vous recommandons de mettre en place des fenêtres de maintenance séparées. Cette approche garantit que la maintenance n’affecte pas vos ressources de sauvegarde en même temps.

J’ai programmé une fenêtre de maintenance à 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 interrompues sur votre ressource pendant la période précédant la fenêtre de maintenance programmé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 plus d’informations, consultez l’article Configurer la maintenance de passerelle contrôlée par le client pour passerelle VPN.

Contenu connexe

« OpenVPN » est une marque d’OpenVPN Inc.