ENI Ecole Informatique

Une formation, un diplôme, un emploi

Services réseau en environnement Linux

Support de cours

Version 2020-11

Version 2020-11 1
T ABLE DES MATIERES
1 Contexte de mise en œuvre...................................................................................................................... 4
1.1 Les besoins : de l’utilisateur au service ............................................................................................. 4
1.2 Objet et objectifs du cours ................................................................................................................ 5
1.3 Maquette / Bac à sable...................................................................................................................... 5
1.4 Présentation de l'environnement de réalisation............................................................................... 5
1.5 Conventions typographiques............................................................................................................. 6
2 Configuration de l’adressage réseau ........................................................................................................ 7
2.1 Eléments de paramétrage ................................................................................................................. 7
2.2 Outils et méthodes de configuration du réseau................................................................................ 8
2.3 Configurer le réseau .......................................................................................................................... 9
2.4 Configuration du nom d’hôte .......................................................................................................... 12
2.5 Paramétrage client DNS................................................................................................................... 13
3 Routage et traduction ............................................................................................................................. 15
3.1 Concepts du routage ....................................................................................................................... 15
3.2 Les routes : point de configuration au cœur du routage ................................................................ 15
3.3 Gestion dynamique des routes........................................................................................................ 16
3.4 Gestion statique des routes............................................................................................................. 16
3.5 Activation / désactivation du paramètre de routage ...................................................................... 17
3.6 Concepts de la traduction d’adresse ............................................................................................... 18
3.7 Mise en œuvre de la traduction d’adresse...................................................................................... 19
4 Administration à distance ....................................................................................................................... 21
4.1 Les outils d’administration à distance ............................................................................................. 21
4.2 Sécurisation de la connexion SSH .................................................................................................... 22
4.3 Gestion des connexions multiples ................................................................................................... 25
5 Service DNS (Première partie) ................................................................................................................ 26
5.1 Fonctionnement du service DNS ..................................................................................................... 26
5.2 Caractéristiques du serveur DNS résolveur ..................................................................................... 28
5.3 Configuration du DNS résolveur ...................................................................................................... 29
6 Service DHCP ........................................................................................................................................... 32
6.1 Notions DHCP .................................................................................................................................. 32
6.2 Principales requêtes DHCP .............................................................................................................. 32
6.3 Choix du service DHCP ..................................................................................................................... 33
6.4 Configuration du serveur DHCP ....................................................................................................... 33
6.5 Démarrage du service : Service versus Binaire................................................................................ 34

Version 2020-11 2
 6.6 Configuration du relais DHCP .......................................................................................................... 35
7 DNS (Deuxième Partie) ........................................................................................................................... 36
7.1 Caractéristiques du serveur DNS faisant autorité ........................................................................... 36
7.2 Configuration d’un service DNS faisant autorité ............................................................................. 38
7.3 Les fichiers de zone.......................................................................................................................... 39
8 Annexes................................................................................................................................................... 41
8.1 Paramètres vim pour Debian........................................................................................................... 41
8.2 Tolérance de panne avec DHCP ....................................................................................................... 42
8.3 Configuration du DHCP Failover ...................................................................................................... 43
8.4 DNS : Sous domaines et délégation................................................................................................. 46
8.5 DNS : Mises à jour DNS dynamiques ............................................................................................... 48

Gilles BROSSIER, Clément FENDER et Frédéric THOUIN ont participés à la création de

ce support

Version 2020-11 3
1 C ONTEXTE DE MISE EN ŒUVRE

1.1 L ES BESOINS : DE L ’ UTILISATEUR AU SERVICE

Aujourd’hui des équipements divers et variés permettent aux utilisateurs d’accéder aux ressources de leur
entreprise. Station de travail, ordinateur portable, tablette, ordiphone […] sont autant d’interfaces que
l’utilisateur perçoit comme des outils de travail.

Ce même utilisateur peut de plus en plus souvent accéder aux ressources de l’entreprise :
- Alors qu’il est confortablement installé dans son canapé une bière à la main
- Quand il est assis dans le train, alors qu’il se rend en clientèle
- Depuis le réseau informatique d’un client ou partenaire
- Depuis le réseau d’un espace de travail collaboratif
- Dans l’entreprise, depuis son bureau

Interface

Lieu

INTERNET

Contexte réseau de l’entreprise

Services

Derrière les périphériques d’accès, quel que soit le lieu d’où travaillent les utilisateurs, qu’ils soient
raccordés directement au réseau de l’entreprise ou qu’ils transitent par le réseau public mondial Internet,
ils accèdent in fine à des services.

Ces services peuvent être gérés par l’équipe informatique de l’entreprise, être souscrits auprès de
prestataires de solutions cloud ou accessibles publiquement. Ce sont eux sur lesquels travaillent les
utilisateurs, les services sont le cœur du système d’information de l’entreprise.

Ce sont ces services dont vous allez appréhender l’installation, la configuration et la gestion.

Version 2020-11 4
1.2 O BJET ET OBJECTIFS DU COURS
Ce cours a pour objectif d’appréhender la mise en œuvre d’un ensemble de services sur une distribution
GNU/Linux. Les services traités sont des services d’infrastructure réseau, leur mise en œuvre sera réalisée
sous Debian 10.

1.3 M AQUETTE / B AC A SABLE

Les services peuvent être mis en œuvre sur des systèmes d’exploitation de machines physiques ou
virtuelles. Plusieurs services peuvent être mutualisés sur un même système. Alternativement, on peut
dédier un serveur à un service.

Pour les mises en œuvre pratiques de ce cours :

- Tous les serveurs utilisés sont des machines virtuelles
- Les serveurs hébergeront plusieurs services (afin de limiter le nombre de machines virtuelles)

Client d’accès aux

services

Implémentation
de
machines virtuelles services

La solution de virtualisation utilisée pour l’hébergement des machines virtuelles nécessaires aux mises en
œuvre est VMware Workstation.
Afin d’isoler les hôtes des différents réseaux logiques, vous utiliserez des réseaux de machines virtuelles
(VMnet) distincts.

1.4 P RESENTATION DE L ' ENVIRONNEMENT DE REALISATION

Pour les ateliers pratiques, chaque stagiaire travaillera sur sa propre infrastructure. Elle est représentée
page suivante.

Les serveurs et équipements réseau prenant part à l’infrastructure sont répartis sur 4 contextes réseau
distincts :

• Les postes de travail sont connectés au réseau LAN Clients

• Les serveurs sont connectés au réseau dédié LAN Serveurs
• Un inter-réseau est utilisé pour la communication entre le routeur et le pare-feu
• Un réseau public, commun à toutes les infrastructures, permet de fournir des services génériques

Version 2020-11 5
 88.44.22.0 / 24

172.30.num_stag.0 / 24

172.18.num_stag.0 / 24 LAN Clients

192.168.num_stag.0 / 24 LAN Serveurs

Passerelle FAI
88.44.22.254

DHCP DNS

Dans un contexte réel, des commutateurs distincts ou VLAN distincts seraient utilisés. Pour le maquettage,
nous utiliserons des réseaux de machines virtuelles (VMnet) distincts.

1.5 C ONVENTIONS TYPOGRAPHIQUES

La syntaxe des commandes est représentée comme suit :
Commande [options] <Argument>
Les exemples de commande et leur résultat dans le Shell sont représentés comme suit :
$ Commande
Les deux types de prompt :
$ Un prompt commençant par un $ représente un utilisateur standard

# Un prompt commençant par # représente le compte root (l’administrateur du système)

Version 2020-11 6
2 C ONFIGURATION DE L ’ ADRESSAGE RESEAU
Afin qu’une communication puisse se faire entre deux postes, des liens physiques et logiques doivent
exister.

Un réseau physique est matérialisé par l’ensemble des matériels mis en œuvre afin de permettre le
transfert de trames entre différents équipements.

Un réseau logique IPv4 est caractérisé par :

• Une adresse de réseau

• Un masque
• Une adresse de diffusion

2.1 E LEMENTS DE PARAMETRAGE

2.1.1 P ARAMETRAGE D ’ UNE CARTE RESEAU

La configuration réseau d’un poste se traduit par la mise en œuvre d’un ou plusieurs des points suivants :

• La configuration d’une adresse IP d’hôte et du masque associé (le système en déduit les adresses
de réseau et de diffusion)
• La configuration d’une passerelle par défaut
• La définition d’un nom d’hôte
• La configuration cliente DNS

2.1.2 N OMMAGE DES CARTES RESEAU

Le mécanisme de gestion des services systemd a introduit un schéma de nommage particulier pour les
cartes réseau, il s’adapte selon les matériels détectés pour éviter les erreurs d’interprétation.

Dans le cas des machines virtuelles déployées avec VMware Workstation, il se présente la forme ens[1-n].
Cette évolution est apparue avec Debian 9 et Red Hat / CentOS 7.

Sur des systèmes plus anciens le nommage des cartes réseau Ethernet est sous la forme eth[0-n].

La carte de boucle locale (loopback) est identifiée avec la forme spécifique lo.

Version 2020-11 7
2.2 O UTILS ET METHODES DE CONFIGURATION DU RESEAU

2.2.1 C ONFIGURATION DEPUIS LE SERVICE N ETWORK M ANAGER

Si le service Network Manager est installé, il est préférable de l’utiliser pour gérer la configuration réseau
du poste.

# systemctl status NetworkManager

● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor p
Active: active (running) since Mon 2019-05-20 12:24:14 CEST; 66h 6min ago

Méthodes de configuration du Network Manager

Les actions réalisées via Network Manager sont prises en compte immédiatement et durablement.

Le service Network Manager peut être configuré :

• Au moyen de lignes de commandes : via la commande nmcli (Command Line Interface) ; cette
méthode est particulièrement adaptée à l’application de modification via des scripts.
• Au moyen d’une interface textuelle de configuration : via la commande nmtui. Plus conviviale que
les commandes nmcli, c’est une méthode qui requiert l’interaction utilisateur.
• Au moyen d’un composant graphique interagissant avec Network Manager ; cela requiert la
présence d’un environnement graphique sur la machine cible. C’est la méthode privilégiée sur les
stations de travail sous GNU/Linux.

2.2.2 C ONFIGURATION AVEC LA COMMANDE IP

La commande ip permet de gérer la configuration réseau. Le résultat d’exécution de cette commande est
pris en compte immédiatement. Par contre, sans configuration complémentaire, les modifications
apportées dynamiquement par cette commande ne sont pas conservées après redémarrage du service
réseau ou de la machine.

ip [ OPTIONS ] OBJECT { COMMAND | help }

OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable | tunnel | tuntap |
maddr | mroute | mrule | monitor | xfrm | netns | l2tp }
Pour utiliser cette commande, on indique le type d’objet à manipuler suivi de la commande [ + arguments ]
à lui appliquer.

Les commandes disponibles dépendent des objets concernés. Des sections d’aide propres aux différents
objets sont utiles pour lister les commandes disponibles pour le contexte concerné.

$ man ip
$ man ip-address

Version 2020-11 8
2.2.3 C ONFIGURATION DURABLE DANS LE FICHIER INTERFACES

Seules les cartes réseau non configurées via Network Manager sont à configurer dans le
fichier de configuration des interfaces présenté ci-dessous.

Sur un serveur ne disposant pas d'interface graphique, la configuration du réseau passera par la
modification du fichier /etc/network/interfaces.

Après toute modification de ce fichier, il est nécessaire de recharger / redémarrer le service networking
pour leur prise en compte.

# systemctl stop networking

# systemctl start networking

2.3 C ONFIGURER LE RESEAU

2.3.1 C ONFIGURATION DE L ’ ADRESSAGE IP

2.3.1.1 CONFIGURATION DU NETWORK-MANAGER

Des commandes nmcli sont présentées ci-dessous pour la configuration via la Network Manager. Bien que
non présentées dans ce support, des commandes nmtui ou le composant graphique de gestion peuvent
aussi être utilisés.

Affichage de la configuration des interfaces :

$ nmcli
ens33: connecté to Wired connection 1
"Intel 82545EM"
ethernet (e1000), 00:0C:29:08:4B:4C, hw, mtu 1500
ip4 default
inet4 172.16.6.6/24
route4 172.16.6.0/24
[...]

lo: non-géré
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:
servers: 10.0.0.1
domains: demo.eni
interface: ens33

Version 2020-11 9
Modification immédiate et durable de l’adresse IP :
# nmcli connection modify Wired\ connection\ 1 ipv4.addresses 192.168.66.6/24

# nmcli connection modify Wired\ connection\ 1 ipv4.addresses 192.168.66.6/24 ipv4.method manual

# nmcli connection modify Wired\ connection\ 1 +ipv4.addresses 192.168.1.1/24

Modification temporaire (immédiate mais non durable) de l’adresse IP :

# nmcli device modify ens33 ipv4.addresses 192.168.200.150/24 ipv4.method manual

2.3.1.2 CONFIGURATION AVEC LA COMMANDE IP

Affichage de la configuration des interfaces : état d’activation, adressage physique et IP

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:4d:bc:c2 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fe4d:bcc2/64 scope link
valid_lft forever preferred_lft forever

Ajout d’adresse, suppression d’une adresse, suppression de toutes les adresses d’une interface :
# ip a add 10.11.12.13/24 dev ens33

# ip a del 172.16.0.1/16 dev ens37

# ip a flush ens33

Activer / désactiver une interface :

# ip link set ens33 down
# ip l set ens37 up

Version 2020-11 10
2.3.1.3 CONFIGURATION DANS LE FICHIER INTERFACES

Exemple de configuration de l’adressage de deux cartes dans le fichier de configuration des interfaces :
/etc/network/interfaces

# L'interface réseau de loopback => il ne faut pas la modifier

auto lo
iface lo inet loopback

# L'interface ens33 est configurée manuellement.

auto ens33
iface ens33 inet static
address 192.168.66.6
netmask 255.255.0.0

# L'interface ens37 est quant à elle configurée via DHCP.

auto ens37
iface ens37 inet dhcp

2.3.2 C ONFIGURATION DE LA PASSERELLE PAR DEFAUT

2.3.2.1 CONFIGURATION DU NETWORK-MANAGER

Ajout ou modification de l’adresse de la passerelle par défaut :
# nmcli connection modify Wired\ connection\ 1 ipv4.gateway 192.168.66.254

2.3.2.2 CONFIGURATION AVEC LA COMMANDE IP

Afin de visualiser ou modifier la table de routage, nous utiliserons l’objet route de la commande ip.
$ man ip-route
Affichage de la table de routage : itinéraires et passerelles :
$ ip r
default via 192.168.0.254 dev ens37
10.11.0.0/16 dev ens33 proto kernel scope link src 10.11.12.13
192.168.0.0/24 dev ens37 proto kernel scope link src 192.168.0.1
Ajouter une route par défaut :
# ip r add default via 10.11.0.254
Modifier la route par défaut :
# ip r change default via 10.11.255.254
Supprimer la route par défaut :
# ip route del default via 192.168.0.254

Version 2020-11 11
2.3.2.3 CONFIGURATION DANS LE FICHIER INTERFACES
La directive gateway permet de définir la passerelle par défaut dans le fichier /etc/network/interfaces.

# L'interface réseau de loopback => il ne faut pas la modifier

auto lo
iface lo inet loopback

# L'interface ens33 est configurée manuellement.

auto ens33
iface ens33 inet static
address 192.168.66.6
netmask 255.255.0.0
gateway 192.168.66.254

# L'interface ens37 est quant à elle configurée via DHCP.

auto ens37
iface ens37 inet dhcp

2.4 C ONFIGURATION DU NOM D ’ HOTE

Le nom d'hôte peut être un nom court, ou un nom FQDN (Fully Qualified Domain Name) séparé par des
points. La commande hostname affiche le nom de la machine et permet de le modifier dynamiquement.

Celui-ci est configuré dans le fichier /etc/hostname, qui ne doit contenir que le nom de la machine :

srv-lan.demo.eni

Il est possible de modifier le nom d’hôte au moyen de la commande nmcli suivante :

# nmcli general hostname srv-lan.demo.eni

Attention, le nom d’hôte doit être résolu localement ; en cas de changement il faut également modifier le
fichier de correspondances local /etc/hosts.

127.0.0.1 localhost
127.0.1.1 srv-lan.demo.eni srv-lan

Version 2020-11 12
2.5 P ARAMETRAGE CLIENT DNS
Pour que les postes soient en mesure de résoudre des noms d’hôtes en adresses IP, le service DNS est
généralement utilisé. Le ou les adresses IP des serveurs interrogés doivent être renseignées dans les
paramétrages réseau du poste.

2.5.1 C ONFIGURATION DE L ’ ORDRE DE RESOLUTION

La liste ordonnancée des mécanismes utilisés pour la résolution de noms est inscrite derrière la directive
hosts du fichier /etc/nsswitch.conf

$ grep hosts /etc/nsswitch.conf

hosts: files dns

Dans l’exemple présenté ci-dessus, les mécanismes suivants sont utilisés successivement :

1. files : lecture de fichier /etc/hosts

2. dns : interrogation du serveur DNS configuré sur le poste

Dans le cas où un environnement graphique a été installé, le paquet avahi-daemon est également fourni. Il
fournit des méthodes pour faciliter la résolution locale et un cache DNS.

La directive hosts du fichier /etc/nsswitch.conf aura le contenu suivant :

# grep hosts /etc/nsswitch.conf

hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

Dans ce cas, les mécanismes utilisés sont :

1. files : lecture de fichier /etc/hosts

2. mdns4_minimal : interrogation mDNS (multicast DNS) pour les noms d’hôtes IPv4 en .local
3. dns : interrogation du serveur DNS configuré sur le poste
4. myhostname : résolution des noms locaux du poste

2.5.2 C ONFIGURATION DU SERVEUR DNS INTERROGE

Si dns fait partie des services référencés dans ce fichier /etc/nsswitch.conf, le ou les serveurs DNS à
interroger sont alors à configurer.

2.5.2.1 CONFIGURATION DU NETWORK-MANAGER

Ajout ou modification de l’adresse du serveur DNS :
# nmcli connection modify Wired\ connection\ 1 ipv4.dns 192.168.66.1
Pour déclarer plusieurs adresses de serveur, indiquer leurs adresses IP en séparant par une virgule.

Version 2020-11 13
2.5.2.2 CONFIGURATION DANS LE FICHIER RESOLV.CONF
En l’absence du Network-Manager, on configure directement les paramètres DNS dans le fichier
/etc/resolv.conf

search demo.eni ad.campus-eni.fr

domain ad.campus-eni.fr
nameserver 10.0.0.3
nameserver 10.100.0.3
Les directives nameserver indiquent les adresses de serveurs DNS à requêter. Seul en cas d’indisponibilité
du premier, le suivant sera sollicité.
Les directives search et domain permettent de définir une liste de suffixes DNS.

Dans le cas d’une interface réseau configurée en DHCP, les paramètres sont renseignés automatiquement à
partir des informations fournies par le serveur DHCP.

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 1. Mise en œuvre et configuration réseau IPv4 de l’environnement

Version 2020-11 14
3 R OUTAGE ET TRADUCTION

3.1 C ONCEPTS DU ROUTAGE

Le routage est le processus permettant la communication entre des hôtes de réseaux logiques distincts.

172. 16 . 6 .6
255.255.255.0 172.16.2.9

A C

LAN Brest LAN Quimper

B
Lorsqu’un hôte (A) cherche à communiquer avec un autre hôte (C) :

• L’hôte (A), au moyen de son adresse IP d’hôte et de son masque de réseau, détermine si l’hôte
distant (C) est sur le même réseau logique que lui.
• Dans le cas contraire, il recherche dans sa propre table de routage si une route permet de joindre le
réseau de destination ; il en extrait l’adresse de passerelle (B).
• L’hôte (A) transmet ensuite le paquet à la passerelle (B) précédemment identifiée.

3.2 L ES ROUTES : POINT DE CONFIGURATION AU CŒUR DU ROUTAGE

Pour configurer le routage, il faut mettre en œuvre l’ensemble des routes nécessaires à la communication
entre les différents réseaux de l’entreprise et vers l’extérieur de celle-ci. Pour simplifier la gestion, les
routes sont généralement configurées uniquement sur les équipements chargés du service de routage.

Les équipements terminaux : stations de travail, serveurs, […] sont alors configurés en client du ou des
seul(s) routeur(s) de leur réseau logique d’appartenance.

Il est possible de configurer les 3 étendues de routes suivantes :

• Route d’hôte : route permettant d’atteindre un seul hôte ciblé

• Route de réseau : route permettant de joindre les hôtes d’un réseau distant concerné
• Route par défaut : route utilisée en l’absence de route d’hôte ou de réseau pour joindre les hôtes
de tout réseau

Version 2020-11 15
Les routes d’hôtes sont généralement peu utilisées, les routes de réseau sont configurées sur des routeurs
d’entreprises. Les routes par défaut sont utilisées sur les équipements terminaux et les routeurs.

3.3 G ESTION DYNAMIQUE DES ROUTES

La commande ip permet de gérer dynamiquement la configuration de routes.

Principales actions prises en charge par cette commande :

$ man ip-route
ip route
ip route { add | del | change | append | replace } ROUTE

Affichage des routes actuellement configurées sur une machine :

$ ip route
default via 172.16.6.254 dev ens33 proto dhcp metric 100
172.16.6.0/24 dev ens33 proto kernel scope link src 172.16.6.6 metric 100

Ajout de routes d’hôte, réseau et par défaut :

# ip route add 10.11.12.3 via 172.16.6.123
# ip route add 10.56.0.0/16 via 172.16.6.253
# ip route add default via 172.16.6.1

Modification d’une route par défaut :

# ip route change default via 10.9.0.200

Suppression d’une route :

# ip route del 10.56.0.0/16

3.4 G ESTION STATIQUE DES ROUTES

Pour que les routes configurées dynamiquement soient conservées au redémarrage, choisir une des deux
possibilités de mise en œuvre suivantes :

• Export via la commande ip route

• Ajout des commandes de création de routes dans le fichier interfaces (ou un fichier …)

Version 2020-11 16
3.5 A CTIVATION / DESACTIVATION DU PARAMETRE DE ROUTAGE
Le noyau Linux a la capacité de router les paquets qui lui sont remis mais non destinés.

Pour afficher l’état d’activation du paramétrage noyau correspondant :

# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
0 routage inactif 1 routage actif

Pour modifier dynamiquement l’état d’activation du routage, utiliser la commande suivante :

# sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Attention cette modification est immédiate mais temporaire.

Pour modifier durablement l’état d’activation du routage, il faut modifier le fichier de configuration
/etc/sysctl.conf et décommenter la directive existante net.ipv4.ip_forward=1

# vi /etc/sysctl.conf
net.ipv4.ip_forward=1
Pour forcer la prise en compte immédiate des modifications apportées à ce fichier :
# sysctl -p

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 2. Configuration d’une infrastructure réseau routée

Version 2020-11 17
3.6 C ONCEPTS DE LA TRADUCTION D ’ ADRESSE
Le routage permet la communication entre des hôtes de différents réseaux logiques. Cela n’est possible
que si les adresses de réseau sont présentes dans les tables de routages.

Dans les cas contraires :

• Réseau(x) privé(s) non routé(s) sur Internet

• Réseau(x) privé(s) non connu(s) des routeurs de l’entreprise (maquette …)
• Hôtes disposant d’adressage privé dont les services doivent être accessibles depuis le réseau
Internet

Le routage seul n’est pas suffisant et doit être complété par la mise en œuvre de traduction d’adresse.

Réseaux routés

*
Adressage source
*
S NAT

*
* Réseau non routé

La traduction d’adresse (NAT), généralement associée à la traduction de ports (NAPT) peut être utile afin
de :
• Remplacer l’adressage source des paquets IP => NAT de source
• Remplacer l’adressage de destination des paquets IP => NAT de destination

Version 2020-11 18
Sous GNU/Linux, sa mise en œuvre peut être réalisée au moyen de la commande iptables.

3.7 M ISE EN ŒUVRE DE LA TRADUCTION D ’ ADRESSE

Dans le cadre des ateliers pratiques, vous mettrez en œuvre la traduction d’adresse avec une machine
virtuelle pfSense.

3.7.1 P ARAMETRES NAT PF S ENSE

Le NAT/NAPT se configure dans le menu Firewall / NAT.

Plusieurs types de paramétrage sont disponibles :

• Port Forward : redirection de port (et d’adresse), principalement destiné à la gestion des paquets
entrants sur l’interface WAN mais également paramétrable pour les autres interfaces
• 1:1 : one-to-one NAT, pour lier une adresse interne (ou un sous-réseau) spécifique à une adresse
externe (ou un sous-réseau) spécifique
• Outbound : traduction d’adresse sur le trafic sortant des cartes, généralement configuré sur
l’interface WAN pour permettre l’accès au réseau public depuis un adressage privé
• NPt : Network Prefix Translation, équivalent au 1:1 IPv4 mais destiné aux adresses IPv6, permet le
mappage d’un préfixe IPv6 vers un autre

Pour paramétrer le NAT de source, les règles à configurer sont dans la section Outbound

Pour paramétrer le NAT de destination, les règles à configurer sont dans la section Port Forward

3.7.2 C ONFIGURATION DU NAT DE SOURCE

Le NAT de source – Outbound est préconfiguré et activé automatiquement après l’installation de pfSense :

• Pour tous les réseaux privés auquel appartient le routeur/pare-feu pfSense

• Pour tous les réseaux privés pour lesquels une route explicite est configurée

Cela permet donc à tous les hôtes des réseaux privés derrière le routeur/pare-feu d’atteindre les
ressources dans les réseaux publics.

Version 2020-11 19
Paramétrage par défaut du mode Outbound :

Règles par défaut :

Le mode automatique (Automatic outbound NAT rule generation) est préconfiguré après l’installation du
système pfSense. Dans ce mode, les règles ne sont pas configurables mais cela convient aux besoins de
base.

Pour pouvoir éditer et/ou ajouter des règles Outbound, il faut activer le mode hybride ou manuel.

Il est également possible de désactiver le NAT sortant avec le mode Disable outbound NAT rule generation.

La désactivation du pare-feu (option Disable Firewall) dans les paramètres systèmes

avancés désactive toutes les règles de pare-feu AINSI QUE toutes les règles NAT
préconfigurées

Vous trouverez des informations détaillées sur les paramétrages NAT dans la documentation officielle :
https://docs.netgate.com/pfsense/en/latest/nat/outbound-nat.html

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 3. Intégration d’un routeur NAT sous pfSense

Version 2020-11 20
4 A DMINISTRATION A DISTANCE

4.1 L ES OUTILS D ’ ADMINISTRATION A DISTANCE

4.1.1 P ROTOCOLE SSH ET ACCES AU S HELL VIA LE RESEAU

Pour administrer le serveur il est possible de s’y connecter (ouverture d’un Shell) localement ou via le réseau.

Pour la prise en main distante, les cibles suivantes doivent être définies:

• Protocole utilisé
• Logiciel client utilisé
• Logiciel / service utilisé sur le serveur

Le protocole généralement utilisé pour l’établissement de connexions sécurisées via le réseau est le
protocole Secure SHell (SSH). Il est normalisé et sécurisé, les échanges d’informations circulant sur le
réseau étant chiffrés.

Le logiciel client est l’application qui se connecte au serveur SSH. Le logiciel client est à exécuter depuis le
poste sur lequel se trouve l’utilisateur qui souhaite prendre la main sur la machine distante. Les
applications présentées ci-dessous sont couramment utilisées à ces fins.

Application Environnement Principales caractéristiques

Putty Windows Logiciel libre disponible à l’origine uniquement

pour Windows, porté depuis sous d’autres
environnements.
OpenSSH-Client Distributions Fournit la commande ssh, généralement
GNU/Linux implémentée nativement sur les principales
distributions GNU/Linux
Windows Fonctionnalité facultative, installable sur Windows
10 (1903) et Windows 2019.
Fournit la commande ssh
D’autres applications clientes sont abordées au point 4.3 de ce chapitre.

Le logiciel serveur SSH

Pour répondre aux requêtes de connexion du client, un service doit être implémenté sur la machine sur
laquelle l’on souhaite travailler à distance un serveur SSH. C’est généralement OpenSSH-Server qui est
utilisé.

Version 2020-11 21
4.1.2 P ROTOCOLE SSH ET TRANSFERT DE FICHIERS SECURISE
Le protocole SSH peut aussi être utilisé pour sécuriser le transfert de fichiers entre différentes machines.

SSH + CP = SCP

Outils nécessaires à la copie de fichiers

Les outils nécessaires à la copie de fichier via SCP peuvent soit être intégrés au logiciel client SSH soit
nécessiter l’installation d’un logiciel supplémentaire.

OpenSSH-Client WinSCP

Intègre la command scp Outil dédié pour Windows

Exemple d’utilisation de la commande scp

Commande passée sur le poste « client SSH » ci-dessus :

$ scp identifiant@IP_du_serveur:/etc/eniconf.cfg /tmp

Cette commande permet de récupérer sur le poste « client SSH » le fichier /etc/eniconf.cfg du « serveur
SSH »

4.2 S ECURISATION DE LA CONNEXION SSH

La connexion à un serveur SSH nécessite de s’authentifier en précisant le mot de passe à chaque connexion.
Il est possible d’utiliser à la place un échange de clé cryptographique. Cela sécurise la connexion manuelle
et permet les usages automatisés via les scripts.

Il en existe plusieurs types de clés : RSA, DSA, ECDSA … Dans la cadre du support, nous utiliserons les
paramétrages par défaut avec un échange de clé RSA.

Version 2020-11 22
4.2.1 G ENERATION DES CLES COTE CLIENT
Une paire de clé doit être générée côté client pour l’utilisateur devant se connecter en SSH. On utilise pour
cela la commande ssh-keygen fournie avec le paquet OpenSSH-Client.

Création de la paire de clés :

fred@cli-debian:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/fred/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/fred/.ssh/id_rsa.
Your public key has been saved in /home/fred/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:HZrJ3cZaWa4nrmvHqve4oLVVUgfxcPauRZyBbAA8ip8 fred@cli-debian
The key's randomart image is:
+---[RSA 2048]----+
| ....*.+. |
| o X oo|
| . . o o +.+|
| o o.o o |
| o +oooo |
| . o+*Bo |
+----[SHA256]-----+
2 clés sont générées dans le répertoire .ssh dans l’espace personnel de l’utilisateur :
id_rsa : la clé privée de l’utilisateur
id_rsa.pub : la clé publique de l’utilisateur, qui sera copiée sur le serveur SSH

Pour simplifier la mise en œuvre, on utilise ici les paramètres par défaut, sans indiquer de passphrase.
Le type, le nom et la taille de la clé peuvent être précisés avec les options de ssh-keygen.

Il est vivement conseillé, dans un contexte de production, d’indiquer une passphrase.

Cette passphrase devra ensuite être fournie à chaque connexion. Elle peut être gérée et
mise en cache côté client avec le composant ssh-agent.

4.2.2 C OPIE DE LA CLE PUBLIQUE SUR LE SERVEUR DISTANT

Le serveur distant SSH doit disposer de la clé publique de l’utilisateur pour initier et valider la connexion.
On utilise pour cela la commande ssh-copy-id fournie avec le paquet OpenSSH-Client.

Dans un premier temps, la clé publique sera copiée dans l’espace personnel d’un utilisateur standard. Une
fois récupérée sur le serveur distant, elle pourra être associée au compte root.

Par défaut la configuration du démon sshd sur le serveur SSH empêche la connexion de root avec un mot de
passe mais permet la connexion avec les clés RSA.

Version 2020-11 23
Copie de la clé publique vers le serveur SSH :
fred@cli-debian:~$ ssh-copy-id admin@192.168.6.66
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/admin/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are
already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to
install the new keys
fred@192.168.6.66's password:

Number of key(s) added: 1

Now try logging into the machine, with: "ssh 'admin@192.168.6.66'"

and check to make sure that only the key(s) you wanted were added.
Avec les paramètres par défaut, ssh-copy-id :
• Utilise le fichier id_rsa.pub généré précédemment avec ssh-keygen
• Génère un fichier authorized_keys dans le répertoire $HOME/.ssh de l’utilisateur distant avec la clé
• Le mot de passe de connexion est demandé (pour la dernière fois !)

Comme indiqué, il est maintenant possible de se connecter sans authentification sur le serveur SSH avec la
commande :
fred@cli-debian:~$ ssh admin@192.168.6.66

Pour fournir la clé publique au compte root, il faut :

• Se connecter avec le compte root sur le serveur distant
• Créer un répertoire .ssh dans son espace personnel avec les permissions adaptées (700)
• Copier le fichier authorized_keys de l’utilisateur standard vers le répertoire .ssh de root

root@srv-debian:~# mkdir /root/.ssh

root@srv-debian:~# chmod 700 /root/.ssh
root@srv-debian:~# cp /home/admin/.ssh/authorized_keys /root/.ssh/

Il est alors possible de se connecter sans authentification avec le compte root sur le serveur SSH avec la
commande :
fred@cli-debian:~$ ssh root@192.168.6.66

La procédure a été simplifiée et n’est adaptée qu’à un contexte avec un nombre limité de
serveurs et de clients. Dans une infrastructure plus complexe, il faudra gérer un ensemble
de clés et manipuler avec précaution le fichier authorized_keys.
Pour plus de détails, consulter : https://www.ssh.com/ssh/

Version 2020-11 24
4.3 G ESTION DES CONNEXIONS MULTIPLES
Selon l’environnement utilisé pour administrer les serveurs GNU/Linux à distance, plusieurs outils
graphiques sont disponibles pour bénéficier d’un contexte de travail plus efficace et performant.

Depuis un client Windows

Application Caractéristiques

Putty
Outil de base pour se connecter aux serveurs distants.
Supporte les connexions SSH, Telnet, Serial. Permet la sauvegarde des paramètres et
informations de connexion. Intègre la gestion des clés d’authentification (format PPK)
Sous forme d’un fichier exécutable compact (moins d’1 Mo)
Logiciel Open Source sous licence MIT
Site web : https://www.chiark.greenend.org.uk/~sgtatham/putty
mRemoteNG
Outil multifenêtres sous forme d’onglets et multiprotocoles.
Supporte les connexions SSH, RDP, VNC, HTTP, …
Permet la sauvegarde des paramètres et une gestion avancée des informations de
connexion. Compatible avec les paramétrages Putty. Existe au format portable.
Logiciel libre sous licence GNU GPL v2, nécessite le .NET Framework
Sites web : https://mremoteng.org/ - https://mremoteng.readthedocs.io/

MobaXTerm
Outil multifenêtres et multiprotocoles avec une interface graphique évoluée.
Supporte les connexions bureau et terminal à distance (RDP, VNC, XDMCP, SSH, Telnet,
FTP, …). Prend en charge les tunnels SSH. Fournit une gestion avancée des connexions
et des outils complémentaires : SFTP, macros, environnement CLI de base (Cygwin), …
Existe au format portable.
Logiciel non libre, version Home gratuite limitée (12 sessions, 2 tunnels SSH)
Site web : https://mobaxterm.mobatek.net/

Depuis un client GNU/Linux

Toute distribution GNU/Linux incorpore un terminal permettant de gérer plusieurs connexions SSH
simultanées sous forme d’onglets. L’outil Terminator disponible sur les dépôts de la plupart des
distributions peut être installé pour disposer de plus de fonctionnalités :

• Affichage multifenêtres avec découpage horizontal et/ou vertical

• Connexion automatique au serveur distant (via le fichier de configuration)
• Groupement de commandes sur plusieurs fenêtres
• …

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 4. Configuration du service SSH

Version 2020-11 25
5 S ERVICE DNS (P REMIERE PARTIE )

5.1 F ONCTIONNEMENT DU SERVICE DNS

DNS – pour Domain Name System est un protocole standardisé par l’IETF (Internet Engineering Task Force).
C’est un des protocoles essentiels au fonctionnement d’Internet.

Utilité

Bien qu’il ne se résume pas uniquement à cela, son rôle premier est de donner des correspondances entre
des noms d’hôtes pleinement qualifiés (Fully Qualified Domain Name ou FQDN) et la ou les adresse·s IP
associée·s.

Le service DNS permet aussi :

• De donner le nom associé à une adresse IP connue (résolution inverse)

• D’indiquer quels hôtes fournissent un service donné (résolution de services)
• D’indiquer quel·s est/sont le·s serveur·s de messagerie d’un domaine cible
• De faire le café

La structure de nommage DNS est arborescente.

Le point par lequel se termine tout nom de domaine,

. ( 1)
représente la racine de l’espace de nom DNS
com. Nom de domaine, sous domaine du domaine racine
. (2) Point / caractère de séparation entre domaines
indiatimes.com. Nom de domaine, sous domaine du domaine « com. »

Point / caractère de séparation entre le nom du domaine et le nom d’un

. (3)
hôte de ce domaine
www.indiatimes.com. Nom d’hôte pleinement qualifié

Version 2020-11 26
La séparation entre les différents niveaux d’arborescence est représentée par le caractère « point ».

Contextes et limite de résolution de noms de domaines

La résolution de noms est utilisée sur le réseau public Internet pour référencer des ressources de ce réseau.
Un ensemble de domaines publics de premier niveau sont administrés par l’IANA (Internet Assigned
Numbers Authority) et des entités sont chargées de leur gestion.

Le protocole DNS peut aussi être utilisé pour la résolution de domaines sans suffixes publics, non
résolvables par les serveurs DNS Internet mais pouvant être résolus en interne.

Lors du choix de création d’un nom de domaine pour y référencer des hôtes, on détermine si ce nom ne
pourra être résolu qu’en interne (suffixe non public) ou si celui-ci doit pouvoir être résolu globalement
(enregistrement d’un nom de domaine public auprès d’un bureau d’enregistrement).

domaine utilité

masuperentreprise.bzh Nom de domaine utilisé pour référencer les services de mon entreprise
accessibles depuis l’Internet
enigmes.corp Nom de domaine propre à mon entreprise dans lequel sont référencées les
ressources hébergées et accessibles uniquement localement dans l’entreprise

Besoins et types de serveurs DNS

Lors du déploiement d’un service DNS, celui-ci peut être configuré pour :

- Résoudre les requêtes clientes relatives à tout domaine / résolveur DSN complet
- Être source d’information pour un ou plusieurs domaines ciblés / serveur faisant autorité

L’implémentation et la configuration du service est distincte en fonction de l’utilisation de celui-ci.

Le serveur DNS résolveur complet

- C’est le service chargé de répondre aux requêtes des clients (1)

- Pour y répondre il fait appel à d’autres serveurs DNS (2)
- Il n’est pas source d’information de domaines

Le serveur DNS faisant autorité est abordé au point 7.1 de ce cours.

Version 2020-11 27
5.2 C ARACTERISTIQUES DU SERVEUR DNS RESOLVEUR
Un serveur DNS résolveur complet fait appel aux services d’autres serveurs DNS pour résoudre les requêtes
qui lui sont adressées.

Par défaut il connait les noms et adresses IP des serveurs racines, il leur adresse des requêtes itératives
afin de résoudre les noms qu’il doit résoudre. Au moyen de requêtes itératives, il contacte ensuite
successivement un ensemble de serveurs faisant autorité pour remonter au serveur de l’espace de noms
donné.

Il est possible de configurer des serveurs redirecteurs afin de limiter les échanges nécessaires à la
résolution de noms. Lorsqu’un redirecteur inconditionnel est configuré, le serveur lui adresse des requêtes
récursives afin de résoudre les noms demandés par ses clients.

La configuration d’un redirecteur conditionnel permet d’indiquer pour un espace de nom donné (la
condition) le serveur à qui adresser la requête récursive de résolution.

La configuration de redirection conditionnelle et inconditionnelle peut être complémentaire.

Le serveur conserve en mémoire cache les réponses aux requêtes de résolution qu’il a transmises à ses
clients. La durée de conservation en cache est définie par les serveurs faisant autorité, elle est subie par les
serveurs DNS résolveurs.

Version 2020-11 28
5.3 C ONFIGURATION DU DNS RESOLVEUR

Nom du paquet bind9

Fichier de configuration /etc/bind/named.conf

Nom du service bind9

Commandes named-checkconf
named-checkzone
rndc

Fichier journal /var/log/syslog

5.3.1 C ONFIGURATION INITIALE DE B IND 9 SOUS D EBIAN

La configuration illustrée ci-après résulte d’une installation de Bind9 sous Debian10 depuis les dépôts
officiels. Le fichier de configuration « principal » renvoie vers 3 fichiers dans lesquels sont répartis les
différentes directives de configuration du service.

/etc/bind/named.conf

[...]

include /etc/bind/named.conf.options ;
options {
directory "/vcb"/ ;
Configuration des options
[…]

include /etc/bind/named.conf.local ; zone "demo.eni" {

[…] Configuration des zones
hébergées localement

include /etc/bind/named.conf.default-zones ; zone "localhost" {

[…] Configuration des zones
par défaut

[…]

Version 2020-11 29
5.3.2 F ICHIERS DE CONFIGURATION D ’ UN SERVICE DNS RESOLVEUR
Fichier /etc/bind/named.conf
// rsxclts = réseaux des postes clients de l’entreprise
acl rsxclts { 127.0.0.0/8; 192.168.53.0/24; 192.168.1.0/24; };

include /etc/bind/named.conf.options ;
include /etc/bind/named.conf.local;
include /etc/bind/named.conf.default-zones ;

Fichier /etc/bind/named.conf.options
options {
// Répertoire de travail de Bind9
directory "/var/cache/bind";

// Redirection exclusive (pas d’appel aux racines en cas d’indisponibilité)

// vers les serveurs Quad9
forward only;
forwarders { 9.9.9.9; }; toujours maitre un point virgule a chaque fin de syntaxe

// Restriction des hôtes auxquels répond le serveur

allow-query { rsxclts; };
// Restriction des hôtes autorisés à adresser des requêtes récursives au serveur
allow-recursion { rsxclts; };

// Communication DNSSEC désactivée

dnssec-enable no;
dnssec-validation no;

// Information de version non communiquée

version none;
};

Fichier /etc/bind/named.conf.default-zones (préconfiguré)

// RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

Version 2020-11 30
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
Les fichiers de zone ciblés dans l’exemple de configuration ci-dessus sont présents par défaut suite à
l’installation du service Bind9.

5.3.3 C ONFIGURATION DE REDIRECTEUR CONDITIONNEL

Pour configurer un redirecteur conditionnel, une zone typée forward doit être ajoutée à la configuration de
Bind9 dans le fichier /etc/bind/named.conf.local, comme dans l’exemple ci-dessous :

zone macharmantevoisine.eni {
type forward;
forward only;
forwarders { 10.0.0.53; };
};

5.3.4 R ESSOURCES COMPLEMENTAIRES

La documentation de référence de Bind9 fournit la liste exhaustive de ses directives et options de
configuration de Bind9 :

https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 5. Configurer un service DNS résolveur

Version 2020-11 31
6 S ERVICE DHCP

6.1 N OTIONS DHCP

Le protocole DHCP (Dynamic Host Protocol Configuration) est normalisé par un ensemble de RFC. Le service
DHCP implémente le protocole DHCP, il permet de fournir des informations de configuration IP aux
équipements qui y font appel.

L’utilisation du service DHCP permet de centraliser la gestion de la configuration de l’adressage IP des

postes et autres équipements réseau.

Principaux avantages liés à l’utilisation de ce service :

• Optimisation de l’utilisation de plage d’adresse réseau

• Risque d’erreur limité
• Simplifie la gestion de l’adressage d’équipements réseau
• Simplicité / rapidité de propagation de mise à jour de configuration réseau

6.2 P RINCIPALES REQUETES DHCP

Détail des échanges du processus d’obtention d’un bail

IPv4 IPv6 *
1 1
------------------> ------------------>
Discover Solicit
2 2
<------------------ <------------------
Offer Advertise
3 3
------------------> ------------------>
Request Request
4 4
<------------------ <------------------
Ack Reply

* L’illustration ci-dessus correspond à la situation dans laquelle le poste client IPv6 cherche à obtenir un bail
contenant une adresse IP. Sous IPv6 il est possible de ne demander que des informations de configuration
complémentaires à l’adressage ; dans ce cas seul les requêtes Information-Request (du client au
serveur) et Reply (du serveur au client) sont utilisées.

Version 2020-11 32
6.3 C HOIX DU SERVICE DHCP
Sous GNU/Linux, plusieurs services DHCP peuvent être implémentés. Parmi les différentes possibilités, nous
retenons les services créés et soutenus par l’ISC (Internet Systems Consortium), gage de qualité et de
respect des RFC.

L’ISC soutient les deux implémentations suivantes :

Service actuellement très répandu

Pas de grande modification du service à venir (version 4.4.x courante et

+ dernière prévue)
isc-dhcp-server
Facilité de mise en œuvre

- Service amené à ne plus évoluer

+ Produit en devenir

kea Service actuellement moins utilisé

-
Format du fichier de configuration plus difficile à appréhender

Le service DHCP retenu dans le cadre de ce cours est le service isc-dhcp-server.

6.4 C ONFIGURATION DU SERVEUR DHCP

Nom du paquet isc-dhcp-server

Fichiers de configuration /etc/default/isc-dhcp-server (les cartes d'écoutes)

/etc/dhcp/dhcpd.conf

Fichier de baux /var/lib/dhcp/dhcpd.leases

Nom du service isc-dhcp-server

Fichier journal /var/log/syslog

Configuration globale du démon

Y configurer à minima la ou les interfaces sur lesquelles le service doit être à l’écoute.

# vi /etc/default/isc-dhcp-server

INTERFACESv4="ens35"
INTERFACESv6=""

Version 2020-11 33
Configuration du service

# vi /etc/dhcp/dhcpd.conf

option domain-name "demo.eni";

option domain-name-servers 172.16.17.18;
# 6H 6m 6s = 21966s
default-lease-time 21966;
max-lease-time 42000;

ddns-update-style none;

authoritative;
log-facility local7;

subnet 192.168.42.0 netmask 255.255.255.0 {

}

subnet 172.19.0.0 netmask 255.255.0.0 {

range 172.19.2.0 172.19.9.255;
option routers 172.19.1.1;
}

host wifi-hp-04 {
hardware ethernet 08:00:07:26:c0:a5;
fixed-address 172.20.0.2;
}

Contrôle syntaxique de la configuration du service :

root@srv-barbichette# dhcpd –t

Internet Systems Consortium DHCP Server 4.4.1

Config file: /etc/dhcp/dhcpd.conf
Database file: /var/lib/dhcp/dhcpd.leases
PID file: /var/run/dhcpd.pid

6.5 D EMARRAGE DU SERVICE : S ERVICE VERSUS B INAIRE

En mode de fonctionnement normal, on utilise les commandes de gestion SystemD pour gérer le service :
# systemctl status isc-dhcp-server
# systemctl stop isc-dhcp-server
# systemctl start isc-dhcp-server
# systemctl restart isc-dhcp-server

A des fins de dépannage ou d’analyse, il peut être utile pour les services serveur DHCP et relais DHCP d’être
appelé directement via leur fichier binaire. Cela permet notamment de spécifier des options de lancement
(comme l’option de debug pour le service isc-dhcp-server).

Version 2020-11 34
 Dans ce cas, veiller au préalable à bien s’assurer que le service est en état arrêté pour
SystemD, ou l’arrêter au besoin.

Lancement du service en mode debug à l’aide du binaire :

# dhcpd –d

6.6 C ONFIGURATION DU RELAIS DHCP

La mise en place de relais DHCP est nécessaire si les clients sont en dehors du domaine de diffusion du / des
serveur(s) DHCP. Sur Debian, le paquet isc-dhcp-relay peut être installé pour fournir ce service.

Un assistant de configuration se lance automatiquement lors de l’installation du paquet. Il permet de

renseigner le fichier de configuration /etc/default/isc-dhcp-relay avec les paramétrages nécessaires :

• La ou les adresses des serveurs DHCP ciblés par le relais

• Le ou les cartes réseau par lesquelles transitent les requêtes DHCP
• Les options à transmettre pour démarrage du démon

Exemple de configuration :
# vi /etc/default/isc-dhcp-relay

# Defaults for isc-dhcp-relay initscript

# What servers should the DHCP relay forward requests to?

SERVERS="192.168.42.2"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="ens33 ens35"

# Additional options that are passed to the DHCP relay daemon?

OPTIONS=""

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 6. Configurer le service DHCP isc-dhcp-server

Version 2020-11 35
7 DNS (D EUXIEME P ARTIE )

7.1 C ARACTERISTIQUES DU SERVEUR DNS FAISANT AUTORITE

7.1.1 L E SERVEUR DNS FAISANT AUTORITE

- Il est source d’information pour un ou plusieurs domaines
- A ce titre, il est interrogé par des serveurs DNS résolveurs pour résoudre des noms de son domaine
hébergé ou de domaines enfants
- Il peut inscrire des informations dans la zone du domaine hébergé ou ne disposer que d’une copie
de la zone

7.1.2 L ES NOTIONS DE « ZONE »

Zone Zone directe Zone inverse

Une zone rassemble un ensemble d’éléments ayant une caractéristique commune. Cette caractéristique
peut être une partie du nom de domaine ou un réseau IP d’appartenance.

Une zone directe référence des équipements appartenant à un même nom de domaine.

Version 2020-11 36
Une zone inverse référence des équipements appartenant à un même réseau logique.

7.1.3 L ES ENREGISTREMENTS
Les informations ou données d’une zone sont stockées sous forme d’enregistrements.

Les principaux enregistrements sont :

Type Utilité

Contient les caractéristiques de la zone, identifie par un FQDN résolvable le serveur qui peut y
SOA
écrire.

Identifie par un FQDN résolvable le·s serveur·s qui dispose·nt d’un exemplaire de la zone et
NS
fait / font autorité pour celle-ci.

A Correspondance entre un nom (connu) et une adresse IPv4 (attendue)

AAAA Correspondance entre un nom (connu) et une adresse IPv6 (attendue)

SRV Correspondance entre un type de service et le FQDN du serveur le fournissant

MX Permet d’identifier le·s serveur·s de messagerie d’un domaine donné

CNAME Correspondance entre un nom et un autre nom

Correspondance entre une adresse d’hôte (connue) et un FQDN (attendu)

PTR
Enregistrements uniquement présents dans des zones inverses

Version 2020-11 37
7.1.4 S ERVEUR PRIMAIRE OU SECONDAIRE
Un serveur faisant autorité pour une zone peut être source d’information et de modification de celle-ci. Il
peut dans ce cas écrire dans la zone pour y ajouter des enregistrements, en modifier ou en supprimer.
Généralement un seul serveur dispose de ces privilèges sur une zone, c’est le serveur primaire de celle-ci.
Le serveur primaire d’une zone peut aussi être appelé serveur maitre de celle-ci.

Alternativement, un serveur faisant autorité pour une zone peut ne disposer que d’une copie de celle-ci. Il
a récupéré cette zone et récupère ses mises à jour auprès d’un serveur primaire de celle-ci, il ne peut pas y
apporter de modifications. Ce serveur est un serveur secondaire de la zone aussi dénommé serveur
esclave de cette zone.

7.2 C ONFIGURATION D ’ UN SERVICE DNS FAISANT AUTORITE

Un serveur Bind9 faisant autorité doit disposer de deux éléments : la configuration et les données. Ces
éléments sont contenus dans des fichiers bien distincts.

Configuration Données

/etc/bind/named.conf.local

zone eni.demo {
file "db.eni.demo"; }; /var/cache/bind/db.eni.demo

$TTL 86400
@ IN SOA dns1.eni.demo.
contact.eni.demo. (
20191002 ; serial
[...]

Les fichiers de configuration sont présentés dans ce chapitre. Les fichiers de zone sont présentés dans le
chapitre suivant.

7.2.1 C ONFIGURATION D ’ UN SERVEUR PRIMAIRE

Exemple de fichier de configuration d’une zone directe :
# vi /etc/bind/named.conf.local

zone "eni.demo" { Déclaration de la zone directe principale en

type master; chargeant le fichier db.eni.demo
file "db.eni.demo";
allow-transfer { 10.11.0.53; }; Autorisation du transfert de zone
};

Version 2020-11 38
Exemple de fichier de configuration d’une zone inverse :
# vi /etc/bind/named.conf.local

zone "42.168.192.in-addr.arpa" { Déclaration de la zone inverse principale en

type master; chargeant le fichier db.192.168.42.inv
file "db.192.168.42.inv";
};

Les fichiers de configuration de zone précédemment présentés requièrent que les fichiers
de zone correspondants : db.eni.demo et db.192.168.42.inv existent et qu’ils contiennent
toutes les informations concernant ces zones.
Des exemples de fichiers de zone sont présentés dans le prochain chapitre.

7.2.2 C ONFIGURATION D ’ UN SERVEUR SECONDAIRE

Exemple de fichier de configuration d’un serveur secondaire d’une zone directe :

# vi /etc/bind/named.conf.local

zone "eni.demo" { Déclaration de la zone directe secondaire

type slave; à partir du serveur principal
masters { 10.5.3.10; }; en chargeant le fichier db.eni.demo
file "db.eni.demo";
allow-query { any; }; Autorisation des requêtes par le client
};

7.3 L ES FICHIERS DE ZONE

Exemple de fichier de zone directe :

; fichier de zone du domaine eni-ecole.bzh Directives de configuration

; point-virgule = commentaire en début / en cours de ligne s’appliquant à tous les
enregistrements suivants
$ORIGIN eni-ecole.bzh.
$TTL 86400
@ SOA dns1.eni-ecole.bzh. hostmaster.eni-ecole.bzh. ( Enregistrements SOA et NS
2019100253 ; serial relatifs à la zone
86400 ; refresh 1 day
7200 ; retry 2 hours
3600000 ; expire
3600 ) ; negative TTL
;
@ NS dns1.eni-ecole.bzh.
@ NS dns2.eni-ecole.bzh.

Version 2020-11 39
 dns1 A 44.0.5.3 Autres enregistrements de la
dns1 AAAA 2001:0db8::ec01:e zone
dns2 AAAA 2001:0db8::ec01:e53
www A 44.0.0.80
rdsgw A 35.12.13.15
smtp A 44.0.0.25
ww CNAME www.eni-ecole.bzh.
wwww CNAME www.eni-ecole.bzh.
@ MX 10 smtp.eni-ecole.bzh.
@ MX 20 mx0.mail.ovh.net.

Exemple de fichier de zone inverse :

; zone inverse pour le réseau 192.168.42.0/24 Directives de configuration

s’appliquant à tous les
$TTL 86400 enregistrements suivants
@ SOA dns1.eni.demo. hostmaster.eni.demo. ( Enregistrements SOA et NS
2019100253 ; serial relatifs à la zone
86400 ; refresh 1 day
7200 ; retry 2 hours
3600000 ; expire
3600 ) ; negative TTL
;
@ NS dns1.eni.demo.
1 PTR srv01.eni.demo. Autres enregistrements de la
2 PTR srv02.eni.demo. zone
13 PTR lucky.eni.demo.
254 PTR gw42.infra.eni.

Pour valider le chapitre, vous réaliserez l’atelier suivant :

Atelier 7. Configurer un service DNS faisant autorité

Version 2020-11 40
8 A NNEXES

8.1 P ARAMETRES VIM POUR D EBIAN

Depuis Debian 9, vim a un comportement plutôt désagréable :
• La sélection avec la souris bascule vim en mode visuel (Visual Mode)
• La copie d’un bloc comportant des lignes commentées génère des lignes commentées après la
première ligne commentée

Par exemple, en copiant ce bloc :

if machin = $truc ;
#alors je fais faire ça :
echo coucou
fi

Quand on colle celui-ci, cela donne ce résultat :

if machin = $truc ;
#alors je fais faire ça :
#echo coucou
#fi

Enfin, dans la version de Debian 9, si on crée son propre fichier .vimrc dans son répertoire personnel, alors
tous les paramètres généraux présents dans /etc/vim/vimrc ne sont plus pris en charge.

Pour retrouver un comportement normal, il faut créer un fichier /etc/vim/vimrc.local avec les paramètres
suivants :
source /usr/share/vim/vim81/defaults.vim
let skip_defaults_vim = 1
if has('mouse')
set mouse=r
endif
set paste

Si au lancement il y a une erreur, il faut corriger le chemin /usr/share/vim/vimXX ou XX correspond à la

version de vim.

Version 2020-11 41
8.2 T OLERANCE DE PANNE AVEC DHCP
Pour accroitre la tolérance de pannes du service, il est possible d’ajouter d’autres instances du service
(autres serveurs DHCP). Il faut alors répartir la plage d’adresses entre les différentes instances du service.
Quand on dispose d’un serveur DHCP principal et d’un second (de secours), le serveur principal dispose du
plus grand nombre d’adresses à allouer. Le serveur « de secours » ne peut distribuer qu’un nombre limité
d’adresses, afin d’opérer la continuité du service en attendant le rétablissement du serveur principal.

450 adresses 50

C’est généralement la règle des « 80/20 » que l’on applique afin de répartir entre les deux serveurs le
pourcentage d’adresses à distribuer.

Pour privilégier le service du serveur « principal », il est possible de retarder la délivrance de baux sur le
serveur « de secours » en utilisant la directive de configuration min-secs.

Exemple de configuration d’un service DHCP « de secours » :

# vi /etc/dhcp/dhcpd.conf

default-lease-time 1800; Durées de baux courtes

max-lease-time 3600;

not authoritative; Service ne faisant pas autorité et

min-secs 5; temporisation avant réponse

subnet 172.19.0.0 netmask 255.255.0.0 {

range 172.19.10.0 172.19.10.255;
option routers 172.19.1.1;
}

Version 2020-11 42
8.3 C ONFIGURATION DU DHCP F AILOVER

8.3.1 U TILITE ET PRINCIPE DE FONCTIONNEMENT DU FAILOVER

La fonctionnalité de Failover du service DHCP permet à plusieurs serveurs DHCP de distribuer des baux
d’une même plage :

• Plusieurs serveurs = tolérance de pannes, si un serveur n’est plus fonctionnel, le service est
toujours disponible
• Baux d’une même plage = cela évite de perdre une plage d’adresse quand le serveur disposant de
cette plage cesse de fonctionner

La configuration de la fonctionnalité DHCP Failover permet de bénéficier de tolérance de pannes tout en

optimisant l’utilisation de la plage d’adresse IP distribuée.

Version 2020-11 43
8.3.2 C ONFIGURATION
Sont présentées ci-dessous les configurations des services DHCP principal et secondaire :

Configuration du serveur principal Configuration du serveur secondaire

failover peer "lancli-failover" { failover peer "lancli-failover" {
primary; secondary;

address dhcp-1.demo.eni; address dhcp-2.demo.eni;

port 647; port 647;

peer address dhcp-2.demo.eni; peer address dhcp-1.demo.eni;

peer port 647; peer port 647;

max-response-delay 60; max-response-delay 60;

max-unacked-updates 10; max-unacked-updates 10;
load balance max seconds 3; load balance max seconds 3;
}
mclt 3600;
split 128;
}
subnet 10.9.0.0 netmask 255.255.0.0 { subnet 10.9.0.0 netmask 255.255.0.0 {
option routers 10.9.255.254; option routers 10.9.255.254;
pool { pool {
failover peer "lancli-failover"; failover peer "lancli-failover";
range 10.9.1.0 10.9.9.255; range 10.9.1.0 10.9.9.255;
} }
} }

Signification des directives utilisées dans la configuration présentée précédemment :

max-response-delay Intervalle de temps (en secondes) au-delà duquel un serveur n’ayant
pas eu de message de son partenaire considère que celui-ci est
défaillant.
max-unacked-updates Nombre de messages d’information de mise à jour (BNPUPD) pouvant
être transmis au partenaire avant l’envoi d’un accusé de réception
(BNPACK).
load balance max seconds Limite du délai, depuis la dernière requête du client, au-delà duquel le
serveur y répondra outrepassant la configuration du failover.
mclt Max Client Lead Time : délai (en secondes) pendant lequel un serveur
peut renouveler un bail obtenu auprès de l’autre serveur.
split Paramètre permettant de moduler la répartition de charge entre le
serveur principal et le secondaire. Sa valeur doit être comprise entre 0
et 255. Plus la valeur est proche de 0, plus le serveur secondaire sera
sollicité ; plus elle se rapproche de 255, plus grand sera le nombre de
clients du serveur principal.

La valeur d’équilibre est 128.

Version 2020-11 44
Sécurisation des échanges

En complément de la configuration présentée précédemment, il est possible de sécuriser les échanges

entre les deux serveurs DHCP prenant part au Failover. Pour ce faire, on ajoute les directives de
configuration ci-dessous à la configuration des deux services.

omapi-port 7911;
key omapi_cle {
algorithm hmac-md5;
secret FFD3yBBsq8F+FW1EhvEAUg==;
}
omapi-key omapi_cle;

La valeur renseignée pour la directive secret pourra être générée avec la commande dnssec-keygen.

Version 2020-11 45
8.4 DNS : S OUS DOMAINES ET DELEGATION

8.4.1 S OUS - DOMAINES , CONCEPT ET MISE EN ŒUVRE

La hiérarchie DNS permet de déclarer des sous-domaines relatifs au domaine parent. Cela permet de gérer
des noms dans un espace de noms dédié tout en conservant les informations dans le même fichier zone
que le domaine parent.

Cela ne nécessite aucune modification dans la configuration du service utilisé, la différenciation se fait
uniquement dans les données du fichier de zone.

Exemple de fichier de zone directe avec un sous-domaine :

; fichier de zone du domaine eni-ecole.bzh

$ORIGIN eni-ecole.bzh.
$TTL 86400
@ SOA dns1.eni-ecole.bzh. hostmaster.eni-ecole.bzh. ( Enregistrements SOA et NS
2019100253 ; serial relatifs à la zone parente
86400 ; refresh 1 day
7200 ; retry 2 hours
3600000 ; expire
3600 ) ; negative TTL
;
@ NS dns1.eni-ecole.bzh.
@ NS dns2.eni-ecole.bzh.
dns1 A 44.0.5.3 Enregistrement relatifs au
dns1 AAAA 2001:0db8::ec01:e domaine parent eni-ecole.bzh
dns2 AAAA 2001:0db8::ec01:e53
www A 44.0.0.80
rdsgw A 35.12.13.15
smtp A 44.0.0.25
ww CNAME www.eni-ecole.bzh.
wwww CNAME www.eni-ecole.bzh.
www.cdb A 35.12.13.16 Enregistrements pour les sous-
rds.cdb A 35.12.13.17 domaines cdb et nrt
www.nrt A 79.21.22.23
rds.nrt A 79.21.22.24

Les sous-domaines cdb.eni-ecole.bzh et nrt.eni-ecole.bzh sont configurés chacun avec 2 enregistrements

www et rds.

Version 2020-11 46
8.4.2 D ELEGATION , CONCEPT ET MISE EN ŒUVRE

La délégation indique à un serveur DNS sa limite

d’autorité pour un ou plusieurs espaces de noms
enfants de zones hébergées.

Quand un serveur gère un domaine de noms donné

mais ne gère pas toute ou partie des domaines
enfants de cette zone, la délégation permet
d’indiquer dans la zone parente qui fait autorité pour
le ou les domaines enfants.

La délégation est inscrite dans la zone : y sont

référencés le·s serveur·s faisant autorité pour le
domaine enfant ciblé.

Cela nécessite une configuration spécifique du

serveur DNS gérant la zone parente et la
configuration d’un autre serveur DNS pour la gestion
de la zone déléguée.

Exemple de fichier de zone du domaine prism.lcl contenant une délégation pour l’espace de noms
enfant fiveeye.prism.lcl :
$ORIGIN prism.lcl.
$TTL 86400
@ SOA nsa.prism.lcl. esnowden.prism.lcl. (
2019100301 86400 7200 3600000 3600 )
;
@ NS nsa.prism.lcl.
nsa A 10.0.255.53
file01 A 10.0.0.1
; Délégation vers le serveur NS du domaine enfant
fiveeye.prism.lcl. NS nsb.prism.lcl.
; Enregistrement d’hôte du NS déclaré pour le sous-domaine (glue record)
nsb A 10.2.0.53
La configuration précédente est suffisante si le serveur DNS est uniquement hébergeur pour la zone
considérée. Par contre, si ce serveur joue aussi le rôle de serveur résolveur, il faut en complément adapter
la configuration de la zone parente.
Configuration complémentaire apportée à la configuration de Bind9 :
zone "prism.lcl" {
type master;
file "db.prism.lcl";
forwarders {};
};
La directive forwarders {}; est utilisée pour désactiver - uniquement pour la zone prism.lcl - les paramètres
globaux forwarders configurés dans le fichier /etc/bind/named.conf.options. Cela permet l’interrogation du
serveur NS nsb.prism.lcl désigné dans le fichier de zone.

Version 2020-11 47
8.5 DNS : M ISES A JOUR DNS DYNAMIQUES
Par défaut sur Bind9, seule la configuration statique des enregistrements DNS est possible dans les fichiers
de zone. La mise à jour dynamique des zones – c’est-à-dire la mise à jour des enregistrements par les
clients eux-mêmes – n’est pas autorisée.

On peut permettre la mise à jour dynamique pour un ensemble de postes clients ou pour seulement des
serveurs dédiés (serveurs DHCP) qui pourront agir pour le compte des clients.

PC-CLI01 PC-CLI02

DHCP DNS

DNS UPDATE
MESSAGE

Subnet Dynamic

10.11.12.0/24
Zone
infra.eni
DNS
Update V
10.11.12.13 PC-CLI01 PC-CLI01 A 10.11.12.13
10.11.12.13 PC-CLI02 PC-CLI01 A 10.11.12.13

8.5.1 C ONFIGURATION DNS POUR LES MISES A JOUR DYNAMIQUES

Dans la configuration de Bind9, la mise à jour dynamique nécessite une configuration explicite avec la
directive allow-update à l’échelle de chacun des domaines concernés. On pourra délimiter le ou les clients
concernés en utilisant des adresses d’hôtes ou de réseaux.

L’activation des mises à jour dynamiques pour le domaine ciblé modifie fortement le comportement du
service Bind9 pour le fichier de zone concerné :

• Bind9 s’approprie totalement le fichier de zone, les modifications manuelles directement dans le
fichier ne sont plus possibles sans précautions
• Le numéro de série de la zone est incrémenté automatiquement lors des modifications
• Un fichier nom_du_fichier_de_zone.jnl est créé au même emplacement que le fichier de zone, il
sert à journaliser les demandes de mise à jour dynamique avant la fusion dans le fichier de zone

Version 2020-11 48
Exemple d’activation de la mise à jour dynamique DNS pour une zone directe :
# vi /etc/bind/named.conf.local

zone "eni.demo" { Déclaration de la zone directe principale en

type master; chargeant le fichier db.eni.demo
file "db.eni.demo";
allow-update { Autorisation des mises à jour dynamiques
192.168.53.0/24; exclusivement pour les clients du réseau cité
localhost; et depuis les adresses locales du serveur
}; (boucle locale comprise)
};

La mise à jour dynamique par les clients n’a lieu que si le suffixe DNS du domaine ciblé est
correctement configuré sur les postes clients.
Pour les postes Windows, il s’agit du paramètre Suffixe DNS Principal dans les propriétés
du nom de la machine. Pour les postes GNU/Linux, c’est la valeur hostname qui devra être
configurée.

Modification manuelle d’un fichier de zone avec les mises à jour dynamiques

Pour effectuer une mise à jour « manuelle » d’une zone dynamique, il est conseillé d’utiliser le client
nsupdate, fourni avec le paquet dsnutils :

# nsupdate
> update delete cli01.demo.eni A
> update add srv01.demo.eni 86400 A 192.168.42.1
> show
> send
> quit

Il est également possible de « geler » la zone afin d’effectuer une modification du fichier de zone. On utilise
pour cela l’outil rndc fourni avec l’installation du service Bind9.

Geler une zone pour un domaine précis :

# rndc freeze eni.demo
Attention pour toute intervention manuelle dans le fichier, il faut également penser à incrémenter le
numéro de série du SOA.

Dégeler une zone pour un domaine précis :

# rndc unfreeze eni.demo
Suite au « dégel », la zone est rechargée automatiquement par le service Bind9.

Version 2020-11 49
8.5.2 MISES A JOUR DYNAMIQUES PAR LE SERVEUR DHCP
Dans un contexte GNU/Linux, il est préférable de cibler les machines autorisées à effectuer les mises à jour
dynamiques. Plutôt que laisser tous les clients DNS le faire, on peut configurer le ou les serveurs DHCP
comme uniques partenaires pour les mises à jour dynamiques.

Pour cela il faut modifier la configuration :

• Des zones principales du serveur DNS, en adaptant la directive allow-update pour cibler
uniquement les adresses IP des serveurs DHCP (il est également possible d’utiliser une clé
cryptographique)
• Du ou des serveurs DHCP pour activer la mise à jour dynamique (voir ci-dessous)

Paramètres DHCP pour les mises à jour dynamiques (fichier /etc/dhcp/dhcpd.conf) :

ddns-updates on; Activation de la mise à jour dynamique DNS
ddns-update-style standard; Mode de mise à jour dynamique « standard »
ddns-domainname "demo.eni"; Suffixe DNS du domaine direct

ignore client-updates; Force la mise à jour par le serveur DHCP

update-static-leases on; Active la mise à jour pour les réservations

Il est également nécessaire de déclarer, dans la configuration DHCP, les zones DNS à mettre à jour et le
serveur associé avec des directives du type :
zone demo.eni { Déclaration de la zone directe
primary 10.5.3.10;} avec le serveur principal sur cette zone

zone 42.168.192.in-addr.arpa { Déclaration de la zone inverse

primary 10.5.3.10;} avec le serveur principal sur cette zone

Version 2020-11 50