Concevoir une solution DNS hybride avec Azure

Cette architecture de référence montre comment concevoir une solution DNS (Domain Name System) hybride pour résoudre les noms des charges de travail hébergées localement et dans Microsoft Azure. Cette architecture fonctionne pour les utilisateurs et des systèmes qui se connectent à partir d’un site local et de l’Internet public.

Architecture

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

Workflow

L’architecture est constituée des composants suivants :

• Réseau local. Le réseau local représente un centre de données unique connecté à Azure via une connexion Azure ExpressRoute ou de réseau privé virtuel (VPN). Dans ce scénario, les composants suivants constituent le réseau local :
  • Serveurs DNS. Ces serveurs sont deux serveurs sur lesquels le service DNS est installé, qui font office d’outils de résolution/redirection. Ces serveurs DNS sont utilisés pour tous les ordinateurs du réseau local en tant que serveurs DNS. Des enregistrements doivent être créés sur ces serveurs pour tous les points de terminaison locaux et dans Azure.
  • Passerelle. La passerelle représente soit un appareil VPN, soit une connexion ExpressRoute utilisée pour se connecter à Azure.
• Abonnement hub. L’abonnement hub représente un abonnement Azure utilisé pour héberger des ressources de connectivité, de gestion et de mise en réseau qui sont partagées entre plusieurs charges de travail hébergées dans Azure. Ces ressources peuvent être réparties en plusieurs abonnements, comme décrit dans l’architecture à l’échelle de l’entreprise.

  Notes

  Le réseau virtuel hub peut être remplacé par un hub de réseau virtuel étendu (WAN), auquel cas les serveurs DNS doivent être hébergés dans un autre réseau virtuel (VNet) Azure. Dans l’architecture à l’échelle de l’entreprise, ce réseau virtuel est conservé dans son propre abonnement appelé Abonnement d’identité.

  • Sous-réseau Azure Bastion. Le service Azure Bastion dans le réseau virtuel hub est utilisé pour la communication à distance avec les machines virtuelles dans le hub et les réseaux virtuels en étoile, à partir de l’Internet public à des fins de maintenance.
  • Sous-réseau de point de terminaison privé. Le sous-réseau de point de terminaison privé héberge des points de terminaison privés pour les charges de travail hébergées sur Azure dans des réseaux virtuels qui ne sont pas appairés au hub. Avec ce type de réseau virtuel déconnecté, ses adresses IP peuvent entrer en conflit avec d’autres adresses IP utilisées dans Azure et en local.
  • Sous-réseau de passerelle. Le sous-réseau de passerelle héberge la passerelle VPN Azure ou ExpressRoute qui est utilisée pour fournir la connectivité au centre de données local.
  • Sous-réseau de services partagés. Le sous-réseau de services partagés héberge les services partagés entre plusieurs charges de travail Azure. Dans ce scénario, ce sous-réseau héberge des machines virtuelles exécutant Windows ou Linux, qui sont également utilisées en tant que serveurs DNS. Ces serveurs DNS hébergent les mêmes zones DNS que les serveurs locaux.
• Abonnement connecté. L’abonnement connecté représente une collection de charges de travail qui nécessitent un réseau virtuel et une connectivité au réseau local.
  • Peering de réseaux virtuels. Ce composant est une connexion de peering vers le réseau virtuel hub. Cette connexion permet la connexion du réseau local au réseau en étoile, puis en retour via le réseau virtuel hub.
  • Sous-réseau par défaut. Le sous-réseau par défaut contient un exemple de charge de travail.
    • web-vmss. Cet exemple de groupe de machines virtuelles identiques héberge une charge de travail dans Azure, qui est accessible à partir d’un emplacement local, d’Azure et de l’Internet public.
    • Équilibreur de charge. L’équilibreur de charge permet d’accéder à une charge de travail qu’une série de machines virtuelles hébergent. L’adresse IP de cet équilibreur de charge dans le sous-réseau par défaut doit être utilisée pour accéder à la charge de travail à partir d’Azure et du centre de données local.
  • Sous-réseau AppGateway. Il s’agit du sous-réseau requis pour le service Azure Application Gateway.
    • AppGateway. Le service Application Gateway permet aux utilisateurs de l’Internet public d’accéder à l’exemple de charge de travail dans le sous-réseau par défaut.
    • wkld1-pip. Il s’agit de l’adresse IP publique utilisée pour accéder à l’exemple de charge de travail à partir de l’Internet public.
• Abonnement déconnecté. L’abonnement déconnecté représente une collection de charges de travail qui n’ont pas besoin de se connecter au centre de données local et utilisent le service de liaison privée.
  • PLSSubnet. Le sous-réseau de service de liaison privée (PLSSubnet) contient une ou plusieurs ressources de service de liaison privée qui fournissent la connectivité aux charges de travail hébergées dans l’abonnement connecté.
  • Sous-réseau par défaut. Le sous-réseau par défaut contient un exemple de charge de travail.
    • web-vmss. Cet exemple de groupe de machines virtuelles identiques héberge une charge de travail dans Azure, qui est accessible à partir d’un emplacement local, d’Azure et de l’Internet public.
    • Équilibreur de charge. L’équilibreur de charge permet d’accéder à une charge de travail qu’une série de machines virtuelles hébergent. Cet équilibreur de charge est connecté au service de liaison privée pour fournir un accès aux utilisateurs provenant d’Azure et du centre de données local.
  • Sous-réseau AppGateway. Il s’agit du sous-réseau requis pour le service Application Gateway.
    • AppGateway. Le service Application Gateway permet aux utilisateurs de l’Internet public d’accéder à l’exemple de charge de travail dans le sous-réseau par défaut.
    • wkld2-pip. Il s’agit de l’adresse IP publique utilisée pour accéder à l’exemple de charge de travail à partir de l’Internet public.
  • Sous-réseau Azure Bastion. Le service Azure Bastion dans le réseau virtuel déconnecté est utilisé pour la communication à distance avec les machines virtuelles dans le hub et les réseaux virtuels en étoile, à partir de l’Internet public à des fins de maintenance.

Composants

• Réseau virtuel. Le réseau virtuel Azure (VNet) est le bloc de construction fondamental pour votre réseau privé dans Azure. Le réseau virtuel permet à de nombreux types de ressources Azure, telles que les machines virtuelles (VM) Azure, de communiquer de manière sécurisée entre elles, avec Internet et avec les réseaux locaux.

• Azure Bastion. Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell Protocol) plus sécurisé et transparent aux machines virtuelles sans aucune exposition via des adresses IP publiques.

• Passerelle VPN. La passerelle VPN envoie du trafic chiffré entre un réseau virtuel Azure et un emplacement local via l’Internet public. Vous pouvez également utiliser une passerelle VPN pour envoyer du trafic chiffré entre les réseaux virtuels Azure sur le réseau Microsoft. Une passerelle VPN est un type spécifique de passerelle de réseau virtuel.

• Private Link. Azure Private Link fournit une connectivité privée entre un réseau virtuel et la plateforme Azure en tant que service (PaaS), appartenant à un client ou à des services partenaires Microsoft. Il simplifie l’architecture réseau et sécurise la connexion entre les points de terminaison dans Azure en éliminant l’exposition des données à l’internet public.

• Application Gateway. Azure Application Gateway est un équilibreur de charge du trafic web qui vous permet de gérer le trafic vers vos applications web. Les équilibreurs de charge traditionnels fonctionnent au niveau de la couche de transport (couche OSI 4 - TCP et UDP) et acheminent le trafic en fonction de l’adresse IP et du port sources, vers une adresse IP et un port de destination.

Recommandations

Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Étendre AD DS à Azure (facultatif)

Utilisez des zones DNS intégrées dans AD DS pour héberger des enregistrements DNS pour votre centre de données local et Azure. Dans ce scénario, il existe deux ensembles de serveurs DNS AD DS : l’un localement et l’autre dans le réseau virtuel hub.

Nous vous recommandons d’étendre votre domaine AD DS à Azure. Nous vous recommandons également de configurer les réseaux virtuels en étoile de façon à ce qu’ils utilisent les serveurs DNS AD DS dans le réseau virtuel hub pour toutes les machines virtuelles dans Azure.

Configurer un DNS split-brain

Assurez-vous que DNS Split-Brain est en place pour permettre aux systèmes Azure, aux utilisateurs locaux et aux utilisateurs Internet d’accéder aux charges de travail en fonction de l’emplacement à partir duquel ils se connectent.

Pour les charges de travail connectées et déconnectées, nous recommandons les composants suivants pour la résolution DNS :

• Zones Azure DNS pour les utilisateurs Internet.
• Serveurs DNS pour les utilisateurs locaux et les systèmes Azure.
• Zones DNS privées Azure pour la résolution entre réseaux virtuels Azure.

Pour mieux comprendre cette recommandation de DNS split-brain, considérez la Charge de travail 1, pour laquelle nous allons utiliser le nom de domaine complet (FQDN) wkld1.contoso.com.

Dans ce scénario, les utilisateurs Internet doivent résoudre ce nom en adresse IP publique qu’Application Gateway expose via Wkld1-pip. Pour effectuer cette résolution, créez un enregistrement d’adresse (enregistrement A) dans Azure DNS pour l’abonnement connecté.

Les utilisateurs locaux doivent résoudre le même nom en adresse IP interne pour l’équilibreur de charge dans l’abonnement connecté. Pour effectuer cette résolution, créez un enregistrement A dans les serveurs DNS dans l’abonnement hub.

Les systèmes Azure peuvent résoudre le même nom sur une adresse IP interne pour l’équilibreur de charge dans l’abonnement connecté, soit en créant un enregistrement A dans le serveur DNS dans l’abonnement hub, soit en utilisant des zones DNS privées. Lorsque vous utilisez des zones DNS privées, vous pouvez créer manuellement un enregistrement A dans la zone DNS privée ou activer l’inscription automatique.

Utiliser des zones DNS privées pour un lien privé

Dans notre scénario, la Charge de travail 2 est hébergée dans un abonnement déconnecté, et l’accès à cette charge de travail pour les utilisateurs locaux et les systèmes Azure connectés est possible via un point de terminaison privé dans le réseau virtuel hub. Toutefois, il existe une troisième possibilité de connexion pour cette charge de travail : Systèmes Azure dans le même réseau virtuel que la Charge de travail 2.

Pour mieux comprendre les recommandations DNS pour la Charge de travail 2, nous allons utiliser le nom de domaine complet (FQDN) wkld2.contoso.com et aborder les recommandations individuelles.

Dans ce scénario, les utilisateurs Internet doivent résoudre ce nom en adresse IP publique qu’Application Gateway expose via Wkld2-pip. Pour effectuer cette résolution, créez un enregistrement A dans Azure DNS pour l’abonnement connecté.

Les utilisateurs locaux et les systèmes Azure connectés au réseau virtuel hub et aux réseaux virtuels en étoile doivent résoudre le même nom en adresse IP interne pour le point de terminaison privé dans le réseau virtuel hub. Pour effectuer cette résolution, créez un enregistrement A dans les serveurs DNS dans l’abonnement hub.

Les systèmes Azure dans le même réseau virtuel que la Charge de travail 2 doivent résoudre le nom en adresse IP de l’équilibreur de charge dans l’abonnement déconnecté. Pour effectuer cette résolution, utilisez une zone DNS privée dans Azure DNS dans cet abonnement.

Des systèmes Azure dans différents réseaux virtuels peuvent toujours résoudre l’adresse IP de la Charge de travail 2 si vous liez ces réseaux virtuels à une zone DNS privée qui héberge l’enregistrement A pour la Charge de travail 2.

Activer l’inscription automatique

Quand vous configurez une liaison de réseau virtuel avec une zone DNS privée, vous pouvez éventuellement configurer l’inscription automatique pour toutes les machines virtuelles.

Si vous utilisez un serveur DNS AD DS, configurez les machines virtuelles Windows de façon à ce qu’elles puissent utiliser des mises à jour dynamiques pour les ordinateurs Windows afin de conserver vos propres enregistrements DNS à jour dans les serveurs DNS AD DS. Nous vous recommandons d’activer les mises à jour dynamiques et de configurer les serveurs DNS de façon à n’autoriser que des mises à jour sécurisées.

Les machines virtuelles Linux prennent pas en charge les mises à jour dynamiques sécurisées. Pour les ordinateurs Linux locaux, utilisez le protocole DHCP (Dynamic Host Configuration Protocol) pour inscrire les enregistrements DNS auprès des serveurs DNS AD DS.

Pour les machines virtuelles Linux dans Azure, utilisez un processus automatisé.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Extensibilité

• Envisagez d’utiliser au moins deux serveurs DNS par région Azure ou par centres de données locaux.
• Notez comment cela se fait dans le scénario précédent, avec des serveurs DNS locaux et dans le réseau virtuel hub.

Disponibilité

• Envisagez de placer les serveurs DNS. Comme décrit dans la section des considérations relatives à la scalabilité, les serveurs DNS doivent être placés à proximité des utilisateurs et systèmes qui ont besoin d’y accéder.
  • Par région Azure. Chaque région Azure possède son propre réseau virtuel hub ou hub vWAN. Il s’agit de l’emplacement où vos serveurs DNS doivent être déployés.
  • Par centre de données local. Vous devez également disposer d’une paire de serveurs DNS par centre de données local pour les utilisateurs et systèmes dans ces emplacements.
  • Pour les charges de travail isolées (déconnectées), hébergez une zone DNS privée et une zone DNS publique pour chaque abonnement afin de gérer les enregistrements DNS split-brain.

Simplicité de gestion

• Tenez compte du besoin d’enregistrements DNS pour les services PaaS.
• Vous devez également prendre en compte la résolution DNS pour les services PaaS qui utilisent un point de terminaison privé. À cette fin, utilisez une zone DNS, et utilisez votre pipeline de DevOps pour créer des enregistrements dans les serveurs DNS.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

• Si vous avez besoin d’utiliser une validation DNSSEC, songez qu’actuellement, Azure DNS ne la prend pas en charge.
• Pour la validation DNSSEC, déployez un serveur DNS personnalisé et activez la validation DNSEC.
• Azure DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout réseau virtuel de périmètre.

DevOps

• Automatisez la configuration de cette architecture en combinant des modèles Azure Resource Manager pour la configuration de toutes les ressources. Les zones DNS privées et publiques prennent en charge la gestion complète à partir d’Azure CLI, de PowerShell, de .Net et d’API REST.
• Si vous utilisez un pipeline d’intégration et de développement continus (CI/CD) pour déployer et gérer les charges de travail dans Azure et localement, vous pouvez également configurer l’inscription automatique d’enregistrements DNS.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

• Les coûts relatifs à la zone Azure DNS sont basés sur le nombre de zones DNS hébergées dans Azure et sur le nombre de requêtes DNS reçues.
• Utiliser la calculatrice de prix Azure pour estimer les coûts. Les modèles tarifaires pour Azure DNS sont expliqués ici.
• Le modèle de facturation pour Azure ExpressRoute est basé sur des données limitées (vous êtes alors facturé par gigaoctet pour le transfert de données sortantes) ou sur des données illimitées (vous devez alors payer des frais mensuels incluant tous les transferts de données).
• Si vous utilisez un VPN au lieu de ExpressRoute, le coût dépend de la référence (SKU) de la passerelle de réseau virtuel et est facturé par heure.

Étapes suivantes

En savoir plus sur les technologies des composants :

• Présentation d’Azure DNS
• Qu’est-ce que le réseau virtuel Azure ?
• Qu’est-ce qu’Azure ExpressRoute ?
• Qu’est-ce qu’Azure Bastion ?

Ressources associées

Explorer les architectures connexes :

• Partage de fichiers cloud Azure en entreprise
• Application multiniveau avec Apache Cassandra
• SaaS mutualisé sur Azure
• Étendre un réseau local à l’aide d’ExpressRoute