Corrigé

Administration Réseaux

Cet article propose une correction détaillée de l'examen d'administration réseaux pour le niveau M1-MP2L. Il aborde la configuration des zones directes et inverses sous BIND, la gestion d'un serveur DHCP avec réservation d'adresse IP et la mise en place de partages NFS sécurisés.

D'après le document Administration Réseaux

Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Administration Réseaux

Document source

Administration Réseaux

Network Administration · PDF · 2 pages · 2020

Afficher l'aperçu du document

Consulter le document original

Ce document présente un examen d'administration réseaux destiné à des étudiants de niveau M1-MP2L. Il évalue des compétences pratiques en configuration DNS, DHCP et NFS, ainsi que la compréhension des concepts fondamentaux liés à ces services réseau.

Exercice 1 : Configuration et analyse d'un serveur DNS

Cet exercice porte sur l'ajout d'enregistrements DNS dans les zones directes et inverses, ainsi que sur l'explication des champs d'un fichier de zone BIND.

1. Ajout des enregistrements pour les postes dans les zones directes et inverses

Nous avons trois postes avec leurs adresses IP :

  • poste1 : 192.168.0.11
  • poste2 : 192.168.0.12
  • poste3 : 192.168.0.13

Dans la zone directe "company.com", on crée des enregistrements de type A qui associent un nom d'hôte à une adresse IP :

poste1 IN A 192.168.0.11
poste2 IN A 192.168.0.12
poste3 IN A 192.168.0.13

Dans la zone inverse "0.168.192.in-addr.arpa", on crée des enregistrements PTR qui associent une adresse IP à un nom d'hôte. Pour cela, on utilise la dernière partie de l'adresse IP :

11 IN PTR poste1.company.com.
12 IN PTR poste2.company.com.
13 IN PTR poste3.company.com.

2. Ajout d'un enregistrement pour le serveur de messagerie mail.company.com

Le serveur mail a l'adresse 192.168.0.5. On ajoute dans la zone directe :

mail IN A 192.168.0.5

Et dans la zone inverse :

5 IN PTR mail.company.com.

3. Ajout d'un enregistrement pour le service web www.company.com installé sur poste1

Le service web est sur poste1, donc il partage la même adresse IP 192.168.0.11. On ajoute un alias (CNAME) dans la zone directe :

www IN CNAME poste1.company.com.

Le CNAME indique que www.company.com est un alias de poste1.company.com, ce qui évite de dupliquer l'adresse IP.

4. Analyse du fichier de base de données de zone /var/named/db.company.com

a) Signification du champ TTL à la ligne 4

Le champ TTL (Time To Live) indique la durée en secondes pendant laquelle les enregistrements DNS peuvent être mis en cache par les serveurs ou clients. Ici, la valeur est 604800, soit 7 jours (604800 secondes = 7 × 24 × 3600). Cela signifie que les enregistrements de cette zone peuvent être conservés en cache pendant une semaine avant d'être rafraîchis.

b) Explication des paramètres des lignes 6 à 10

Ces lignes correspondent à la définition du SOA (Start Of Authority), qui contient plusieurs paramètres :

  • company.com. : le nom de la zone.
  • IN SOA : indique le début de la déclaration SOA.
  • company.com root.company.com ( : le serveur DNS principal (maître) et l'adresse email du responsable de la zone (le point remplace le @ dans root.company.com).
  • 107202001 : numéro de série de la zone, utilisé pour indiquer les mises à jour.
  • 6H : Refresh - intervalle (6 heures) avant que les serveurs secondaires demandent une mise à jour.
  • 1H : Retry - intervalle (1 heure) à attendre avant de réessayer après un échec de rafraîchissement.
  • 1W : Expire - durée (1 semaine) après laquelle les serveurs secondaires considèrent la zone périmée s'ils ne peuvent pas contacter le maître.
  • 4H : Minimum TTL - durée (4 heures) utilisée comme TTL par défaut pour les enregistrements de la zone.

c) Signification du champ NS à la ligne 12

Le champ NS (Name Server) indique le serveur de noms autoritaire pour la zone. Ici, la ligne :

company.com. IN NS ns0

signifie que le serveur de noms principal pour la zone company.com est nommé ns0.company.com.

Résumé des réponses de l'exercice 1 :

  • Enregistrements A et PTR ajoutés pour poste1, poste2, poste3.
  • Enregistrements A et PTR ajoutés pour mail.company.com.
  • Alias CNAME ajouté pour www.company.com pointant vers poste1.company.com.
  • TTL = 604800 secondes (7 jours), paramètres SOA expliqués (numéro de série, refresh, retry, expire, minimum TTL).
  • NS indique le serveur de noms autoritaire ns0 pour la zone.

Exercice 2 : Gestion et configuration d'un serveur DHCP

Cet exercice traite du rôle du protocole DHCP, de l'analyse d'un fichier de configuration dhcpd.conf et de l'extraction de données à partir de logs pour attribuer une IP fixe.

1. Rôle d’un serveur DHCP et informations fournies aux clients

Un serveur DHCP (Dynamic Host Configuration Protocol) attribue automatiquement des adresses IP et d'autres paramètres réseau aux clients qui se connectent au réseau. Les informations qu’il peut fournir incluent :

  • Adresse IP
  • Masque de sous-réseau
  • Adresse de la passerelle (routeur)
  • Adresse du ou des serveurs DNS
  • Durée du bail (temps pendant lequel l’adresse est attribuée)

2. Analyse du fichier dhcpd.conf

subnet 10.1.0.0 netmask 255.255.255.0 {
  option routers 10.1.0.254;
  option domain-name-servers 10.1.0.1;
  range 10.1.0.51 10.1.0.100;
}

(a) Nombre maximum de machines clientes connectées et comportement en cas de dépassement

Le serveur DHCP peut attribuer des adresses dans la plage 10.1.0.51 à 10.1.0.100, soit :

100 - 51 + 1 = 50 adresses disponibles.

Donc, au maximum 50 clients peuvent obtenir une adresse IP. Si plus de 50 clients demandent une adresse, les clients supplémentaires ne recevront pas d’adresse IP et ne pourront pas se connecter au réseau via DHCP.

(b) Ajout pour limiter le bail à 5 minutes

Pour limiter la durée du bail à 5 minutes (300 secondes), on ajoute dans la déclaration du subnet :

default-lease-time 300;
max-lease-time 300;

Ces deux directives garantissent que le bail attribué ne dépasse pas 5 minutes.

(c) Modification pour fixer l’adresse du client « posteC » à 10.1.2.250

Le log indique :

DHCPREQUEST for 10.1.0.67 from 00:15:70:85:9b:ea via 10.1.0.254
DHCPACK on 10.1.0.67 to 00:15:70:85:9b:ea via 10.1.0.254

Pour fixer une adresse IP statique à un client identifié par son adresse MAC, il faut ajouter dans dhcpd.conf une déclaration de host :

host posteC {
  hardware ethernet 00:15:70:85:9b:ea;
  fixed-address 10.1.2.250;
}

Cette configuration attribuera toujours l’adresse 10.1.2.250 au client posteC avec l’adresse MAC indiquée.

Résumé des réponses de l'exercice 2 :

  • Le serveur DHCP attribue des adresses IP et paramètres réseau aux clients.
  • 50 clients maximum peuvent être connectés simultanément avec la plage donnée.
  • Ajout de default-lease-time et max-lease-time à 300 secondes pour limiter le bail à 5 minutes.
  • Déclaration host avec adresse MAC et fixed-address pour fixer l’adresse IP de posteC.

Exercice 3 : Partage de fichiers et sécurisation avec NFS

Cet exercice couvre la configuration d'un serveur NFS pour partager des répertoires en lecture seule ou lecture-écriture, la gestion des droits UNIX et l'utilisation de la commande de montage.

3.1 Contenu du fichier /etc/exports pour le partage de /dirs/public

Le répertoire /dirs/public doit être exporté en lecture seule à toutes les machines du domaine uvt.rnu.tn. La syntaxe est :

/dirs/public  *.uvt.rnu.tn(ro,sync)

Explications :

  • *.uvt.rnu.tn : toutes les machines du domaine.
  • ro : accès en lecture seule.
  • sync : écriture synchronisée pour garantir la cohérence.

3.2 Contenu du fichier /etc/exports pour le partage de /dirs/private

Le répertoire /dirs/private doit être exporté en lecture-écriture uniquement à la machine arwa.uvt.rnu.tn :

/dirs/private  arwa.uvt.rnu.tn(rw,sync)

Explications :

  • arwa.uvt.rnu.tn : machine autorisée.
  • rw : accès lecture-écriture.
  • sync : écriture synchronisée.

3.3 Permissions et propriétaires des répertoires /dirs/public et /dirs/private

Pour que les partages NFS fonctionnent correctement :

  • /dirs/public : doit être lisible par tous les utilisateurs qui accèdent au partage, donc permissions au moins r-x pour les autres. Par exemple, chmod 755 /dirs/public.
  • /dirs/private : doit être accessible en lecture-écriture uniquement par l’utilisateur ou groupe autorisé. Par exemple, propriétaire et groupe définis sur l’utilisateur qui doit écrire, avec permissions rwx------ ou rwxr-x--- selon le besoin.

Les propriétaires doivent correspondre aux utilisateurs qui manipulent ces fichiers sur le serveur NFS.

3.4 Commande pour monter le répertoire partagé public sur arwa.uvt.rnu.tn

Pour monter le partage NFS /dirs/public exporté par pubstorage.uvt.rnu.tn dans le répertoire local /mnt/pubstorage, la commande est :

mount -t nfs pubstorage.uvt.rnu.tn:/dirs/public /mnt/pubstorage

3.5 Explication de la commande d'écriture sur le partage NFS

Après avoir monté le partage NFS en lecture seule sur /mnt/pubstorage, l'exécution de la commande suivante :

echo "bonjour" > /mnt/pubstorage/test.txt

tente d’écrire un fichier nommé test.txt dans le répertoire monté.

Or, /dirs/public est exporté en lecture seule (ro). Par conséquent :

  • Le client arwa envoie une requête d’écriture au serveur NFS.
  • Le serveur refuse l’opération car le partage est en lecture seule.
  • La commande échoue avec un message d’erreur (permission refusée).

Si le partage avait été en lecture-écriture, le contenu "bonjour" aurait été écrit dans test.txt sur le serveur.

Résumé des réponses de l'exercice 3 :

  • Fichier /etc/exports : /dirs/public en lecture seule pour *.uvt.rnu.tn, /dirs/private en lecture-écriture pour arwa.uvt.rnu.tn.
  • Permissions : /dirs/public accessible en lecture, /dirs/private accessible en lecture-écriture par le propriétaire.
  • Commande mount NFS standard pour monter le partage public.
  • Écriture sur un partage en lecture seule échoue, la commande echo génère une erreur.

Méthode et conseils pour réussir l'examen

Ce sujet récompense une bonne maîtrise des configurations réseau classiques (DNS, DHCP, NFS) et la capacité à interpréter des fichiers de configuration et des logs. Il faut :

  • Respecter la syntaxe exacte des fichiers de configuration.
  • Montrer clairement les étapes de raisonnement, notamment pour le calcul des plages d’adresses et l’interprétation des paramètres SOA.
  • Ne pas inventer d’informations manquantes, mais indiquer clairement quand un élément est absent.
  • Expliquer les conséquences pratiques des configurations (exemple : effet du TTL, comportement d’un partage NFS en lecture seule).
  • Éviter les confusions entre zones directes et inverses en DNS.
  • Vérifier les calculs numériques (nombre d’adresses, durées en secondes).

Les erreurs les plus pénalisées sont les oublis d’enregistrements essentiels, la mauvaise interprétation des paramètres SOA, et la confusion entre types d’enregistrements DNS ou permissions NFS.

Toutes les révisions