Partager via


Utiliser Azure Private Link dans Azure Virtual WAN

Azure Private Link est une technologie qui vous permet de connecter des offres PaaS Azure à l’aide d’une connectivité d’adresse IP privée en exposant des points de terminaison privés. Grâce à Azure Virtual WAN, vous pouvez déployer un point de terminaison privé dans l’un des réseaux virtuels connectés à un hub virtuel. La liaison privée permet de se connecter à un autre réseau virtuel ou à une autre branche connectée au même réseau Virtual WAN.

Avant de commencer

Les étapes décrites dans cet article supposent que vous avez déployé un réseau étendu virtuel avec un ou plusieurs hubs et au moins deux réseaux virtuels connectés à Virtual WAN.

Pour créer un nouveau réseau étendu virtuel et un nouveau hub, suivez les étapes décrites dans les articles suivants :

La connectivité de point de terminaison privé dans Azure est avec état. Lorsqu’une connexion à un point de terminaison privé est établie via Virtual WAN, le trafic est acheminé via un ou plusieurs tronçons de trafic via différents composants Virtual WAN (par exemple, routeur de hub virtuel, passerelle ExpressRoute, passerelle VPN, pare-feu Azure ou appliances virtuelles réseau). Le trafic exact des tronçons dépend de vos configurations de routage Virtual WAN. En coulisses, la couche réseau à définition logicielle d'Azure envoie tous les paquets liés à un flux unique de 5 tuples à l’une des instances de back-end desservant les différents composants Virtual WAN. Le trafic routé de manière asymétrique (par exemple, le trafic correspondant à un flux unique de 5 tuples routé vers différentes instances de back-end) n’est pas pris en charge et est supprimé par la plateforme Azure.

Pendant les événements de maintenance sur l’infrastructure Virtual WAN, les instances back-end sont redémarrées une par une. Cela peut entraîner des problèmes de connectivité intermittents à un point de terminaison privé, car l’instance qui maintenance du flux n’est pas disponible temporairement. Un problème similaire peut survenir lorsque le pare-feu Azure ou le routeur de hub virtuel effectue un scale-out. Le même flux de trafic peut être réparti vers une nouvelle instance de back-end différente de celle qui gère actuellement le flux.

Pour atténuer l’impact des événements de maintenance et de scale-out sur le trafic de liaison privée ou de point de terminaison privé, suivez les meilleures pratiques ci-dessous :

  • Configurez la valeur de délai d’expiration TCP de n’importe quelle application (hébergée localement ou dans un autre réseau virtuel Azure) qui accède au point de terminaison privé/liaison privée pour passer de 15 à 30 secondes. Une valeur de délai d’expiration TCP plus petite permet au trafic d’application de récupérer plus rapidement à partir des événements de maintenance et de scale-out. Vous pouvez également tester différentes valeurs de délai d’expiration d’application pour déterminer un délai d’expiration approprié en fonction de vos besoins.
  • Mettez à l’échelle les composants Virtual WAN à l’avance pour gérer les pics de trafic et éviter les événements de mise à l’échelle automatique. Pour le routeur de hub virtuel, vous pouvez définir les unités d’infrastructure de routage minimales sur votre routeur hub pour empêcher la mise à l’échelle pendant les pics de trafic.

Enfin, si vous utilisez la connectivité locale entre Azure et vos infrastructures locales à l’aide d’un VPN ou d’ExpressRoute, vérifiez que votre appareil local est configuré pour utiliser le même tunnel VPN ou le même routeur Microsoft Enterprise Edge que la prochaine étape pour chaque 5-tuple correspondant au trafic des points de terminaison privés.

Créer un point de terminaison de liaison privée

Vous pouvez créer un point de terminaison de liaison privée pour de nombreux services différents. Dans cet exemple, nous allons utiliser Azure SQL Database. Vous trouverez plus d’informations sur la création d’un point de terminaison privé pour une base de données Azure SQL dans Démarrage rapide : Créer un point de terminaison privé en utilisant le portail Azure. L’illustration suivante montre la configuration réseau de la base de données Azure SQL :

créer une liaison privée

Après avoir créé la base de données Azure SQL, vous pouvez vérifier l’adresse IP du point de terminaison privé en parcourant vos points de terminaison privés :

Points de terminaison privés

En cliquant sur le point de terminaison privé que nous avons créé, vous devez voir son adresse IP privée et son nom de domaine complet (FQDN). Le point de terminaison privé devrait avoir une adresse IP comprise dans la plage du réseau virtuel (10.1.3.0/24) :

point de terminaison SQL

Vérifier la connectivité provenant du même réseau virtuel

Dans cet exemple, nous vérifions la connectivité à Azure SQL Database à partir d’une machine virtuelle Linux sur laquelle les outils MS SQL sont installés. La première étape consiste à vérifier que la résolution DNS fonctionne et que le nom de domaine complet d’Azure SQL Database est résolu en adresse IP privée, dans le même réseau virtuel où le point de terminaison privé est déployé (10.1.3.0/24) :

nslookup wantest.database.windows.net
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Comme vous pouvez le voir dans la sortie précédente, le nom de domaine complet wantest.database.windows.net est mappé à wantest.privatelink.database.windows.net, que la zone DNS privée créée avec le point de terminaison privé résout en l’adresse IP privée 10.1.3.228. L’analyse de la zone DNS privée confirme qu’il existe un enregistrement A pour le point de terminaison privé mappé à l’adresse IP privée :

Zone DNS

Après avoir vérifié la résolution DNS correcte, nous pouvons tenter de nous connecter à la base de données :

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.3.75

Comme vous pouvez le voir, nous utilisons une requête SQL spéciale qui nous donne l’adresse IP source que le serveur SQL voit à partir du client. Dans ce cas, le serveur voit le client avec son adresse IP privée (10.1.3.75), ce qui signifie que le trafic transite directement du réseau virtuel au point de terminaison privé.

Définissez les variables username et password pour qu’elles correspondent aux informations d’identification définies dans Azure SQL Database et que les exemples de ce guide fonctionnent.

Se connecter à partir d’un autre réseau virtuel

Maintenant qu’un réseau virtuel dans Azure Virtual WAN dispose d’une connectivité au point de terminaison privé, tous les autres réseaux virtuels et toutes les branches connectées à Virtual WAN peuvent également y accéder. Vous devez fournir une connectivité à l’aide de l’un des modèles pris en charge par Azure Virtual WAN, comme le scénario Any-To-Any ou le scénario Réseaux virtuels des services partagés, pour ne citer que deux exemples.

Une fois que vous disposez d’une connectivité entre le réseau virtuel ou la branche et le réseau virtuel dans lequel le point de terminaison privé a été déployé, vous devez configurer la résolution DNS :

  • Si vous vous connectez au point de terminaison privé à partir d’un réseau virtuel, vous pouvez utiliser la même zone privée que celle qui a été créée avec la base de données Azure SQL.
  • Si vous vous connectez au point de terminaison privé à partir d’une branche (VPN site à site, VPN point à site ou ExpressRoute), vous devez utiliser la résolution DNS locale.

Dans cet exemple, nous nous connectons à partir d’un autre réseau virtuel. Tout d’abord, attachez la zone DNS privée au nouveau réseau virtuel afin que ses charges de travail puissent résoudre le nom de domaine complet d’Azure SQL Database en adresse IP privée. Pour ce faire, vous pouvez lier la zone DNS privée au nouveau réseau virtuel :

lien DNS

Maintenant, toute machine virtuelle du réseau virtuel attaché doit résoudre correctement le FQDN de la base de données Azure SQL en adresse IP privée de la liaison privée :

nslookup wantest.database.windows.net
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Afin de vérifier que ce réseau virtuel (10.1.1.0/24) dispose d’une connectivité au réseau virtuel d’origine dans lequel le point de terminaison privé a été configuré (10.1.3.0/24), vous pouvez vérifier la table de routage en vigueur dans toute machine virtuelle du réseau virtuel :

itinéraires effectifs

Comme vous pouvez le voir, il existe un itinéraire pointant vers le réseau virtuel 10.1.3.0/24 injecté par les passerelles du réseau virtuel dans Azure Virtual WAN. Nous pouvons à présent tester la connectivité à la base de données :

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"
10.1.1.75

Dans cet exemple, nous avons vu comment la création d’un point de terminaison privé dans l’un des réseaux virtuels attachés à un réseau Virtual WAN permet de se connecter au reste des réseaux virtuels et des branches du réseau Virtual WAN.

Étapes suivantes

Pour plus d’informations sur Virtual WAN, consultez la FAQ.