Déployer un NetScaler® pour une zone privée Azure DNS

Azure DNS est un service de l’infrastructure Microsoft Azure pour l’hébergement de domaines DNS et la résolution de noms.

Les zones privées Azure DNS sont un service axé sur la résolution de noms de domaine dans un réseau privé. Avec les zones privées, les clients peuvent utiliser leurs propres noms de domaine personnalisés plutôt que les noms fournis par Azure disponibles aujourd’hui.

NetScaler, la solution de livraison d’applications leader, est la mieux adaptée pour fournir des capacités d’équilibrage de charge et de GSLB pour une zone privée Azure DNS. En s’abonnant à la zone privée Azure DNS, l’entreprise peut compter sur la puissance et l’intelligence du Global Server Load Balancing (GSLB) de NetScaler pour distribuer le trafic intranet entre les charges de travail dans plusieurs zones géographiques et entre les centres de données, connectés via des tunnels VPN sécurisés. Cette collaboration garantit aux entreprises un accès transparent à une partie de leur charge de travail qu’elles souhaitent déplacer vers le cloud public Azure.

Présentation d’Azure DNS

Le système de noms de domaine (DNS) est responsable de la traduction ou de la résolution d’un nom de service en son adresse IP. Service d’hébergement pour les domaines DNS, Azure DNS assure la résolution de noms en utilisant l’infrastructure Microsoft Azure. En plus de prendre en charge les domaines DNS accessibles sur Internet, Azure DNS prend désormais également en charge les domaines DNS privés.

Azure DNS fournit un service DNS fiable et sécurisé pour gérer et résoudre les noms de domaine dans un réseau virtuel sans nécessiter de solution DNS personnalisée. En utilisant des zones DNS privées, vous pouvez utiliser vos propres noms de domaine personnalisés plutôt que les noms fournis par Azure. L’utilisation de noms de domaine personnalisés vous aide à adapter l’architecture de votre réseau virtuel aux besoins de votre organisation. Il assure la résolution de noms pour les machines virtuelles (VM) au sein d’un réseau virtuel et entre les réseaux virtuels. De plus, les clients peuvent configurer des noms de zone avec une vue en horizon partagé, ce qui permet à une zone DNS privée et publique de partager un nom.

Pourquoi NetScaler GSLB pour la zone privée Azure DNS ?

Dans le monde d’aujourd’hui, les entreprises souhaitent faire passer leurs charges de travail des environnements sur site au cloud Azure. La transition vers le cloud leur permet d’optimiser le délai de commercialisation, les dépenses d’investissement/le prix, la facilité de déploiement et la sécurité. Le service de zone privée Azure DNS offre une proposition unique aux entreprises qui transfèrent une partie de leurs charges de travail vers le cloud Azure. Ces entreprises peuvent créer leur nom DNS privé, qu’elles utilisaient depuis des années dans les déploiements sur site, lorsqu’elles utilisent le service de zone privée. Avec ce modèle hybride de serveurs d’applications intranet étant sur site et dans le cloud Azure connectés via des tunnels VPN sécurisés, le défi est d’avoir un accès transparent à ces applications intranet. NetScaler résout ce cas d’utilisation unique avec sa fonction d’équilibrage de charge global, qui achemine le trafic d’application vers les charges de travail/serveurs distribués les plus optimaux, qu’ils soient sur site ou dans le cloud Azure, et fournit l’état de santé du serveur d’applications.

Cas d’utilisation

Les utilisateurs d’un réseau sur site et de différents réseaux virtuels Azure peuvent se connecter aux serveurs les plus optimaux d’un réseau interne pour accéder au contenu requis. Cela garantit que l’application est toujours disponible, que les coûts sont optimisés et que l’expérience utilisateur est bonne. La gestion du trafic privé Azure (PTM) est l’exigence principale ici. Azure PTM garantit que les requêtes DNS des utilisateurs sont résolues en une adresse IP privée appropriée du serveur d’applications.

Solution du cas d’utilisation

NetScaler inclut la fonction d’équilibrage de charge global des serveurs (GSLB) pour répondre aux exigences d’Azure PTM. GSLB agit comme un serveur DNS, qui reçoit les requêtes DNS et les résout en une adresse IP appropriée pour fournir :

• Basculement transparent basé sur DNS.
• Migration progressive du local vers le cloud.
• Test A/B d’une nouvelle fonctionnalité.

Parmi les nombreuses méthodes d’équilibrage de charge prises en charge, les méthodes suivantes peuvent être utiles dans cette solution :

1. Tourniquet (Round Robin)

2. Proximité statique (sélection de serveur basée sur l’emplacement). Elle peut être déployée de deux manières :

   1. GSLB basé sur le sous-réseau client EDNS (ECS) sur NetScaler.
   2. Déployer un redirecteur DNS pour chaque réseau virtuel.

Topologie

La figure suivante représente le déploiement GSLB de NetScaler pour une zone DNS privée Azure.

Un utilisateur peut accéder à n’importe quel serveur d’applications, soit sur Azure, soit sur site, en fonction de la méthode GSLB de NetScaler dans une zone DNS privée Azure. Tout le trafic entre le réseau virtuel sur site et Azure passe uniquement par un tunnel VPN sécurisé. Le trafic d’application, le trafic DNS et le trafic de surveillance sont présentés dans la topologie précédente. En fonction de la redondance requise, NetScaler et le redirecteur DNS peuvent être déployés dans les réseaux virtuels et les centres de données. Par souci de simplicité, un seul NetScaler est présenté ici, mais nous recommandons au moins un ensemble de NetScaler et de redirecteur DNS pour la région Azure. Toutes les requêtes DNS des utilisateurs sont d’abord acheminées vers le redirecteur DNS qui contient des règles définies pour transférer les requêtes vers un serveur DNS approprié.

Configuration de NetScaler pour la zone DNS privée Azure

Produits et versions testés :

Remarque :

Le déploiement est testé et reste le même avec NetScaler version 12.0 et ultérieure.

Prérequis

Voici les prérequis généraux.

• Compte de portail Microsoft Azure avec un abonnement valide.
• Assurez la connectivité (tunnel VPN sécurisé) entre le réseau sur site et le cloud Azure. Pour configurer un tunnel VPN sécurisé dans Azure, consultez Pas à pas : Configuration d’une passerelle VPN site à site entre Azure et les locaux.

Description de la solution

Si vous souhaitez héberger une application de zone privée DNS Azure (rr.ptm.mysite.net) qui s’exécute sur HTTPs et est déployée sur Azure et sur site avec un accès intranet basé sur la méthode d’équilibrage de charge GSLB de type tourniquet. Pour réaliser ce déploiement, activez GSLB pour la zone DNS privée Azure avec NetScaler, qui comprend les configurations suivantes :

1. Configurez la configuration Azure et sur site.
2. Appliance NetScaler sur le réseau virtuel Azure.

Configurer la configuration Azure et sur site

Comme indiqué dans la topologie, configurez le réseau virtuel Azure (VNet A, VNet B dans ce cas) et la configuration sur site.

1. Créez une zone DNS privée Azure avec le nom de domaine (mysite.net).
2. Créez deux réseaux virtuels (VNet A, VNet B) dans un modèle Hub-and-Spoke dans une région Azure.
3. Déployez un serveur d’applications, un redirecteur DNS, un client Windows 10 Pro, NetScaler dans le VNet A.
4. Déployez un serveur d’applications et un redirecteur DNS si des clients se trouvent dans le VNet B.
5. Déployez un serveur d’applications, un redirecteur DNS et un client Windows 10 Pro sur site.

Zone DNS privée Azure

Créez une zone DNS privée Azure avec un nom de domaine.

1. Connectez-vous au portail Azure et sélectionnez ou créez un tableau de bord.
2. Cliquez sur créer une ressource et recherchez la zone DNS à créer (mysite.net dans ce cas) zone DNS privée Azure avec le nom de domaine (mysite.net).

Réseaux virtuels Azure (VNet A, VNet B) dans un modèle Hub-and-Spoke

Créez deux réseaux virtuels (VNet A, VNet B) dans un modèle Hub-and-Spoke dans une région Azure.

1. Créez deux réseaux virtuels.

2. Sélectionnez le même tableau de bord et cliquez sur créer une ressource, puis recherchez les réseaux virtuels pour créer deux réseaux virtuels, à savoir VNet A et VNet B, dans la même région et les appairer pour former un modèle Hub-and-Spoke, comme illustré dans l’image suivante. Pour plus d’informations sur la configuration d’une topologie hub-and-spoke, consultez Implémenter une topologie de réseau hub-and-spoke dans Azure.

   

   

Appairage de VNet A à VNet B

Pour appairer VNet A et VNet B :

1. Cliquez sur Appairages dans le menu Paramètres de VNet A et appairez VNet B.

2. Activez Autoriser le trafic transféré et Autoriser le transit de passerelle comme illustré dans l’image suivante.

   

L’image suivante représente l’appairage réussi de VNet A à VNet B.

Appairage de VNet B à VNet A

Pour appairer VNet B et VNet A :

1. Cliquez sur Appairages dans le menu Paramètres de VNet B et appairez VNet A.
2. Activez Autoriser le trafic transféré et utilisez des passerelles distantes comme illustré dans l’image suivante.

![VNet B to A](/en-us/vpx/media/image-07.png)

L’image suivante représente l’appairage réussi de VNet B à VNet A.

Déployer un serveur d’applications, un redirecteur DNS, un client Windows 10 Pro, NetScaler dans VNet A

Nous discutons brièvement du serveur d’applications, du redirecteur DNS, du client Windows 10 Pro et de NetScaler sur VNet A.

1. Sélectionnez le même tableau de bord, cliquez sur Créer une ressource.
2. Recherchez les instances respectives et attribuez une adresse IP à partir du sous-réseau du VNet A.

Serveur d’applications

Le serveur d’applications n’est rien d’autre que le serveur web (serveur HTTP) où un serveur Ubuntu 16.04 est déployé en tant qu’instance sur la VM Azure ou locale. Pour en faire un serveur web, à l’invite de commande, tapez :

sudo apt install apache2

Client Windows 10 Pro

Lancez une instance Windows 10 Pro en tant que machine cliente sur le VNet A et sur site.

NetScaler

NetScaler complète la zone privée Azure DNA par un contrôle de santé et des analyses de NetScaler MAS. Lancez un NetScaler depuis Azure Marketplace en fonction de vos besoins ; ici, nous avons utilisé NetScaler (BYOL) pour ce déploiement.

Pour les étapes détaillées sur la façon de déployer NetScaler sur Microsoft Azure. Voir Déployer une instance NetScaler VPX sur Microsoft Azure.

Après le déploiement, utilisez l’adresse IP de NetScaler pour configurer NetScaler GSLB.

Redirecteur DNS

Il est utilisé pour transférer les requêtes client des domaines hébergés liés à NetScaler GSLB (adresse IP ADNS). Lancez un serveur Ubuntu 16.04 en tant qu’instance Linux (serveur Ubuntu 16.04) et consultez l’URL ci-dessous pour savoir comment le configurer en tant que redirecteur DNS.

Remarque :

Pour la méthode d’équilibrage de charge GSLB Round Robin, un redirecteur DNS par région Azure est suffisant, mais pour la proximité statique, nous avons besoin d’un redirecteur DNS par réseau virtuel.

1. Après avoir déployé le redirecteur, modifiez les paramètres du serveur DNS du réseau virtuel A de la valeur par défaut à une valeur personnalisée avec l’adresse IP du redirecteur DNS du VNet A, comme illustré dans l’image suivante.
2. Modifiez le fichier named.conf.options dans le redirecteur DNS du VNet A pour ajouter des règles de redirection pour le domaine (mysite.net) et le sous-domaine (ptm.mysite.net) vers l’adresse IP ADNS du GSLB NetScaler.
3. Redémarrez le redirecteur DNS pour que les modifications apportées au fichier named.conf.options soient prises en compte.

Paramètres du redirecteur DNS du VNet A

    zone "mysite.net" {
               type forward;
    forwarders { 168.63.129.16; };
    };
    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
 <!--NeedCopy-->

Remarque :

Pour l’adresse IP de la zone de domaine (“mysite.net”), utilisez l’adresse IP DNS de votre région Azure. Pour l’adresse IP de la zone de sous-domaine (“ptm.mysite.net”), utilisez toutes les adresses IP ADNS de vos instances GSLB.

Déployer un serveur d’applications et un redirecteur DNS si des clients se trouvent dans le VNet B

1. Pour le réseau virtuel B, sélectionnez le même tableau de bord, cliquez sur créer une ressource.
2. Recherchez les instances respectives et attribuez une adresse IP à partir du sous-réseau du VNet B.
3. Lancez le serveur d’applications et le redirecteur DNS s’il y a un équilibrage de charge GSLB de proximité statique similaire au VNet A.

4. Modifiez les paramètres du redirecteur DNS du VNet B dans named.conf.options comme indiqué dans le paramètre suivant :

   Paramètres du redirecteur DNS du VNet B

    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
<!--NeedCopy-->

L’image suivante représente les paramètres du redirecteur DNS du VNet B :

Déployer un serveur d’applications, un redirecteur DNS et un client Windows 10 Pro sur site

1. Pour les déploiements sur site, lancez les machines virtuelles sur du matériel nu et installez le serveur d’applications, le redirecteur DNS et le client Windows 10 Pro de manière similaire au VNet A.

2. Modifiez les paramètres du redirecteur DNS sur site dans le named.conf.options comme indiqué dans l’exemple suivant.

Paramètres du redirecteur DNS sur site

    zone "mysite.net" {
               type forward;
               forwarders { 10.8.0.6; };
    };
    zone "ptm.mysite.net" {
        type forward;
        forwarders { 10.8.0.5; };
    };
<!--NeedCopy-->

Pour mysite.net, nous avons attribué l’adresse IP du redirecteur DNS du VNet A au lieu de l’adresse IP du serveur de zone DNS privé Azure, car il s’agit d’une adresse IP spéciale qui n’est pas accessible depuis les locaux. Par conséquent, cette modification est requise dans le paramètre du redirecteur DNS sur site.

Configurez le NetScaler sur le réseau virtuel Azure

Comme indiqué dans la topologie, déployez le NetScaler sur le réseau virtuel Azure (VNet A dans ce cas) et accédez-y via l’interface graphique du NetScaler.

Configuration du GSLB NetScaler

1. Créez un service ADNS.
2. Créez des sites locaux et distants.
3. Créez des services pour les serveurs virtuels locaux.
4. Créez des serveurs virtuels pour les services GSLB.

Ajouter un service ADNS

1. Connectez-vous à l’interface graphique du NetScaler.
2. Dans l’onglet Configuration, accédez à Gestion du trafic > Équilibrage de charge > Services.
3. Ajoutez un service. Nous vous recommandons de configurer le service ADNS en TCP et en UDP, comme indiqué dans l’image suivante :

Ajouter des sites GSLB

1. Ajoutez des sites locaux et distants entre lesquels le GSLB sera configuré.

2. Sous l’onglet Configuration, accédez à Gestion du trafic > GSLB > Sites GSLB. Ajoutez un site comme indiqué dans l’exemple suivant et répétez la même procédure pour les autres sites.

   

   

   

Ajouter des services GSLB

1. Ajoutez des services GSLB pour les serveurs virtuels locaux et distants qui équilibrent la charge des serveurs d’applications.
2. Sous l’onglet Configuration, accédez à Gestion du trafic > GSLB > Services GSLB.
3. Ajoutez les services comme indiqué dans les exemples suivants.

4. Liez le moniteur HTTP pour vérifier l’état du serveur.

   

   

5. Après avoir créé le service, accédez à l’onglet Paramètres avancés à l’intérieur du service GSLB.

6. Cliquez sur Ajouter un moniteur pour lier le service GSLB à un moniteur HTTP afin de faire passer l’état du service à UP.

7. Une fois que vous avez lié le moniteur HTTP, l’état des services est marqué comme UP, comme indiqué dans l’image suivante :

Ajouter un serveur virtuel GSLB

Ajoutez un serveur virtuel GSLB via lequel les services GSLB alias des serveurs d’applications sont accessibles.

1. Dans l’onglet Configuration, accédez à Gestion du trafic > GSLB > Serveurs virtuels GSLB.
2. Ajoutez les serveurs virtuels comme indiqué dans l’exemple suivant.

3. Lie-lui les services GSLB et le nom de domaine.

   

4. Après avoir créé le serveur virtuel GSLB et sélectionné la méthode d’équilibrage de charge appropriée (Round Robin dans ce cas), liez les services GSLB et les domaines pour terminer l’étape.

   

5. Accédez à l’onglet Paramètres avancés à l’intérieur du serveur virtuel et cliquez sur l’onglet Ajouter des domaines pour lier un domaine.

6. Accédez à Avancé > Services et cliquez sur la flèche pour lier un service GSLB et lier les trois services (VNet A, VNet B, Sur site) au serveur virtuel.

   

   Après avoir lié les services GSLB et le domaine au serveur virtuel, il apparaît comme indiqué dans l’image suivante :

   

Vérifiez si le serveur virtuel GSLB est opérationnel et sain à 100 %. Lorsque le moniteur indique que le serveur est opérationnel et sain, cela signifie que les sites sont synchronisés et que les services back-end sont disponibles.

Pour tester le déploiement, accédez à l’URL du domaine rr.ptm.mysite.net depuis une machine cliente cloud ou une machine cliente sur site. Si vous y accédez depuis une machine cliente Windows cloud, assurez-vous que le serveur d’applications sur site est accessible dans une zone DNS privée sans avoir besoin de solutions DNS tierces ou personnalisées.