Guide sur Private Link et DNS dans Azure Virtual WAN

Azure Private Link

Azure DNS

Pare-feu Azure

Azure Virtual WAN

Azure Private Link permet aux clients d’accéder aux services PaaS (platform as a service) Azure directement à partir de réseaux virtuels privés sans utiliser d’adresse IP publique. Pour chaque service, vous configurez un point de terminaison privé qui utilise une adresse IP privée de votre réseau. Les clients peuvent ensuite utiliser le point de terminaison privé pour se connecter en privé au service.

Les clients continuent d’utiliser le nom de domaine complet (FQDN) d’un service pour s’y connecter. Vous configurez DNS dans votre réseau pour résoudre le nom de domaine complet du service en adresse IP privée du point de terminaison privé.

La conception de votre réseau et, en particulier, la configuration de votre DNS, sont des facteurs clés de la prise en charge de la connectivité du point de terminaison privé aux services. Cet article fait partie d’une série d’articles qui fournissent une aide à l’implémentation de différents scénarios Private Link. Même si aucun des scénarios ne correspond exactement à votre situation, vous devez pouvoir adapter les conceptions pour répondre à vos besoins.

Topologie de réseau de départ

La topologie de réseau de départ est une architecture de réseau qui sert de point de départ à tous les scénarios de cette série d’articles. L’architecture est un réseau hub-and-spoke classique qui utilise Azure Virtual WAN.

Figure 1 : Topologie de réseau de départ de tous les scénarios de points de terminaison privés et DNS

Téléchargez un fichier Visio de cette architecture. Cette topologie présente les caractéristiques suivantes :

Il s’agit d’un réseau hub-and-spoke implémenté avec Azure Virtual WAN.
Il existe deux régions, chacune ayant un hub virtuel sécurisé de Pare-feu Azure régional.
Les paramètres de sécurité des connexions au Réseau virtuel Azure de chaque hub virtuel régional sécurisé sont les suivants :
- Trafic Internet : Sécurisé par le Pare-feu Azure - Tout le trafic vers Internet transite par le pare-feu du hub régional.
- Trafic privé : Sécurisé par le Pare-feu Azure - Tout le trafic vers le spoke à spoke transite par le pare-feu du hub régional.
Chaque hub virtuel régional est sécurisé par un Pare-feu Azure. Les paramètres du pare-feu du hub régional sont les suivants :
- Serveurs DNS : Par défaut (fourni par Azure) - Le pare-feu du hub régional utilise explicitement Azure DNS pour la résolution du nom de domaine complet dans les collections de règles.
- Proxy DNS : Activé - Le pare-feu du hub régional répond aux requêtes DNS sur le port 53. Il transfère les requêtes de valeurs non mises en cache vers Azure DNS.
- Le pare-feu journalise les évaluations de règles et les requêtes de proxy DNS dans un espace de travail Log Analytics qui se trouve dans la même région. La journalisation de ces événements est une exigence de journalisation de sécurité réseau courante.
Chaque spoke de réseau virtuel connecté possède son serveur DNS par défaut configuré pour correspondre à l’adresse IP privée du pare-feu du hub régional. Sinon, l’évaluation de la règle du nom de domaine complet peut être désynchronisée.

Routage multi-région

La prise en charge de la connectivité entre hubs des hubs Virtual WAN sécurisés est limitée lorsqu’il y a plusieurs hubs virtuels sécurisés. Cette limitation affecte les scénarios multi-hub, intrarégionaux et interrégionaux. Par conséquent, la topologie réseau ne facilite pas directement le filtrage du trafic privé interrégional via le Pare-feu Azure. La prise en charge de cette fonctionnalité est assurée à l’aide d’intention et de stratégies de routage du hub Virtual WAN. Pour le moment, cette fonctionnalité n’est disponible que dans la version préliminaire.

Dans cette série d’articles, il est supposé que le trafic sécurisé interne ne traverse pas plusieurs hubs. Le trafic qui doit traverser plusieurs hubs doit respecter une topologie parallèle qui ne filtre pas le trafic privé via un hub virtuel sécurisé, mais qui le laisse plutôt passer.

Ajout de réseaux spoke

Lorsque vous ajoutez des réseaux spoke, ils respectent les contraintes définies dans la topologie de réseau de départ. Plus précisément, chaque réseau spoke est associé à la table de routage par défaut qui se trouve dans son hub régional, et le pare-feu est configuré pour sécuriser à la fois le trafic Internet et le trafic privé. La capture d’écran suivante présente un exemple de configuration :

Figure 2 : Configuration de sécurité des connexions au réseau virtuel dans le hub virtuel

Principaux défis

La topologie de réseau de départ rend difficile la configuration DNS des points de terminaison privés.

Alors que l’utilisation d’un Virtual WAN vous offre une expérience de hub managé, la capacité à influencer la configuration du hub virtuel ou la possibilité d’y ajouter d’autres composants est en contrepartie limitée. Une topologie hub-and-spoke traditionnelle vous permet d’isoler des charges de travail dans les spokes tout en partageant des services réseau courants, tels que des enregistrements DNS, dans le hub automanagé. Vous liez généralement la zone DNS privée au réseau hub afin qu’Azure DNS puisse résoudre les adresses IP de point de terminaison privé des clients.

Toutefois, il n’est pas possible de lier des zones DNS privées aux hubs Virtual WAN. Par conséquent, toute résolution DNS qui se produit dans le hub ne connaît pas les zones privées. Plus précisément, il s’agit d’un problème du Pare-feu Azure, le fournisseur DNS configuré pour les spokes de charge de travail, qui utilise DNS pour la résolution d’un nom de domaine complet.

Lorsque vous utilisez des hubs Virtual WAN, il semble intuitif de lier des zones DNS privées aux réseaux virtuels spoke dans lesquels des charges de travail attendent une résolution DNS. Toutefois, comme indiqué dans l’architecture, le proxy DNS est activé sur les pare-feu régionaux et on s’attend à ce que tous les spokes utilisent leur pare-feu régional en tant que source DNS. Azure DNS est appelé à partir du pare-feu plutôt que du réseau de la charge de travail. Par conséquent, les liens des zones DNS privées sur le réseau de la charge de travail ne sont pas utilisés dans la résolution.

Notes

Pour configurer le pare-feu régional en tant que fournisseur DNS du spoke, définissez le serveur DNS personnalisé sur le réseau virtuel spoke pour qu’il pointe vers l’adresse IP privée du pare-feu plutôt que sur la valeur DNS Azure normale.

Étant donné la complexité qui résulte de l’activation du proxy DNS sur les pare-feu régionaux, examinons les raisons de son activation.

Les règles réseau du Pare-feu Azure prennent en charge les limites basées sur le nom de domaine complet afin de contrôler plus précisément le trafic de sortie que les règles d’application ne gèrent pas. Cette fonctionnalité nécessite l’activation du proxy DNS. Une utilisation courante consiste à limiter le trafic NTP (Network Time Protocol) aux points de terminaison connus, tels que time.windows.com.
Les équipes de sécurité peuvent bénéficier de la journalisation des requêtes DNS. Le Pare-feu Azure dispose d’une prise en charge intégrée de la journalisation des requêtes DNS, ainsi exiger que toutes les ressources spoke utilisent le pare-feu Azure en tant que fournisseur DNS garantit une large couverture de journalisation.

Pour illustrer les défis, les sections suivantes décrivent deux configurations. Parmi lesquelles un exemple simple fonctionnel et un exemple plus complexe non fonctionnel, mais dont l’échec est instructif.

Scénario fonctionnel

L’exemple suivant est une configuration de point de terminaison privé de base. Un réseau virtuel contient un client qui nécessite l’utilisation d’un service PaaS au moyen d’un point de terminaison privé. Une zone DNS privée liée au réseau virtuel comporte un enregistrement A qui résout le nom de domaine complet du service en adresse IP privée du point de terminaison privé. Le diagramme suivant illustre le flux.

Figure 3 : Configuration DNS de base pour des points de terminaison privés

Téléchargez un fichier Visio de cette architecture.

Le client émet une requête vers stgworkload00.blob.core.windows.net.
Azure DNS, le serveur DNS configuré pour le réseau virtuel, est interrogé sur l’adresse IP de stgworkload00.blob.core.windows.net.

L’exécution de la commande suivante à partir de la machine virtuelle (VM) montre que la machine virtuelle est configurée pour utiliser Azure DNS (168.63.129.16) en tant que fournisseur DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
La zone DNS privée privatelink.blob.core.windows.net est liée au réseau virtuel de la charge de travail, ainsi, Azure DNS intègre les enregistrements du réseau virtuel de la charge de travail dans sa réponse.
Étant donné qu’un enregistrement A existe dans la zone DNS privée qui mappe le nom de domaine complet, stgworkload00.privatelink.blob.core.windows.net, sur l’adresse IP privée du point de terminaison privé, l’adresse IP privée 10.1.2.4 est retournée.

L’exécution de la commande suivante à partir de la machine virtuelle résout le nom de domaine complet du compte de stockage en adresse IP privée du point de terminaison privé.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
La requête est émise à l’adresse IP privée du point de terminaison privé qui, dans ce cas, est 10.1.2.4.
La requête est routée via Private Link vers le compte de stockage.

La conception fonctionne, car Azure DNS :

est le serveur DNS configuré pour le réseau virtuel.
connaît la zone DNS privée liée.
résout les requêtes DNS à l’aide des valeurs de la zone.

Scénario non fonctionnel

L’exemple suivant est une tentative naïve d’utilisation des points de terminaison privés dans la topologie de réseau de départ. Il n’est pas possible de lier une zone DNS privée à un hub Virtual WAN. Par conséquent, lorsque des clients sont configurés pour utiliser le pare-feu en tant que serveur DNS, les requêtes DNS sont transférées à Azure DNS à partir du hub virtuel, qui n’est pas lié à une zone DNS privée. Azure DNS ne sait pas comment résoudre la requête autrement qu’en fournissant la valeur par défaut, qui est l’adresse IP publique.

Figure 4 : Tentative naïve d’utilisation des points de terminaison privés dans la topologie de réseau de départ

Téléchargez un fichier Visio de cette architecture.

Le client émet une requête vers stgworkload00.blob.core.windows.net.

L’exécution de la commande suivante à partir de la VM montre que la VM est configurée pour utiliser le pare-feu du hub virtuel en tant que fournisseur DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
Le proxy DNS est activé sur le pare-feu avec le paramètre par défaut pour transférer des requêtes à Azure DNS. La requête est transférée à Azure DNS.
Azure DNS ne peut pas résoudre stgworkload00.blob.core.windows.net en adresse IP privée du point de terminaison privé pour les raisons suivantes :
1. Une zone DNS privée ne peut pas être liée à un hub Virtual WAN.
2. Azure DNS ne connaît pas de zone DNS privée liée au réseau virtuel de la charge de travail, car le serveur DNS configuré pour le réseau virtuel de la charge de travail est le Pare-feu Azure. Azure DNS retourne l’adresse IP publique du compte de stockage.
L’exécution de la commande suivante à partir de la machine virtuelle résout le nom de domaine complet du compte de stockage en adresse IP publique du compte de stockage.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Étant donné que le Pare-feu Azure proxyse des requêtes DNS, nous sommes en mesure de les enregistrer. Voici des exemples de journaux de proxy DNS du Pare-feu Azure.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
Le client ne reçoit pas l’adresse IP privée du point de terminaison Private Link et ne peut pas établir de connexion privée au compte de stockage.

Le comportement ci-dessus est normal. C’est le problème que les scénarios gèrent.

Scénarios

Bien que les solutions à ce problème soient similaires, l’analyse des scénarios de charge de travail courants montre comment les solutions répondent aux exigences de différentes situations. La plupart des scénarios comportent un client qui accède à un ou plusieurs services PaaS par un point de terminaison privé. Ils adhèrent à la topologie de réseau de départ, mais ont des exigences de charge de travail différentes. Les scénarios commencent simplement, avec un client qui accède à un seul service PaaS régional. Ils deviennent progressivement plus complexes, ajoutant plus de visibilité réseau, de régions et de services PaaS.

Dans la plupart des scénarios, le client est implémenté en tant que machine virtuelle et le service PaaS auquel le client accède est un compte de stockage. Vous devez considérer les machines virtuelles comme un substitut de toute ressource Azure dont la carte réseau est exposée sur un réseau virtuel, comme les Virtual Machine Scale Sets, les nœuds Azure Kubernetes Service ou tout autre service qui route de la même manière.

Important

L’implémentation Private Link du compte stockage Azure peut différer de manière subtile des autres services PaaS, mais pour beaucoup, elle correspond bien. Par exemple, certains services suppriment les enregistrements de nom de domaine complet lorsqu’ils sont exposés via Private Link, ce qui peut entraîner des comportements différents, mais ces différences ne sont généralement pas un facteur dans les solutions de ces scénarios.

Chaque scénario commence par l’état final souhaité et détaille la configuration requise pour passer de la topologie de réseau de départ à l’état final souhaité. La solution de chaque scénario s’appuie sur le modèle d’extensions de hub virtuel. Ce modèle explique comment exposer des services partagés de manière isolée et sécurisée, en tant qu’extension conceptuelle d’un hub régional. Le tableau suivant contient des liens vers le modèle d’extension de hub virtuel et les scénarios.

Guide	Description
PaaS dédié à une seule région	Une charge de travail dans une seule région accède à une ressource PaaS dédiée.

Étapes suivantes

Lire le scénario de ressource PaaS dédiée à une seule région

Guide sur Private Link et DNS dans Azure Virtual WAN