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 l’adressage IP public. Pour chaque service, vous configurez un point de terminaison privé qui utilise une adresse IP privée à partir 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 se 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, votre configuration DNS, sont des facteurs clés dans la prise en charge de la connectivité de point de terminaison privé aux services. Cet article est l’une des séries d’articles qui fournissent des conseils sur l’implémentation de différents scénarios Private Link. Même si aucun des scénarios ne correspond exactement à votre situation, vous devez être en mesure d’adapter les conceptions pour répondre à vos besoins.

Démarrage de la topologie du réseau

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

Figure 1 : Démarrage de la topologie de réseau pour tous les scénarios DNS et de point de terminaison privé

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-spoke implémenté avec Azure Virtual WAN.
Il existe deux régions, chacune avec un hub virtuel sécurisé par le pare-feu Azure régional.
Chaque hub virtuel régional sécurisé a les paramètres de sécurité suivants pour les connexions de réseau virtuel Azure :
- 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 qui transite de spoke vers spoke transite par le pare-feu du hub régional.
Chaque hub virtuel régional est sécurisé avec le Pare-feu Azure. Les pare-feu du hub régional ont les paramètres suivants :
- Serveurs DNS : par défaut (Azure fourni) : le pare-feu du hub régional utilise explicitement Azure DNS pour la résolution de 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 des requêtes à Azure DNS pour les valeurs non mises en cache.
- Le pare-feu consigne les évaluations des règles et les demandes de proxy DNS vers un espace de travail Log Analytics qui se trouve dans la même région. La journalisation de ces événements est une exigence courante de journalisation de la sécurité réseau.
Chaque spoke de réseau virtuel connecté a son serveur DNS par défaut configuré pour être l’adresse IP privée du pare-feu du hub régional. Sinon , l’évaluation de la règle de nom de domaine complet peut être hors synchronisation.

Routage multirégion

Les hubs Virtual WAN sécurisés prennent en charge une prise en charge limitée de la connectivité entre hubs lorsqu’il existe plusieurs hubs virtuels sécurisés. Cette limitation affecte les scénarios multi-hub, intrarégion et inter-régions. Par conséquent, la topologie réseau ne facilite pas directement le filtrage du trafic privé et interrégion via le Pare-feu Azure. La prise en charge de cette fonctionnalité est fournie à l’aide de l’intention de routage et des stratégies de routage du hub Virtual WAN. Cette fonctionnalité est actuellement en préversion.

Pour cette série d’articles, l’hypothèse est que le trafic sécurisé interne ne traverse pas plusieurs hubs. Le trafic qui doit traverser plusieurs hubs doit le faire sur une topologie parallèle qui ne filtre pas le trafic privé par le biais d’un hub virtuel sécurisé, mais le laisse passer à la place.

Ajout de réseaux spoke

Lorsque vous ajoutez des réseaux spoke, ils suivent les contraintes définies dans la topologie de réseau de démarrage. 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 le trafic Internet et privé. La capture d’écran suivante montre un exemple de configuration :

Figure 2 : Configuration de la sécurité pour les connexions de réseau virtuel dans le hub virtuel

Principaux défis

La topologie de réseau de démarrage crée des défis pour la configuration du DNS pour les points de terminaison privés.

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

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

Lorsque vous utilisez des hubs Virtual WAN, il semble intuitif que vous lieriez des zones DNS privées aux réseaux virtuels spoke où les 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 tous les spokes utilisent leur pare-feu régional comme source DNS. Azure DNS est appelé à partir du pare-feu au lieu du réseau de la charge de travail. Par conséquent, les liaisons de zone DNS privées sur le réseau de charge de travail ne sont pas utilisées dans la résolution.

Remarque

Pour configurer le pare-feu régional comme 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 au lieu de la valeur Azure DNS normale.

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

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 que le proxy DNS soit activé. Une utilisation courante limite le trafic NTP (Network Time Protocol) aux points de terminaison connus, tels que time.windows.com.
Les équipes de sécurité peuvent tirer parti de la journalisation des requêtes DNS. Le Pare-feu Azure prend en charge la journalisation des requêtes DNS, ce qui exige que toutes les ressources spoke utilisent le Pare-feu Azure comme fournisseur DNS garantit une couverture de journalisation étendue.

Pour illustrer les défis, les sections suivantes décrivent deux configurations. Il existe un exemple simple qui fonctionne, et un plus complexe qui ne le fait pas, mais son échec est instructif.

Scénario de travail

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 a un enregistrement A qui résout le nom de domaine complet du service en adresse IP privée du point de terminaison privé. Le schéma suivant illustre le flux :

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

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

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

L’exécution de la commande suivante à partir de la machine virtuelle illustre que la machine virtuelle est configurée pour utiliser Azure DNS (168.63.129.16) comme 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 privatelink.blob.core.windows.net DNS privée est liée au réseau virtuel de charge de travail. Azure DNS incorpore donc les enregistrements du réseau virtuel de 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à 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 acheminée via Private Link vers le compte de stockage.

La conception fonctionne parce qu’Azure DNS :

Serveur DNS configuré pour le réseau virtuel.
Est conscient de la zone DNS privée liée.
Résout les requêtes DNS à l’aide des valeurs de la zone.

Scénario de non-travail

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

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

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

Le client émet une demande de stgworkload00.blob.core.windows.net.

L’exécution de la commande suivante à partir de la machine virtuelle illustre que la machine virtuelle 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 pare-feu a le proxy DNS activé avec le paramètre par défaut pour transférer des requêtes vers Azure DNS. La requête est transférée à Azure DNS.
Azure DNS ne peut pas résoudre stgworkload00.blob.core.windows.net l’adresse IP privée du point de terminaison privé, car :
1. Une zone DNS privée ne peut pas être liée à un hub Virtual WAN.
2. Azure DNS n’est pas conscient d’une zone DNS privée liée au réseau virtuel de charge de travail, car le serveur DNS configuré pour le réseau virtuel de charge de travail est le Pare-feu Azure. Azure DNS répond avec 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 sur l’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 proxye des requêtes DNS, nous sommes en mesure de les journaliser. 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 attendu. C’est le problème que les scénarios résolvent.

Scénarios

Bien que les solutions à ce problème soient similaires, les scénarios de charge de travail courants montrent comment les solutions répondent aux exigences de différentes situations. La plupart des scénarios se composent d’un client qui accède à un ou plusieurs services PaaS sur un point de terminaison privé. Ils adhèrent à la topologie de réseau de départ, mais diffèrent dans leurs exigences de charge de travail. Les scénarios commencent simplement par un client qui accède à un seul service PaaS régional. Ils sont plus complexes de façon incrémentielle, en ajoutant davantage 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 étant autonomes pour toutes les ressources Azure qui disposent d’une carte réseau exposée sur un réseau virtuel, comme les groupes de machines virtuelles identiques, les nœuds Azure Kubernetes Service ou tout autre service qui achemine de la même façon.

Important

L’implémentation private Link pour le compte de stockage Azure peut différer d’autres services PaaS de manière subtile, mais elle s’aligne correctement pour de nombreuses personnes. 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 pour 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émarrage à l’état final souhaité. La solution à chaque scénario tire parti du 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 à un hub régional. Le tableau suivant contient des liens vers le modèle d’extension de hub virtuel et les scénarios.

Guide	Descriptif
Région unique, PaaS dédiée	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é à la région unique