Installation de 2 DDNS en failover sur Linux pour 2 réseaux

I . Introduction

Dans ce document je vais présenter la mise en place d’un serveur DDNS sous Linux Red-Hat 7.3. Après un rapide rappel de la fonction d’un serveur DDNS, j’exposerai d’abord l’installation de Red-Hat 7.3. J’expliquerai ensuite la mise en place du serveur dans un réseau « normal » puis dans un réseau « virtuel ».

Pré-requis

LAN (Local Area Network) : Terme représentant le réseau de l’entreprise. Tout les éléments du réseau sont reliés par des composants réseaux. Chacun de ces élements est identifié par une adresse IP.

Adresse IP (Internet Protocol): Toute machine d’un réseau informatique (PC, serveur, imprimante) possède une adresse numérique de la forme aaa.bbb.ccc.ddd. Elle permet d’identifier de façon unique la machine avec laquelle on veut dialoguer.

Serveur DCHP (Dynamic Configuration Host Protocol) : Ce serveur délivre les adresses IP sous forme de baux. En effet, avec l’apparition des PC portables et la taille grandissante des réseaux, il est fastidieux pour l’administrateur d’attribuer manuellement des adresses à ses clients. C’est pourquoi, lorsqu’un ordinateur est configuré en DCHP, il envoie au démarrage une demande d’adresse sur le réseau. Le serveur DHCP alors présent sur le réseau lui donne en retour toutes les informations nécessaires sur le réseau. Cette adresse est délivrée de façon temporaire. Lorsque le bail vient a expiration, le client demande un renouvellement au serveur qui reconduit alors le « contrat ».

VLAN (Virtual Local Area Network) : Terme représentant un découpage d’un réseau en sous réseaux distincts. Cette technique permet à plusieurs réseaux de partager les mêmes composants informatiques.

Interface : Désigne la carte réseau.

Red-Hat : C’est un système d’exploitation au même titre que Windows. Il s’appuie sur l’environnement Unix et est entièrement gratuit. Il est développé par des utilisateurs du monde entier ce qui fait de lui un système très stable car très testé.

DNS (Domain Name Server) : Contient l’ensemble des noms et adresses IP des clients du réseau. Le renseignement du client dans le serveur est manuel et donc fastidieux. C’est pourquoi nous mettons en place le DDNS.

DDNS (Dynamic Domain Name Server) : C’est une association du serveur DHCP et du serveur DNS. Lorsque le serveur DHCP attribue une nouvelle adresse, il renseigne automatique le DNS qui met ainsi sa base de données à jour.

Failover : Signifie que lorsqu’un serveur tombe en panne, un second prend automatiquement le relai.

II . Installation de Red-Hat

1 . Pourquoi Red Hat ?

Red-Hat a été retenu dans un premier temps pour sa capacité a géré deux réseaux différents. Son prix est également un avantage car il est nul.

De plus, la gestion d’un serveur DHCP sous Red-Hat est plus stable. En effet, contrairement à un serveur DHCP Windows, un serveur DHCP Red-Hat est « fail-over ». Cela signifie que si le serveur tombe en panne, son travail peut être repris par un autre serveur.

2 .  Installation de Red-Hat 7.3

Pour installer Red-Hat il suffit de démarrer sur le cdrom numéro 1. Dès lors, on est accueillit par une interface graphique qui nous aiguille dans l’installation. Je vais lister dans l’ordre les manipulations qu’il faut effectuer :

L’étape suivante est importante. Elle représente les outils qui vont être installés sur le système :

L’installation de la carte graphique dépend de la machine. Sur la mienne :

Dans la suite de ce document, nous appellerons le serveur primaire « muscat » et le secondaire « gamay ».

Pour parfaire la configuration réseaux le fichier /etc/resolv.conf doit contenir les lignes suivantes :

domain mon_domaine

nameserver 192.168.168.8

nameserver 192.168.168.9

III . Installation d’un programme

Il y a 2 facons d’installer un programme : soit on compile les sources, soit on installe le package.

1 . Compilation des sources

Les fichiers sont généralement des fichiers compressés « .tar.gz ». On les décompresse par la commande : tar –zxvf nom_du_fichier.tar.gz Si le fichier est de la forme « .tar.bz2 » il faut utiliser les commandes : bunzip2 nom_du_fichier.tar.bz2 puis

tar –xvf nom_du_fichier.tar

Une fois les sources décompressés, il faut les compiler. Dans le répertoire, éxecutez la commande ./configure. Cela va générer un fichier « Makefile » ou « makefile ». On  éxecute la commande make puis make install.

2 . Installation d’un package

Un package est un fichier d’extension  « .rpm ».

On éxecute simplement la commande : rpm –ivh nom_du_package.rpm

3 . Execution des programmes par scripts

Pour certains programmes, il est préférable d’utiliser un scrip pour contrôler le programme : demarrer, arreter, re-demarrer, afficher l’état.

Sur Internet on trouve de nombreux scripts tout prêt pour chaque programme.

On peut également modifier le script d’un programme existant.

Les scripts se trouvent dans le répertoire /etc/init.d . Placer donc le scripts dans ce répertoire et tapper les commandes suivantes :

            chkconfig --add nom_du_script

            chkconfig --level 345 nom_du_script on

Cela a pour effet d’installer le script et de le lancer au démarrage de la machine pour les run level 3,4 et 5. Pour savoir ce qu’est un run level, éditez le fichier /etc/inittab

Pour lancer un programme par son script, 2 techniques :

Les options que l’on peut employer sont : start, stop, status, restart

IV . Installation des serveurs DHCP

 

1 .  Configuration des serveurs

La configuration des serveurs DHCP se fait dans 2 fichiers :

Fichier dhcpd.conf de muscat :

#Duree des baux

default-lease-time 30000;

max-lease-time 60000;

#Configuration de la mise a jour du DNS

ddns-updates on; #Autorisation de mise a jour

ddns-update-style interim;#Mode de mise a jour

#Configuration du failover cote Power

failover peer "dhcp_power" {

 primary; #Serveur primaire

 address 10.18.168.8; #adresse de notre serveur

 port 519;#Port de dialogue

 peer address 10.18.168.9;#adresse du serveur pair

 peer port 519;#Port de dialogue

 max-response-delay 60;#Temps de non reponse

 max-unacked-updates 10;#Nombre max de non acquitements

 mclt 3660;   # Temps de renouvellement des bauds

 split 128;   # Repartition des plages d’adresses

 load balance max seconds 3;

}

#idem que Power mais pour T&D

failover peer "dhcp_tde" {

 primary;

 address 10.22.40.8;

 port 519;

 peer address 10.22.40.9;

 peer port 519;

 max-response-delay 60;

 max-unacked-updates 10;

 mclt 3660;

 split 128;

 load balance max seconds 3;

}

# Les lignes suivantes servent au boot

#failover peer "dhcp_power" state {

#my state partner-down;

#}

#failover peer "dhcp_tde" state {

#my state partner-down;

#}

#Inclusion du fichier dhcpd.master

include "/etc/dhcpd.master";

Les lignes « failover peer … state » sont à décommenter lorsque l’on démarre pour la première fois les serveurs DHCP. En effet, quand le fichier dhcpd.leases est vide de chaque côté, chaque serveur croit qu’il est tombe en panne et attend le temps mclt pour se mettre en marche. Il faut donc dans un premier temps démarrer le serveur primaire avec ces lignes décommentées.

Fichier dhcpd.conf de gamay :

#Duree des baux

default-lease-time 30000;

max-lease-time 60000;

#Configuration de la mise a jour du DNS

ddns-updates on;

ddns-update-style interim;

failover peer "dhcp_power" {

 secondary;

 address 10.18.168.9;

 port 519;

 peer address 10.18.168.8;

 peer port 519;

 max-response-delay 60;

 max-unacked-updates 10;

 load balance max seconds 3;

}

failover peer "dhcp_tde" {

 secondary;

 address 10.22.40.9;

 port 519;

 peer address 10.22.40.8;

 peer port 519;

 max-response-delay 60;

 max-unacked-updates 10;

 load balance max seconds 3;

}

# Les lignes suivantes servent au boot

#failover peer "dhcp_power" state {

#my state partner-down;

#}

#failover peer "dhcp_tde" state {

#my state partner-down;

#}

include "/etc/dhcpd.master";

Fichier dhcpd.master de muscat et gamay

#Configuration du reseau POWER

subnet 10.18.168.0 netmask 255.255.254.0

{

        #Les clients peuvent mettre a jour le DNS

        allow client-updates;

        #Declaration d’une plage

        pool {

         # Initialisation du failover

         failover peer "dhcp_power";

         # Le failover ne fonctionne pas avec les clients BOOTP

         deny dynamic bootp clients;

         #Information de configuration du reseau

         #DNS

         option domain-name "stp";

          option domain-name-servers 10.18.168.8, 10.18.168.9;

         #WINS

option netbios-name-servers 10.18.168.8, 10.18.168.9;

          option netbios-node-type 8;

         #Adressage IP

          option subnet-mask 255.255.254.0;

          option broadcast-address 10.18.169.255;

         option routers 10.18.169.1;

         #Plages dediées

         range 10.18.168.20 10.18.168.255;

         range 10.18.169.2 10.18.169.254;

         allow unknown clients;

        }

}

#Idem que Power

subnet 10.22.40.0 netmask 255.255.248.0

{

        allow client-updates;

        pool {

         # Initialisation du failover

         failover peer "dhcp_tde";

         # Le failover ne fonctionne pas avec les clients BOOTP

        deny dynamic bootp clients;

   ddns-domainname "stp";

        option domain-name "stp";

        option domain-name-servers 10.22.40.8, 10.22.40.9;

   option netbios-name-servers 10.22.40.8, 10.22.40.9;

        option netbios-node-type 8;

        option subnet-mask 255.255.248.0;

        option broadcast-address 10.22.47.255;

        option routers 10.22.40.1;

        range 10.22.41.10 10.22.47.254;

        allow unknown clients;

        }

}

2 .  Démarrage et fonctionnement des serveurs

Les serveurs DHCP dialoguent entre eux pour échanger des signaux de vie et leur base de données. Ils allouent indifféremment les adresses IP sur les 2 plages Power et T&D. Lorsque l’un d’eux ne répond plus, l’autre renouvelle les baux de sa pair pendant le temps mtcl. Une fois cette durée révolue, le serveur restant réalloue lui-même les baux.

Lorsque le serveur tombé en panne réapparaît, il synchronise sa base de donnée avec le serveur restant. De plus, il ne répond pas aux demandes d’adresses IP pendant le temps mtcl.

Les baux alloués ainsi que la trace des évenemements se situent dans le fichier dhcpd.leases.

Lors du premier démarrage, le fichier dhcpd.leases doit être créer manuellement et doit être vide : touch /var/state/dhcp/dhcpd.leases. Lorsque les serveurs démarrent, ils voient que leur base de données est vide. Ils croient alors tous qu’ils sont tombés précedemment en panne et attendent. Pour palier ce problème, il faut décommenter sur le primaire les lignes « failover  … state ». Elles ont pour effet de dire au serveur que le serveur secondaire est en panne. Ainsi, le serveur primaire remplit sa base de données et l’on peut démarrer le secondaire si ce n’est pas déjà fait. On arrête alors le primaire pour commenter les lignes « failover … state » et on le redémarre.

Les deux serveurs sont maintenant démarrés et échangent leurs informations.

Pour démarrer un serveur : dhcpd.

Les divers opérations sont tracées dans /var/log/messages.1

3 .  Tester le fonctionnement sur un poste client

Pour tester le bon fonctionnement il suffit de demander à un ordinateur client de renouveler son bail.

Pour un ordinateur Windows NT il suffit de lancer les commandes suivantes :


Maintenant que le DHCP fonctionne, il ne reste plus qu’à installer le DNS pour obtenir un DDNS.

 

IV) Installation du DDNS

Le DDNS est un serveur DNS classique sauf qu’il accepte la mise à jour de sa base de données par le DHCP.

 

a)  Fonctionnement du serveur

 

Le serveur reçoit soit des demandes de noms, soit des demandes d’adresses IP. S’il ne sait pas répondre, il demande à d’autres DNS qui font de même. Un serveur DNS appartient et gère un domaine qui constitue l’ensemble des machines qu’il peut renseigner.

Le serveur « master » est épaulé  par le ou les serveurs « slave » qui le relais en cas de panne ou de surcharge réseau.

 

b)  Configuration du serveur

 

Le serveur DNS se configure dans 3 types de fichiers :
/etc/resolv.conf : contient les informations du serveur au sein du domaine.
/etc/named.conf : contient la configuration du serveur
/var/named/* : ce sont les fichiers de zone. Ils contiennent les bases de données du serveur.

 

Le fichier /etc/resolv.conf de muscat et gamay :

domain stp
nameserver 10.18.168.8
nameserver 10.22.40.8
nameserver 10.18.168.9
nameserver 10.22.40.9
Le fichier /etc/named.conf de muscat :
/* Localisation des fichiers de zones */
options {

    directory "/var/named";

};
/*

 * Fichier de cache. En commentaire faute de mieux.

 */
/*
zone "." {
   type hint;
file "named.ca";
};
*/
/*
 * Configuration de la zone stp : On recoit une demande d’adresse IP à partir d’un nom
 */
zone "stp" {

 

     /* Muscat est le serveur maitre* /

     type master ;

 

     /* Le fichier de base de données de la zone */

     file "stp";

 

     /* Ensemble des postes qui ont acces a la base de donnees (DDNS) : tout le reseau */

     allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};     allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};
};
/*

 

 * Configuration de la zone reverse 10.22.40: On recoit une demande de nom à partir d’un adresse IP commencant par 10.22.40. On retourne le nom.

 */
zone "40.22.10.in-addr.arpa" {
     /* Muscat est maitre */
     type master ;

 

     /* Fichier de base de données */

     file "stp.rev.40";

 

     /* Ensemble des postes qui ont acces a la base de donnees (DDNS) : tout le reseau */

     allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};     allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};
};
/* Idem */
zone "41.22.10.in-addr.arpa" {

type master ;

file "stp.rev.41";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};
allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};
};
zone "42.22.10.in-addr.arpa" {

type master ;

file "stp.rev.42";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "43.22.10.in-addr.arpa" {

type master ;

file "stp.rev.43";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "44.22.10.in-addr.arpa" {

type master ;

file "stp.rev.44";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "45.22.10.in-addr.arpa" {

type master ;

file "stp.rev.45";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "46.22.10.in-addr.arpa" {

type master ;

file "stp.rev.46";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "47.22.10.in-addr.arpa" {

type master ;

file "stp.rev.47";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
/* Idem mais pour la partie POWER du réseau */
zone "168.18.10.in-addr.arpa" {

type master ;

file "power.rev.168";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
zone "169.18.10.in-addr.arpa" {

type master ;

file "power.rev.169";

allow-query {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

allow-update {10.22.40/21;localhost;10.22.40.8;10.18.168/23;};

};
Fichier /etc/named.conf de gamay :
/* Repertoire contenant les fichiers de zone */
options {

directory "/var/named";

};

/*

* Fichier de cache. En commentaire faute de mieux

*/

/*
zone "." {

type hint;

file "named.ca";

};

*/

/* Configuration de la zone directe */

zone "stp" {

/* Gamay est slave */

type slave ;

/* Son serveur master est muscat */

masters  {10.22.40.8;10.18.168.8;};

/* Le fichier de base de données */

file "stp";

/* Il peut être mis à jour par tout le reseau */

allow-update-forwarding {any;};

};

/* Idem */

zone "40.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.40";

allow-update-forwarding {any;};

};

zone "41.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.41";

allow-update-forwarding {any;};

};

zone "42.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.42";

allow-update-forwarding {any;};

};

zone "43.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.43";

allow-update-forwarding {any;};

};

zone "44.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.44";

allow-update-forwarding {any;};

};

zone "45.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.45";

allow-update-forwarding {any;};

};

zone "46.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.46";

allow-update-forwarding {any;};

};

zone "47.22.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "stp.rev.47";

allow-update-forwarding {any;};

};

zone "168.18.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "power.rev.168";

allow-update-forwarding {any;};

};

zone "169.18.10.in-addr.arpa" {

type slave ;

masters  {10.22.40.8;10.18.168.8;};

file "power.rev.169";

allow-update-forwarding {any;};

};

Les fichiers de zones contiennent les différents enregistrements des clients sur le réseaux.

Fichier /var/named/stp sur muscat et gamay :

$ORIGIN . ; Toutes infos ne finissant pas par un point est concatene a $ORIGIN

$TTL 300 ; 5 minutes : Duree de vie de l’info avant renouvellement

stp           IN SOA   muscat.stp. root.muscat.stp. (

200207287  ; serial

28800      ; refresh (8 hours)

14400      ; retry (4 hours)

604800     ; expire (1 week)

80400      ; minimum (22 hours 20 minutes)

)

NS   gamay.stp.

NS   muscat.stp.

$ORIGIN stp.

$TTL 15000    ; 4 hours 10 minutes

CLIENT_POWER       A    10.18.169.131

$TTL 1830 ; 30 minutes 30 seconds

TXT  "313156fc954a4f6e4e1c3a2dec187f233b"

CLIENT_STP         A    10.22.44.128

TXT  "31e42953b1b88e3aca9af5e45a1457daed"

$TTL 300 ; 5 minutes

gamay              A    10.22.40.9

muscat             A    10.22.40.8

Explication de SOA :

Les lignes de $ORIGIN stp à gamay (non incluse) ont été rajoutées par le DHCP. Pour que la configuration fonctionne au démarrage, il faut donc les autres lignes.
Le champ « A » correspond à un enregistrement de client.
Le champ « TXT » correspond à une description du client.
Fichier de zone inverse de muscat et gamay :
$ORIGIN .
$TTL 300 ; 5 minutes
169.18.10.in-addr.arpa  IN SOA   muscat.stp. root.stp. (

20020728   ; serial

28800      ; refresh (8 hours)

14400      ; retry (4 hours)

604800     ; expire (1 week)

80400      ; minimum (22 hours 20 minutes)

)

NS   gamay.stp.

NS   muscat.stp.

$ORIGIN 169.18.10.in-addr.arpa.
$TTL 15000    ; 4 hours 10 minutes
131           PTR  CLIENT_POWER.stp.
131 correspond à l’adresse 10.18.169.131 et PTR à un enregistrement inverse.
Un autre exemple de fichier de zone inverse :
$ORIGIN .
$TTL 300 ; 5 minutes
40.22.10.in-addr.arpa   IN SOA   muscat.stp. root.stp. (

                   200207300  ; serial

28800      ; refresh (8 hours)

14400      ; retry (4 hours)

604800     ; expire (1 week)

80400      ; minimum (22 hours 20 minutes)

)

NS   gamay.stp.

NS   muscat.stp.

$ORIGIN 40.22.10.in-addr.arpa.
$TTL 1830 ; 30 minutes 30 seconds
8             PTR  muscat.stp.
9             PTR  gamay.stp.

Pour démarrer le serveur DNS : named.

c) Test du côté client

Pour tester le bon fonctionnement, on utilise la commande nslookup sur un poste Windows NT.