Utiliser Azure Private Link dans Azure Virtual WAN

Article
10/16/2024

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 Virtual WAN avec un ou plusieurs hubs, ainsi qu’au moins deux réseaux virtuels connectés à Azure Virtual WAN.

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

Considérations relatives au routage avec Private Link dans Virtual WAN

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 NVA). Le trafic de tronçons exacts est basé sur vos configurations de routage Virtual WAN. En coulisses, la couche DNS envoie tous les paquets liés à un flux unique de 5 tuiles à l’une des instances dorsales desservant les différents composants du réseau étendu virtuel. Le trafic routé de manière asymétrique (par exemple, le trafic correspondant à un seul flux 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 principales sont redémarrés un par un, ce qui peut entraîner des problèmes de connectivité intermittents vers un point de terminaison privé, car l’instance qui assure la maintenance du flux n’est pas disponible temporairement. Le problème similaire peut se produire lorsque le pare-feu Azure ou le routeur de hub virtuel est mis à l’échelle. Le même flux de trafic peut être équilibré en charge vers une nouvelle instance de back-end différente de celle actuellement en cours de maintenance du 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é, tenez compte des meilleures pratiques suivantes :

Configurez la valeur de délai d’attente TCP de votre application locale pour qu’elle se situe entre 15 et 30 secondes. Une valeur de délai d’attente 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’attente d’application pour déterminer un délai d’attente approprié en fonction de vos besoins.
Pré-mise à l’échelle des composants Virtual WAN pour gérer les rafales de trafic afin d’empêcher la mise à l’échelle automatique des événements. 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 rafales de trafic.

Enfin, si vous utilisez la connectivité locale entre Azure et local à 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 le tronçon suivant pour chaque tuple de 5 tuples correspondant au trafic de point de terminaison privé.

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 :

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 :

En cliquant sur le point de terminaison privé que nous avons créé, vous devriez 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) :

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 de la base de données Azure SQL est résolu en une adresse IP privée, dans le même réseau virtuel où le point de terminaison privé a été 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ésoudra en l’adresse IP privée 10.1.3.228. L’examen de la zone DNS privée confirmera qu’il existe un enregistrement A pour le point de terminaison privé mappé à l’adresse IP privée :

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 :

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 :

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.

Partager via