Note :

Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Démarrer avec le niveau gratuit d'Oracle Cloud Infrastructure.
Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments d'Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles qui sont propres à votre environnement en nuage.

Mettre en oeuvre la haute disponibilité sur le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure

Présentation

OraStage est une entreprise leader dans le secteur de l'énergie, spécialisée dans les solutions d'énergie renouvelable et les technologies d'énergie innovantes, la société a annoncé une décision stratégique de migrer ses charges de travail vers Oracle Cloud Infrastructure (OCI) afin d'améliorer la performance, l'évolutivité et la sécurité.

Compte tenu des besoins et conditions spécifiques que OraStage a décrits, la société a besoin d'un système hybride de noms de domaine (DNS). La solution dans le nuage, et par hybride ici, signifie utiliser leur propre système DNS Berkeley Internet Name Domain version 9 (BIND9) en plus du service DNS OCI, où l'architecture finale qu'ils cherchent à construire est affichée dans l'image suivante.

OraStage Exigences relatives au DNS :

La société dispose de plusieurs domaines et sous-domaines internes. Tous doivent être résolus par leur DNS BIND9 dans OCI, où OraStage gérera toutes les zones et tous les enregistrements connexes. L'un de ces domaines est orastage.com que nous allons utiliser dans ce tutoriel. Ainsi, toute interrogation à orastage.com doit être transmise à BIND9.
Ils doivent toujours résoudre les domaines natifs OCI (oraclevcn.com, oraclecloud.com, etc.) dans certains cas, et cela se fera à l'aide de composants DNS privés OCI : vues privées, transfert de points d'extrémité et de règles, et points d'extrémité d'écoute.
Toutes les interrogations doivent être inspectées par une instance de pare-feu pfSense.
Pour éviter un point de défaillance unique, OraStage prévoit d'utiliser un autre serveur DNS et d'exploiter l'équilibreur de charge OCI pour répartir les interrogations entre le DNS principal et le DNS secondaire.

Cette série de tutoriels vous guidera étape par étape pour atteindre les exigences décrites ci-dessus, en construisant l'ensemble de la solution à partir de zéro. Vous pouvez facilement accéder à chaque tutoriel à partir de la liste ci-dessous :

Tutoriel 1 : Configurer le DNS BIND9 dans OCI. Voyez comment installer et configurer BIND9 sur une instance de calcul, ce qui en fait le serveur DNS local pour deux environnements de test dans OCI. Ces environnements seront constitués de serveurs "Frontend" et "Backend", chacun hébergé dans un réseau satellite distinct. Le serveur BIND9 traitera toutes les interrogations DNS dirigées vers orastage.com.
Tutoriel 2 : Mettre en oeuvre la haute disponibilité dans le scénario DNS BIND9 dans OCI. Ce tutoriel porte sur l'ajout d'un serveur BIND9 secondaire et la configuration d'un équilibreur de charge de réseau (NLB) pour répartir le trafic DNS entre les deux serveurs. Les interrogations DNS vers orastage.com seront dirigées vers l'adresse IP de l'équilibreur de charge de réseau, qui permettra d'équilibrer la charge entre les serveurs BIND9 principal et secondaire. Si un serveur devient indisponible, la résolution DNS se poursuivra sans interruption de service.
Tutoriel 3 : Utiliser le DNS OCI pour résoudre les domaines natifs. Se concentrant uniquement sur un cas d'utilisation spécifique, où nous utilisons des composants DNS natifs dans OCI, au cas où il serait nécessaire de résoudre des domaines natifs tels que oraclevcn.com et oraclecloud.com. Le DNS BIND9 n'est pas utilisé dans ce tutoriel.
Tutoriel 4 : Ajout de la sécurité à l'architecture DNS à l'aide du pare-feu pfSense. Mettre l'accent sur l'installation d'un pare-feu pfSense dans le VCN central dans OCI et effectuer la configuration réseau requise pour acheminer tout le trafic Est-Ouest, y compris les interrogations DNS (effectuées dans les précédents tutoriels) au moyen du pare-feu à inspecter.

Aperçu

Aujourd'hui, une infrastructure DNS fiable et efficace est essentielle pour assurer des opérations réseau transparentes. Dans le premier tutoriel : Configurer le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, nous avons déjà expliqué comment BIND9, l'un des logiciels DNS les plus utilisés, qui fournit des fonctions robustes et une flexibilité pour gérer les services DNS, peut être déployé et utilisé dans OCI. Alors qu'un seul serveur BIND9 peut gérer efficacement les demandes DNS, l'ajout d'un second serveur BIND9 offre de nombreux avantages qui améliorent la performance globale et la fiabilité de votre réseau.

Ce tutoriel vous guidera tout au long du processus de configuration d'un serveur BIND9 secondaire et d'un équilibreur de charge dans OCI, en mettant en évidence les avantages de cette configuration. En mettant en œuvre cela, vous obtiendrez :

Redondance : Assurer la disponibilité continue des services DNS, même en cas de défaillance du serveur principal.
Équilibrage de charge : Répartition de la charge d'interrogation DNS entre les serveurs, ce qui améliore les temps de réponse et réduit le risque de surcharge.
Distribution géographique : Si nécessaire, placer des serveurs DNS à différents emplacements peut fournir des temps de réponse plus rapides aux utilisateurs mondiaux.
Sécurité améliorée : Atténuation des risques en séparant et en sécurisant les services DNS sur plusieurs serveurs.

Équilibreur de charge de réseau OCI

Un équilibreur de charge de réseau flexible OCI (NLB) est un service qui aide à répartir le trafic entrant entre plusieurs ressources dorsales. Cela est particulièrement utile pour gérer les volumes de trafic élevés et s'assurer que les applications restent disponibles et réactives même en cas de défaillance d'un ou de plusieurs serveurs.

L'équilibreur de charge de réseau OCI fonctionne à la couche 3 et à la couche 4 du modèle OSI (Open Systems Interconnection), en gérant des protocoles tels que le protocole TCP (Transmission Control Protocol), le protocole UDP (User Datagram Protocol) et le protocole ICMP (Internet Control Message Protocol). En équilibrant efficacement la charge, il peut améliorer les performances des applications, fournir une haute disponibilité et améliorer l'évolutivité globale du système. Le service offre également des fonctions telles que des vérifications d'état pour surveiller le statut des serveurs dorsaux et garantir que le trafic est uniquement dirigé vers des instances saines et opérationnelles.

En résumé, un équilibreur de charge de réseau OCI joue un rôle clé dans le maintien de la fiabilité et de l'extensibilité des applications en répartissant intelligemment le trafic réseau sur plusieurs ressources. En raison de tous les avantages que nous avons mentionnés, nous ajouterons un équilibreur de charge de réseau à notre configuration afin d'optimiser notre solution DNS.

Objectifs

Déployez l'équilibreur de charge de réseau OCI et un serveur BIND9 secondaire dans OCI intégrés de façon transparente à votre réseau, assurant ainsi une infrastructure DNS robuste et résiliente.
L'objectif principal de ce tutoriel est d'activer le client FE-VM (fe.orastage.com) pour interroger BE-VM (be.orastage.com), et inversement, avec DNS-NLB répartissant les demandes de client entre Primary-DNS (primary-dns.orastage.com) et Secondary-DNS (secondary-dns.orastage.com) pour répondre à toutes les interrogations.

Architecture finale

Préalables

Accès à une location OCI et autorisations pour gérer le réseau et les services de calcul requis.
Comprendre de base le routage et la sécurité du réseau OCI et leurs fonctionnalités : réseau en nuage virtuel (VCN), table de routage, passerelle de routage dynamique (DRG), liste de sécurité, hôte bastion et équilibreur de charge de réseau OCI.
Présentation de base du service de journalisation OCI.
Compréhension de base de Ubuntu Linux et DNS en général.
Veillez à terminer le premier tutoriel : Configurer le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, où vous auriez déjà créé l'architecture suivante.

Tâche 1 : Provisionner une instance DNS secondaire et configurer BIND9

Reportez-vous au premier tutoriel : Configurer le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, où les tâches 2 et 3 indiquent la création et la configuration de l'instance Principale-DNS, les mêmes tâches doivent être effectuées pour configurer Secondaire-DNS, en tenant compte des informations suivantes :

Le nom de l'instance sera Secondary-DNS.
Il réside dans le même sous-réseau que le service de noms de domaine (DNS) principal et une adresse IP de 10.0.0.20 doit lui être affectée.
Au cours du processus de configuration, chaque fois que Primary-DNS 10.0.0.10 est mentionné, il doit être remplacé par Secondary-DNS 10.0.0.20, un exemple est le nom de domaine complet pour cette instance doit être secondary-dns.orastage.com.
Utilisez la même clé SSH.
Le même hôte bastion OCI utilisé pour accéder à Primary-DNS peut également être utilisé pour accéder au Secondary-DNS, mais à l'aide d'une nouvelle session.
Dans le fichier /var/lib/bind/db.orastage.com pour les instances principale et secondaire, assurez-vous que tous les enregistrements suivants sont présents afin que les deux serveurs DNS puissent se résoudre en plus des instances FE-VM et BE-VM.
```
primary-dns                 IN  A       10.0.0.10
secondary-dns               IN  A       10.0.0.20
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5
```

A la fin de cette tâche, l'architecture doit ressembler à ceci :

Tâche 2 : Configurer un équilibreur de charge de réseau OCI

Tâche 2.1 : Ajouter des détails

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur équilibreur de charge de réseau.
Cliquez sur Créer un équilibreur de charge de réseau.
1. Nom de l'équilibreur de charge : Entrez un nom.
2. Sélectionner un type de visibilité : Sélectionnez Privé.
3. Sélectionner un réseau : Sélectionnez DNS-VCN et son sous-réseau privé, où nous allons placer l'équilibreur de charge de réseau.
4. Cliquez sur Suivant.

Tâche 2.2 : Configurer un processus d'écoute

Un module d'écoute est un composant essentiel d'un équilibreur de charge qui est responsable de la réception d'un type spécifique de trafic avec certains ports (par exemple, TCP/port 80, UDP/port 21) et de son acheminement vers des serveurs dorsaux. Dans ce tutoriel, nous voulons que le module d'écoute écoute sur le port 53 (TCP) et (UDP), car DNS les utilise tous les deux.

Entrez les informations suivantes .
1. Nom du module d'écoute : Entrez un nom.
2. Spécifier le type de trafic que gère le module d'écoute : Sélectionnez UDP/TCP.
3. Spécifier le port : Entrez le numéro de port 53.
4. Cliquez sur Suivant.

Tâche 2.3 : Sélectionner un jeu dorsal

Un jeu dorsal est un regroupement logique de serveurs dorsaux vers lesquels l'équilibreur de charge de réseau achemine le trafic. Nos serveurs dorsaux sont Principal-DNS et Secondaire-DNS.

Entrez les informations suivantes .
1. Nom du jeu dorsal : Entrez un nom de jeu dorsal.
2. Cliquez sur Ajouter des serveurs dorsaux.
3. Type de serveur dorsal : Sélectionnez Instances de calcul.
4. Instances de calcul IPv4 dorsales : Sélectionnez les deux serveurs DNS : Primary-DNS et Secondary-DNS.
5. Cliquez sur Ajouter des serveurs dorsaux.
6. Vous pouvez voir que les serveurs dorsaux sont ajoutés au jeu.
7. Spécifier la politique de vérification de l'état : Une politique de vérification de l'état est utilisée pour vérifier la disponibilité des serveurs dorsaux en effectuant des demandes ou en tentant des connexions. L'équilibreur de charge de réseau effectue ces vérifications d'état à intervalles réguliers spécifiés, en utilisant cette politique pour surveiller en continu le statut des serveurs dorsaux.
8. Cliquez sur Suivant.

Tâche 2.4 : Réviser et créer

Vérifiez tous les détails et cliquez sur Créer un équilibreur de charge de réseau.
DNS-NLB est créé. Notez l'adresse IP privée comme nous l'utiliserons dans la tâche 3.

Tâche 2.5 : Ajouter une règle de sécurité

Pour éviter l'échec de la vérification de l'état et assurer une communication fluide sans aucune perturbation du trafic.

Ajoutez les règles suivantes dans la liste de sécurité DNS-Private-Subnet pour autoriser le trafic DNS envoyé depuis l'équilibreur de charge de réseau vers ses serveurs dorsaux.
L'architecture doit se présenter comme indiqué dans l'image suivante.

Tâche 3 : Configurer les règles de transmission DNS pour OCI

Tâche 3.1 : Configurer la règle de transmission Frontend-VCN

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur Réseaux en nuage virtuels.
Cliquez sur Frontend-VCN.
Cliquez sur le résolveur DNS du VCN.
Faire défiler vers le bas
1. Cliquez sur Règles.
2. Cliquez sur Gérer les règles.
3. Remplacez l'adresse IP de destination de l'adresse IP Primary-DNS par l'adresse IP DNS-NLB (10.0.0.110) créée dans la tâche 2.
4. Cliquez sur enregistrer les modifications.
5. Adresse IP de destination modifiée avec succès. Ainsi, toutes les interrogations provenant de FE-VM seront transmises à l'adresse IP DNS-NLB, qui les répartira entre les serveurs DNS principal et secondaire.

Tâche 3.2 : Configurer la règle de transfert dorsal-VCN

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur Réseaux en nuage virtuels.
Cliquez sur Backend-VCN.
Cliquez sur le résolveur DNS du VCN.
Faire défiler vers le bas.
1. Cliquez sur Règles.
2. Cliquez sur Gérer les règles.
3. Remplacez l'adresse IP de destination de l'adresse IP Primary-DNS par l'adresse IP DNS-NLB (10.0.0.110) créée dans la tâche 2.
4. Cliquez sur enregistrer les modifications.
5. Adresse IP de destination modifiée avec succès. Ainsi, toutes les interrogations provenant de BE-VM seront transmises à l'adresse IP DNS-NLB, qui les répartira entre les serveurs DNS principal et secondaire.

Tâche 4 : Tester et valider

Conditions requises :

Activer les journaux : Pour vérifier le flux de trafic, nous activerons les journaux de flux de sous-réseau, ce qui nous permet de surveiller et de suivre le trafic réseau entrant ou sortant d'un sous-réseau spécifique. Ces journaux saisissent des détails sur le trafic réseau, tels que les adresses IP source et de destination, les numéros de port et la quantité de données transmises. Pour activer le journal, procédez comme suit :
1. Allez au sous-réseau privé DNS-VCN, dans lequel résident Primary-DNS, Secondary-DNS et DNS-NLB.
2. Cliquez sur Journaux.
3. Sélectionnez Activer le journal.
Pour plus d'informations sur les journaux et sur leur utilisation dans OCI, voir
- Journaux des flux dans le réseau en nuage virtuel.
- Informations détaillées sur les journaux de flux de VCN - Voyez comment lire le contenu du journal.
- Suivre les paquets dans une architecture de routage de VCN central et satellite dans OCI - Tutoriel utile pour savoir comment tracer les paquets de réseau dans un environnement OCI à l'aide de plusieurs méthodes, telles que la saisie des paquets de pare-feu, les journaux de sous-réseau et TCPdump. Suivez les tâches 6 et 13.
  - Tâche 6 : Activer la journalisation (tous les journaux) sur le sous-réseau privé satellite.
  - Tâche 13 : Examinez tous les points de journalisation et les captures de paquets et suivez le chemin - point de journalisation B.

Maintenant, tout le trafic entrant et sortant de ce sous-réseau sera journalisé.

Scénario de test 1 : DNS principal répond aux interrogations FE-VM lorsque le DNS secondaire est arrêté

En cas de défaillance dans Secondary-DNS, nous devons nous assurer que le Primary-DNS répond aux interrogations provenant de FE-VM, car DNS-NLB y dirige le trafic.

L'image suivante illustre le scénario de test que nous visons à réaliser.
Actuellement, toutes les instances sont en cours d'exécution. Commençons par arrêter l'instance Secondary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Calculer.
2. Cliquez sur Instances.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Arrêter.
4. Cliquez sur Arrêter.
5. L'instance est maintenant à l'état Arrêté.
Accédez à FE-VM et effectuez un test en exécutant une interrogation. Pour ce faire, nous utiliserons le service d'hôte bastion OCI. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Identité et sécurité.
2. Cliquez sur Hospital.
Cliquez sur FEBastion.
Cliquez sur Créer une session.
Entrez les informations suivantes .
1. Type de session : Sélectionnez Session SSH gérée.
2. Nom de session : Entrez un nom pour la session.
3. Nom d'utilisateur : Entrez le nom d'utilisateur. Pour l'instance Oracle Linux, le nom d'utilisateur par défaut est opc.
4. Instance de calcul : Sélectionnez l'instance FE-VM.
5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : Générer une paire de clés SSH.
6. Cliquez sur Créer une session.

Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

La commande doit ressembler à ceci :

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Ouvrez OCI Cloud Shell.
1. Naviguez jusqu'au répertoire .ssh à l'aide de la commande cd .ssh.
2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
3. Entrez oui.
La connexion a été établie avec succès. Maintenant, effectuez une interrogation de test de FE-VM à be.orastage.com à l'aide de la commande host. Vérifiez que l'interrogation a réussi et qu'une réponse a été reçue.
Nous savons qu'il n'y a qu'un seul serveur dorsal sain pour traiter la demande, qui est Primary-DNS. Nous allons donc vérifier le flux de l'interrogation DNS et voir quel serveur a répondu à cette interrogation à l'aide des journaux de sous-réseau OCI.
1. Cliquez sur le journal.
2. La demande est passée du point d'extrémité de transfert (10.1.0.6) qui est placé dans le même sous-réseau que FE-VM à l'adresse IP NLB (10.0.0.110) du DNS-VCN.
3. Puis, à partir de l'adresse IP NLB (10.0.0.110), la demande est envoyée à Primary-DNS (10.0.0.10).
Test réussi. Primary-DNS a pu traiter les interrogations DNS en cas d'arrêt de Secondary-DNS.

Scénario de test 2 : DNS secondaire répond aux interrogations FE-VM lorsque le DNS principal est arrêté

En cas de défaillance dans Primary-DNS, nous devons nous assurer que le Secondary-DNS répond aux interrogations provenant de FE-VM, car DNS-NLB y dirige le trafic.

L'image suivante illustre le scénario de test que nous visons à réaliser.
Commençons par arrêter l'instance Primary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Calculer.
2. Cliquez sur Instances.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Arrêter.
4. Cliquez sur Arrêter.
5. L'instance est maintenant à l'état Arrêté.
Démarrez l'instance Secondary-DNS.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Commencer.
4. Cliquez sur Commencer.
5. L'instance est maintenant à l'état En cours d'exécution.
Ensuite, nous allons accéder à FE-VM et effectuer un test en exécutant une interrogation. Pour ce faire, nous utiliserons le service d'hôte bastion OCI. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Identité et sécurité.
2. Cliquez sur Hospital.
Cliquez sur FEBastion.
Cliquez sur Créer une session.
Entrez les informations suivantes .
1. Type de session : Sélectionnez Session SSH gérée.
2. Nom de session : Entrez un nom pour la session.
3. Nom d'utilisateur : Entrez le nom d'utilisateur. Pour l'instance Oracle Linux, le nom d'utilisateur par défaut est opc.
4. Instance de calcul : Sélectionnez l'instance FE-VM.
5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : Générer une paire de clés SSH.
6. Cliquez sur Créer une session.

Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

La commande doit ressembler à ceci :

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Ouvrez OCI Cloud Shell.
1. Naviguez jusqu'au répertoire .ssh à l'aide de la commande cd .ssh.
2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
3. Entrez oui.
La connexion a été établie avec succès. Maintenant, effectuez une interrogation de test de FE-VM à be.orastage.com à l'aide de la commande host. Vérifiez que l'interrogation a réussi et qu'une réponse a été reçue.
Nous savons qu'il n'y a qu'un seul serveur dorsal sain pour traiter la demande, qui est Secondary-DNS. Nous allons donc vérifier le flux de l'interrogation DNS et voir quel serveur a répondu à cette interrogation à l'aide des journaux de sous-réseau OCI.
1. Cliquez sur le journal.
2. La demande est passée du point d'extrémité de transfert (10.1.0.6) qui est placé dans le même sous-réseau que FE-VM à l'adresse IP NLB (10.0.0.110) du DNS-VCN.
3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Secondary-DNS (10.0.0.20).
Test réussi. Secondary-DNS peut traiter les interrogations DNS si le service principal de DNS est arrêté.

Scénario de test 3 : DNS principal répond aux interrogations BE-VM lorsque le DNS secondaire est arrêté

En cas de défaillance dans Secondary-DNS, nous devons nous assurer que Primary-DNS répond aux interrogations provenant de BE-VM, car DNS-NLB y dirige le trafic.

L'image suivante illustre le scénario de test que nous visons à réaliser.
Actuellement, toutes les instances sont en cours d'exécution. Commençons par arrêter l'instance Secondary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Calculer.
2. Cliquez sur Instances.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Arrêter.
4. Cliquez sur Arrêter.
5. L'instance est maintenant à l'état Arrêté.
Ensuite, nous allons accéder à BE-VM et effectuer un test en exécutant une interrogation. Pour ce faire, nous utiliserons le service d'hôte bastion OCI. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Identité et sécurité.
2. Cliquez sur Hospital.
Cliquez sur BEBastion.
Cliquez sur Créer une session.
Entrez les informations suivantes .
1. Type de session : Sélectionnez Session SSH gérée.
2. Nom de session : Entrez un nom pour la session.
3. Nom d'utilisateur : Entrez le nom d'utilisateur. Pour l'instance Oracle Linux, le nom d'utilisateur par défaut est opc.
4. Instance de calcul : Sélectionnez l'instance BE-VM.
5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : Générer une paire de clés SSH.
6. Cliquez sur Créer une session.

Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

La commande doit ressembler à ceci :

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Ouvrez OCI Cloud Shell.
1. Naviguez jusqu'au répertoire .ssh à l'aide de la commande cd .ssh.
2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
3. Entrez oui.
La connexion a été établie avec succès. Maintenant, effectuez une interrogation de test de BE-VM à fe.orastage.com à l'aide de la commande host. Vérifiez que l'interrogation a réussi et qu'une réponse a été reçue.
Nous savons qu'il n'y a qu'un seul serveur dorsal sain pour traiter la demande, qui est Primary-DNS. Nous allons donc vérifier le flux de l'interrogation DNS et voir quel serveur a répondu à cette interrogation à l'aide des journaux de sous-réseau OCI.
1. Cliquez sur le journal.
2. La demande est passée du point d'extrémité de transfert (10.2.0.6) qui est placé dans le même sous-réseau que BE-VM à l'adresse IP NLB (10.0.0.110) du DNS-VCN.
3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Primary-DNS (10.0.0.10).
Test réussi. Primary-DNS a pu traiter les interrogations DNS en cas d'arrêt de Secondary-DNS.

Scénario de test 4 : DNS secondaire répond aux interrogations BE-VM lorsque le DNS principal est arrêté

En cas de défaillance dans Primary-DNS, nous devons nous assurer que le Secondary-DNS répond aux interrogations provenant de BE-VM, car DNS-NLB y dirige le trafic.

L'image suivante illustre le scénario de test que nous visons à réaliser.
Commençons par arrêter l'instance Primary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Calculer.
2. Cliquez sur Instances.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Arrêter.
4. Cliquez sur Arrêter.
5. L'instance est maintenant à l'état Arrêté.
Démarrez l'instance Secondary-DNS.
1. Cochez la case à côté de l'instance.
2. Cliquez sur Actions.
3. Cliquez sur Commencer.
4. Cliquez sur Commencer.
5. L'instance est maintenant à l'état En cours d'exécution.
Ensuite, nous allons accéder à BE-VM et effectuer un test en exécutant une interrogation. Pour ce faire, nous utiliserons le service d'hôte bastion OCI. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Identité et sécurité.
2. Cliquez sur Hospital.
Cliquez sur BEBastion.
Cliquez sur Créer une session.
Entrez les informations suivantes .
1. Type de session : Sélectionnez Session SSH gérée.
2. Nom de session : Entrez un nom pour la session.
3. Nom d'utilisateur : Entrez le nom d'utilisateur. Pour l'instance Oracle Linux, le nom d'utilisateur par défaut est opc.
4. Instance de calcul : Sélectionnez l'instance BE-VM.
5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : Générer une paire de clés SSH.
6. Cliquez sur Créer une session.

Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

La commande doit ressembler à ceci :

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Ouvrez OCI Cloud Shell.
1. Naviguez jusqu'au répertoire .ssh à l'aide de la commande cd .ssh.
2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
3. Entrez oui.
La connexion a été établie avec succès. Maintenant, effectuez une interrogation de test de BE-VM à fe.orastage.com à l'aide de la commande host. Vérifiez que l'interrogation a réussi et qu'une réponse a été reçue.
Nous savons qu'il n'y a qu'un seul serveur dorsal sain pour traiter la demande, qui est Secondary-DNS. Nous allons donc vérifier le flux de l'interrogation DNS et voir quel serveur a répondu à cette interrogation à l'aide des journaux de sous-réseau OCI.
1. Cliquez sur le journal.
2. La demande est passée du point d'extrémité de transfert (10.2.0.6) qui est placé dans le même sous-réseau que BE-VM à l'adresse IP NLB (10.0.0.110) du DNS-VCN.
3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Secondary-DNS (10.0.0.20).
Test réussi. Secondary-DNS a pu traiter les interrogations DNS en cas d'arrêt de Primary-DNS.

Étapes suivantes

Dans ce tutoriel, nous avons amélioré une configuration DNS simple client-serveur BIND9 dans OCI en intégrant un équilibreur de charge de réseau OCI et un serveur DNS secondaire afin de garantir une disponibilité continue du service en cas de défaillance du serveur principal.

Jusqu'à présent, nous avons développé une architecture DNS haute performance et fiable spécifiquement pour le traitement des requêtes de domaine orastage.com. Toutefois, la société OraStage doit également résoudre les noms de domaine natifs OCI, tels que oraclevcn.com et oraclecloud.com, et pour cela, des étapes supplémentaires sont nécessaires. Dans le prochain tutoriel, Utiliser le DNS d'OCI pour résoudre les domaines natifs, nous montrerons comment effectuer cette configuration.

Remerciements

Auteur - Anas abdallah (spécialiste du réseau en nuage)

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.

Informations sur le titre et les droits d'auteur

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14453-02