Configurer les paramètres réseau sous Linux

La même démarche existe pour Windows : Configurer les paramètres réseau sous Windows.

Préparer l’intervention

Tous les exemples de cette page utilisent la fiche d’adressage ci-dessous. Remplace ces valeurs par celles de ton propre plan d’adressage : dans les blocs de code, ce sont ces valeurs (interface, adresses, nom d’hôte, domaine) qu’il faut adapter.

Paramètre	Valeur d’exemple	Rôle
Interface réseau	`ens192`	Carte sur laquelle on applique la configuration
Nom d’hôte	`srv-web01`	Nom de la machine sur le réseau
Réseau	`192.168.50.0/24`	Réseau logique auquel appartient la machine
Adresse IPv4	`192.168.50.20`	Identifie la machine dans ce réseau (doit être unique)
Masque	`255.255.255.0` (/24)	Délimite la partie « réseau » et la partie « hôte »
Passerelle par défaut	`192.168.50.254`	Routeur à qui envoyer tout ce qui sort du réseau local
DNS primaire / secondaire	`192.168.50.10` / `192.168.50.11`	Serveurs qui traduisent les noms en adresses IP
Suffixe DNS	`sio.lab`	Domaine ajouté automatiquement aux noms courts

Prérequis

Un compte disposant des droits sudo (on évite de travailler directement en root).
Un accès à la machine qui ne dépend pas du réseau : console de la VM (vCenter, Proxmox…) ou accès physique.
La fiche d’adressage validée : adresse libre, hors de l’étendue DHCP, cohérente avec le réseau.

Relever la configuration actuelle

ip -br link                 # nom des interfaces (ici ens192) et état
ip -br addr                 # adresses IP attribuées
ip route                    # passerelle par défaut (ligne « default via »)
cat /etc/resolv.conf        # serveurs DNS utilisés
hostnamectl                 # nom d'hôte et version du système
# Sauvegarde de l'état initial
{ ip addr; ip route; cat /etc/resolv.conf; } > ~/config-avant.txt

Une configuration réseau est un tout cohérent

On parle souvent de « changer l’adresse IP » d’une machine. En réalité, une configuration IPv4 repose sur au moins quatre paramètres qui dépendent les uns des autres : l’adresse, le masque, la passerelle et le ou les serveurs DNS. Modifier l’un d’eux sans vérifier les autres est la cause la plus fréquente des pannes après intervention.

§ Les règles de cohérence à connaître

L’adresse IP et la passerelle doivent appartenir au même réseau, défini par le masque. Une passerelle hors du réseau est injoignable.
L’adresse IP ne doit être ni l’adresse du réseau (192.168.50.0), ni l’adresse de diffusion (192.168.50.255), ni déjà utilisée par une autre machine.
Une adresse fixe doit être hors de la plage distribuée par le serveur DHCP (ou faire l’objet d’une réservation), sinon le conflit apparaîtra plus tard, au hasard d’un bail.
Il n’y a qu’une seule passerelle par défaut. Pour joindre d’autres réseaux par un autre routeur, on ajoute des routes statiques.
Sur un serveur Linux joint à un annuaire (AD, FreeIPA), le DNS doit être celui de l’annuaire : sinon SSSD/Kerberos ne trouvent plus les contrôleurs et les authentifications échouent.

Ce qu’un changement peut casser

Le tableau suivant sert de liste de contrôle : pour chaque paramètre modifié, il indique les effets possibles sur la machine elle-même, mais aussi sur le reste du système d’information.

Je modifie…	Conséquences possibles	Ce que je dois vérifier / mettre à jour
L’adresse IP	Les clients qui utilisaient l’ancienne adresse ne trouvent plus le service. Risque de conflit avec une machine existante.	Enregistrements DNS (A et PTR), réservations DHCP, règles et alias du pare-feu, supervision (Zabbix), inventaire (GLPI), configuration des applications qui écoutent sur une IP précise, clés SSH connues des clients, certificats
Le masque	Trop petit : des machines du même réseau deviennent « distantes », la passerelle peut se retrouver hors réseau. Trop grand : la machine croit joindre directement des hôtes qui sont derrière un routeur, et ne passe plus par la passerelle (ni par le pare-feu).	Cohérence avec le plan d’adressage, présence de la passerelle dans le réseau, adresse de diffusion
La passerelle	Plus aucun accès hors du réseau local. Une passerelle erronée ou malveillante peut détourner le trafic.	Même réseau que l’IP, une seule passerelle par défaut, routes statiques éventuelles
Le ou les DNS	Plus de résolution de noms, même si le réseau « marche » (le ping par IP fonctionne). Un DNS externe fait fuiter les noms internes et casse l’annuaire.	DNS internes en premier, suffixe de recherche, enregistrement dynamique de la machine
Le nom d’hôte	Enregistrement DNS obsolète, compte ordinateur de l’annuaire à renommer, certificats émis pour l’ancien nom.	Fichier `/etc/hosts`, DNS, annuaire, certificats
Le mode (DHCP → fixe)	Conflit futur si l’adresse choisie appartient à l’étendue DHCP.	Exclusion ou réservation dans le serveur DHCP
Le réseau / VLAN	Tout le plan change : IP, masque, passerelle, parfois DNS. Les règles de filtrage qui s’appliquaient ne sont plus les mêmes.	Plan d’adressage du nouveau VLAN, règles de pare-feu entre VLAN

Rappel : notation CIDR et masque

Les outils graphiques demandent souvent le masque en notation décimale, les outils en ligne de commande en longueur de préfixe (notation CIDR). Il faut savoir passer de l’une à l’autre.

CIDR	Masque décimal	Adresses utilisables	Exemple de réseau
/8	`255.0.0.0`	16 777 214	`10.0.0.0/8`
/16	`255.255.0.0`	65 534	`172.16.0.0/16`
/24	`255.255.255.0`	254	`192.168.50.0/24`
/25	`255.255.255.128`	126	`192.168.50.0/25` → .1 à .126
/26	`255.255.255.192`	62	`192.168.50.64/26` → .65 à .126
/27	`255.255.255.224`	30	`192.168.50.32/27` → .33 à .62
/28	`255.255.255.240`	14	`192.168.50.16/28` → .17 à .30
/30	`255.255.255.252`	2	Liaison point à point entre deux routeurs

Adresses privées et adresses publiques

Avant de choisir une adresse, il faut savoir à quelle catégorie elle appartient. Ces deux notions ne s’opposent pas sur la « qualité » de l’adresse, mais sur sa portée : où elle est valable et qui peut la joindre.

La différence entre les deux notions

Critère	Adresse publique	Adresse privée
Portée	Valable et routée sur Internet	Non routée sur Internet : valable uniquement à l’intérieur d’un réseau local ou d’entreprise
Unicité	Unique au niveau mondial	Unique seulement dans le réseau qui l’utilise : des millions de réseaux réutilisent `192.168.1.0/24`
Attribution	Distribuée par l’IANA, puis les registres régionaux (le RIPE NCC pour l’Europe), puis les FAI et hébergeurs	Choisie librement par l’administrateur réseau, sans demande à personne
Coût / rareté	Ressource rare en IPv4, payante (louée par le FAI ou l’hébergeur)	Gratuite et abondante
Accès depuis Internet	Joignable directement si aucun filtrage ne l’empêche	Pas joignable directement : il faut une traduction d’adresse (NAT) ou une redirection de port
Exemple	L’adresse de ta box côté Internet, celle d’un serveur web hébergé	L’adresse de ton PC à la maison ou au lycée

Les plages à connaître (RFC 1918 et plages spéciales)

Plage	Étendue	Usage
`10.0.0.0/8`	10.0.0.0 → 10.255.255.255	Privée (RFC 1918) — grandes infrastructures, beaucoup de sous-réseaux
`172.16.0.0/12`	172.16.0.0 → 172.31.255.255	Privée (RFC 1918) — attention : 172.32.x.x est publique !
`192.168.0.0/16`	192.168.0.0 → 192.168.255.255	Privée (RFC 1918) — réseaux domestiques et petites structures
`169.254.0.0/16`	169.254.0.1 → 169.254.255.254	Adresse « lien local » (APIPA) : la machine se l’attribue seule quand aucun serveur DHCP ne répond. C’est un symptôme de panne, pas une configuration.
`127.0.0.0/8`	127.0.0.1 en pratique	Boucle locale (localhost) : la machine elle-même
`100.64.0.0/10`	100.64.0.0 → 100.127.255.255	Partagée par les opérateurs (CGNAT, RFC 6598) — à ne pas utiliser en interne

Comment une machine en adresse privée accède-t-elle à Internet ?

Grâce à la traduction d’adresses (NAT), réalisée par la box, le routeur ou le pare-feu (pfSense, par exemple). Quand le poste 192.168.50.20 sort vers Internet, le routeur remplace l’adresse source privée par sa propre adresse publique et mémorise la correspondance pour renvoyer la réponse au bon poste. Vu d’Internet, tout le réseau interne se cache derrière une seule adresse publique.

L’intérêt des adresses privées en cybersécurité

✅ Ce que les adresses privées apportent

Pas d’exposition directe : un attaquant sur Internet ne peut pas initier une connexion vers 192.168.50.20, car aucun routeur d’Internet ne sait acheminer cette adresse. Pour qu’un service interne soit joignable, il faut une décision volontaire (redirection de port, publication via un proxy inverse).
Masquage de la topologie : le plan d’adressage interne (nombre de machines, découpage en sous-réseaux) n’est pas visible de l’extérieur.
Cloisonnement facilité : la liberté de découper 10.0.0.0/8 en nombreux sous-réseaux (un par VLAN : serveurs, postes, administration, invités…) permet d’appliquer des règles de filtrage précises entre zones.
Économie d’adresses publiques : quelques adresses publiques suffisent pour tout un établissement, ce qui réduit aussi le nombre de points d’entrée à surveiller.

⚠️ Ce que les adresses privées n’apportent PAS

Le NAT n’est pas un pare-feu. Il ne filtre rien : il traduit. La protection réelle vient des règles de filtrage du pare-feu, qui doivent exister aussi entre les réseaux internes.
Aucune protection contre une menace interne : un poste compromis dans le réseau voit toutes les adresses privées de son sous-réseau. D’où l’intérêt de la segmentation en VLAN.
Les connexions sortantes restent possibles : un logiciel malveillant qui « appelle » son serveur de commande traverse le NAT sans difficulté. Il faut filtrer aussi le trafic sortant.
UPnP peut ouvrir des ports tout seul sur une box ou un routeur : à désactiver sur un équipement professionnel.
IPv6 : une machine peut avoir une adresse IPv6 globale (publique) en plus de son adresse IPv4 privée. Le filtrage doit couvrir les deux protocoles.

Mode opératoire

Étape préalable : qui gère le réseau sur cette machine ?

Contrairement à Windows, Linux n’a pas un outil unique. Selon la distribution et le type d’installation, la configuration réseau est gérée par l’un des outils ci-dessous. Modifier le fichier d’un outil qui ne gère pas l’interface n’a aucun effet — ou pire, crée un conflit entre deux gestionnaires.

Distribution / installation	Gestionnaire habituel	Où se trouve la configuration
Debian (serveur, sans bureau)	ifupdown	`/etc/network/interfaces`
Debian (avec environnement de bureau)	NetworkManager	Outil `nmcli` / `nmtui`
Ubuntu Server	Netplan (qui pilote systemd-networkd)	`/etc/netplan/*.yaml`
Ubuntu Desktop	Netplan → NetworkManager	Outil `nmcli` / `nmtui`
RHEL / Rocky / AlmaLinux 9 et plus, Fedora	NetworkManager	`nmcli` — fichiers dans `/etc/NetworkManager/system-connections/`
RHEL / CentOS 7 et 8 (anciens)	NetworkManager	Anciens fichiers `/etc/sysconfig/network-scripts/ifcfg-*`

# Trois vérifications rapides
nmcli device status           # NetworkManager gère-t-il l'interface ?
ls /etc/netplan/ 2>/dev/null  # Netplan présent ?
cat /etc/network/interfaces   # interface déclarée pour ifupdown ?

Configuration temporaire ou persistante ?

La commande ip modifie la configuration en mémoire : utile pour un test rapide, elle est perdue au prochain redémarrage ou rechargement du réseau. Une configuration de production doit toujours être écrite dans les fichiers du gestionnaire.

# TEMPORAIRE — disparaît au redémarrage
sudo ip addr add 192.168.50.20/24 dev ens192
sudo ip route add default via 192.168.50.254

Famille Debian — ifupdown (Debian serveur)

Étape 1 — Sauvegarder le fichier existant, puis l’ouvrir.

sudo cp /etc/network/interfaces /etc/network/interfaces.bak
sudo nano /etc/network/interfaces

Étape 2 — Remplacer la déclaration iface … inet dhcp de l’interface par une configuration statique. Ne pas toucher au bloc de l’interface lo.

# Interface de bouclage — ne pas modifier
auto lo
iface lo inet loopback

# Interface principale — configuration statique
auto ens192
iface ens192 inet static
    address 192.168.50.20/24
    gateway 192.168.50.254
    # Les deux lignes suivantes ne sont prises en compte que si le paquet resolvconf est installé
    dns-nameservers 192.168.50.10 192.168.50.11
    dns-search sio.lab

Étape 3 — Configurer les DNS. Sans le paquet resolvconf, les lignes dns-* sont ignorées : on renseigne alors directement /etc/resolv.conf.

# /etc/resolv.conf
search sio.lab
nameserver 192.168.50.10
nameserver 192.168.50.11

Étape 4 — Appliquer la configuration depuis la console. La méthode la plus propre consiste à désactiver l’interface avec l’ancienne configuration, puis à la réactiver avec la nouvelle.

# Méthode recommandée : ifdown AVANT la modification du fichier, ifup APRÈS
sudo ifdown ens192      # puis modification du fichier (étapes 2 et 3)
sudo ifup ens192

# Si le fichier a déjà été modifié : on retire l'ancienne adresse puis on relance
sudo ip addr flush dev ens192 && sudo systemctl restart networking

Étape 5 — Mettre à jour le nom d’hôte et le fichier hosts. Sous Debian, le nom de la machine est associé à l’adresse 127.0.1.1 dans /etc/hosts. Si le nom ou le domaine change, ce fichier doit suivre — de nombreux services (base de données, messagerie, Kerberos) s’appuient sur cette résolution locale.

sudo hostnamectl set-hostname srv-web01
# /etc/hosts
127.0.0.1       localhost
127.0.1.1       srv-web01.sio.lab srv-web01

Famille Debian — Netplan (Ubuntu Server)

Netplan décrit la configuration en YAML. L’indentation est significative : on utilise uniquement des espaces (jamais de tabulation), toujours le même nombre par niveau.

ls /etc/netplan/          # repérer le fichier existant
sudo cp /etc/netplan/50-cloud-init.yaml ~/50-cloud-init.yaml.bak
sudo nano /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  ethernets:
    ens192:
      dhcp4: false
      addresses:
        - 192.168.50.20/24
      routes:
        - to: default
          via: 192.168.50.254
      nameservers:
        addresses: [192.168.50.10, 192.168.50.11]
        search: [sio.lab]

sudo chmod 600 /etc/netplan/*.yaml   # lisible par root uniquement
sudo netplan try     # applique, puis annule seul après 120 s sans confirmation
sudo netplan apply   # application définitive une fois le test validé
resolvectl status    # DNS réellement utilisés

Famille Red Hat — NetworkManager avec nmcli

Sur RHEL, Rocky Linux, AlmaLinux (9 et suivantes) et Fedora, NetworkManager est l’outil de référence. On ne modifie pas les fichiers à la main : on passe par nmcli, qui valide la syntaxe et enregistre la configuration. NetworkManager raisonne en connexions (profils) appliquées à des périphériques (interfaces) : le nom de la connexion n’est pas forcément celui de l’interface.

Étape 1 — Identifier la connexion active.

nmcli device status                 # interface ens192 → connexion associée
nmcli connection show               # liste des connexions (colonne NAME)
nmcli connection show "ens192" | grep ipv4   # paramètres IPv4 actuels

Étape 2 — Modifier tous les paramètres en une seule commande. Le regroupement est important : ipv4.method manual exige qu’une adresse soit fournie dans la même commande.

sudo nmcli connection modify "ens192" \
    ipv4.addresses 192.168.50.20/24 \
    ipv4.gateway 192.168.50.254 \
    ipv4.dns "192.168.50.10 192.168.50.11" \
    ipv4.dns-search sio.lab \
    ipv4.method manual \
    connection.autoconnect yes

Étape 3 — Appliquer en réactivant la connexion. La modification est enregistrée mais n’est effective qu’à cette étape.

sudo nmcli connection up "ens192"

# Depuis une session SSH (à défaut de console), dans tmux pour ne pas interrompre la commande :
tmux new -s reseau 'sudo nmcli connection up "ens192"'

Étape 4 — Nom d’hôte et contrôle du fichier généré.

sudo hostnamectl set-hostname srv-web01.sio.lab
sudo cat /etc/NetworkManager/system-connections/ens192.nmconnection

Famille Red Hat — les fichiers de configuration

nmcli ne fait qu’écrire un fichier, comme on le ferait à la main sous Debian dans /etc/network/interfaces. Selon la version du système, ce fichier n’a pas le même format ni le même emplacement :

Version	Format	Emplacement
RHEL / CentOS 7 et 8	ifcfg (format historique)	`/etc/sysconfig/network-scripts/ifcfg-ens192`
RHEL / Rocky / AlmaLinux 9	keyfile pour toute nouvelle connexion ; les anciens fichiers ifcfg restent lus	`/etc/NetworkManager/system-connections/ens192.nmconnection`
RHEL 10 et suivantes	keyfile uniquement : le format ifcfg n’est plus pris en charge	`/etc/NetworkManager/system-connections/`

Savoir quel fichier porte une connexion — la commande indique directement le format utilisé :

nmcli -f NAME,DEVICE,FILENAME connection show
# ens192  ens192  /etc/NetworkManager/system-connections/ens192.nmconnection   → keyfile
# ens192  ens192  /etc/sysconfig/network-scripts/ifcfg-ens192                  → ifcfg

Le format actuel : le keyfile. Il est organisé en sections entre crochets, comme un fichier .ini. Les commentaires doivent occuper une ligne entière commençant par # : un commentaire placé en fin de ligne serait lu comme faisant partie de la valeur. Voici le fichier produit par la commande nmcli de la section « Famille Red Hat — NetworkManager avec nmcli » :

# /etc/NetworkManager/system-connections/ens192.nmconnection
[connection]
# Nom de la connexion (colonne NAME de nmcli)
id=ens192
# Identifiant unique, généré automatiquement
uuid=2f1c5a8e-…
type=ethernet
interface-name=ens192
# Activation au démarrage
autoconnect=true

[ethernet]

[ipv4]
# manual = adresse fixe ; auto = DHCP
method=manual
# Adresse ET masque, en notation CIDR
address1=192.168.50.20/24
gateway=192.168.50.254
# Listes : valeurs séparées (et terminées) par un point-virgule
dns=192.168.50.10;192.168.50.11;
dns-search=sio.lab;

[ipv6]
method=auto

§ Modifier un keyfile à la main

C’est possible, mais NetworkManager ne relit pas le fichier tout seul. Après modification :

sudo chmod 600 /etc/NetworkManager/system-connections/ens192.nmconnection
sudo chown root:root /etc/NetworkManager/system-connections/*.nmconnection
sudo nmcli connection reload                 # relire les fichiers
sudo nmcli connection up "ens192"           # appliquer

Un fichier qui n’appartient pas à root ou qui est lisible par d’autres utilisateurs est ignoré par NetworkManager. Dans la pratique, nmcli reste préférable : il vérifie la syntaxe avant d’écrire.

Le format historique : ifcfg. Il est encore très présent sur les serveurs RHEL / CentOS 7 et 8 en production, et dans de nombreux tutoriels. Il faut savoir le lire :

# /etc/sysconfig/network-scripts/ifcfg-ens192
TYPE=Ethernet
NAME=ens192
DEVICE=ens192
ONBOOT=yes
# none (ou static) = adresse fixe ; dhcp = DHCP
BOOTPROTO=none
IPADDR=192.168.50.20
# Masque en longueur de préfixe (ou NETMASK=255.255.255.0)
PREFIX=24
GATEWAY=192.168.50.254
DNS1=192.168.50.10
DNS2=192.168.50.11
DOMAIN=sio.lab

# Appliquer une modification du fichier — RHEL 8 (NetworkManager)
sudo nmcli connection reload && sudo nmcli connection up "ens192"
# RHEL / CentOS 7 avec les anciens scripts réseau
sudo systemctl restart network

Correspondance entre les deux formats et nmcli :

Paramètre	ifcfg (ancien)	keyfile (actuel) — section [ipv4]	Propriété nmcli
Mode fixe / DHCP	`BOOTPROTO=none` / `dhcp`	`method=manual` / `auto`	`ipv4.method`
Adresse et masque	`IPADDR=` + `PREFIX=` (ou `NETMASK=`)	`address1=192.168.50.20/24`	`ipv4.addresses`
Passerelle	`GATEWAY=`	`gateway=`	`ipv4.gateway`
DNS	`DNS1=`, `DNS2=`	`dns=…;…;`	`ipv4.dns`
Suffixe DNS	`DOMAIN=`	`dns-search=`	`ipv4.dns-search`
Activation au démarrage	`ONBOOT=yes`	`autoconnect=true` (section [connection])	`connection.autoconnect`

Convertir les anciens fichiers avant une migration vers RHEL 10. Sur un serveur RHEL 9 qui contient encore des fichiers ifcfg, NetworkManager sait les convertir en keyfiles :

# Sauvegarde d'abord
sudo cp -a /etc/sysconfig/network-scripts ~/network-scripts.bak
sudo nmcli connection migrate "ens192"     # une connexion ; sans argument : toutes
nmcli -f NAME,FILENAME connection show     # vérifier le nouvel emplacement

Pare-feu firewalld : vérifier la zone

Sous Red Hat, firewalld applique des règles par zone, et chaque connexion est rattachée à une zone. Changer de réseau peut nécessiter de changer de zone : un serveur déplacé dans un réseau d’administration n’a pas les mêmes ouvertures qu’un serveur exposé.

sudo firewall-cmd --get-active-zones             # zone de chaque interface
sudo firewall-cmd --zone=public --list-all       # services et ports ouverts dans la zone
sudo nmcli connection modify "ens192" connection.zone internal   # rattacher la connexion à une zone
sudo nmcli connection up "ens192"

Passer de DHCP à adresse fixe, et inversement

Changer de mode d’adressage ne se limite pas à cocher une case sur la machine. Une adresse fixe est gérée sur la machine ; une adresse DHCP est gérée sur le serveur DHCP. Basculer de l’un à l’autre revient donc à déplacer la responsabilité de la configuration, et il faut intervenir des deux côtés — ainsi que dans le DNS.

Adresse fixe, DHCP ou réservation : que choisir ?

Critère	Adresse fixe (statique)	DHCP (adresse dynamique)	Réservation DHCP
Où est la configuration ?	Sur la machine	Sur le serveur DHCP	Sur le serveur DHCP, liée à l’adresse MAC
Adresse toujours identique ?	Oui	Pas garanti	Oui
Changer de DNS ou de passerelle	Machine par machine	Une seule modification sur le serveur	Une seule modification sur le serveur
Fonctionne si le DHCP est en panne ?	Oui	Non (au renouvellement du bail)	Non
Risque d’erreur	Saisie manuelle, doublons, oublis lors des évolutions	Faible	Faible (attention au changement de carte réseau : nouvelle MAC)
Usage typique	Serveurs d’infrastructure : contrôleurs de domaine, DNS, le serveur DHCP lui-même, routeurs, pare-feu, commutateurs	Postes de travail, portables, invités	Imprimantes réseau, bornes Wi-Fi, équipements à joindre par une adresse stable

De DHCP vers adresse fixe

Relever ce que la machine reçoit actuellement du DHCP : adresse MAC, masque, passerelle, DNS, suffixe. Ce sont les bonnes valeurs du réseau — elles serviront pour la configuration fixe.
Choisir une adresse hors de l’étendue DHCP, conforme au plan d’adressage, et vérifier qu’elle est libre. Si aucune adresse hors étendue n’est disponible, ajouter une exclusion dans le serveur DHCP.
Côté serveur DHCP : supprimer le bail en cours de la machine, et la réservation éventuelle. Sinon le serveur considère l’ancienne adresse comme encore attribuée jusqu’à l’expiration du bail.
Appliquer la configuration fixe sur la machine (voir « Mode opératoire »).
Côté DNS : créer ou corriger les enregistrements A et PTR. Un enregistrement créé dynamiquement par le DHCP peut être supprimé automatiquement à l’expiration du bail : la machine « disparaît » alors du DNS quelques jours après l’intervention.
Mettre à jour la documentation : plan d’adressage, inventaire, supervision.

ip -br link show ens192                       # adresse MAC
nmcli -f DHCP4 device show ens192             # options reçues (NetworkManager)
networkctl status ens192                      # même chose avec Netplan / networkd
cat /var/lib/dhcp/dhclient*.leases             # bail ifupdown (dhclient), si présent

D’une adresse fixe vers DHCP

Côté serveur DHCP : vérifier que l’étendue du réseau a encore des adresses libres et que ses options sont correctes (003 routeur, 006 serveurs DNS, 015 nom de domaine). La machine recevra exactement ces valeurs.
Si la machine doit garder une adresse stable : créer une réservation à partir de son adresse MAC. Sinon, supprimer l’éventuelle exclusion devenue inutile pour récupérer l’adresse dans l’étendue.
Côté DNS : supprimer l’enregistrement statique de l’ancienne adresse. Sinon le nom continue de pointer vers une adresse qui sera un jour attribuée à une autre machine — un client pourrait alors envoyer des données (identifiants compris) au mauvais destinataire.
Basculer la machine en DHCP, en effaçant tous les paramètres saisis à la main (voir ci-dessous).
Contrôler le bail obtenu : adresse dans l’étendue attendue, passerelle et DNS reçus du serveur, aucune adresse 169.254.x.x.
Mettre à jour tout ce qui référençait l’ancienne adresse : règles de pare-feu, supervision, listes blanches, documentation.

Gestionnaire	Passage en DHCP	Appliquer / renouveler le bail
ifupdown (Debian)	Remplacer le bloc statique par `iface ens192 inet dhcp` et supprimer les lignes `address`, `gateway`, `dns-*`	`ifdown ens192` puis `ifup ens192` (depuis la console)
Netplan (Ubuntu)	Remplacer le contenu du bloc de l’interface par `dhcp4: true`	`netplan try` puis `netplan apply` ; renouveler : `networkctl renew ens192`
NetworkManager (Red Hat, postes Debian/Ubuntu)	`nmcli con mod "ens192" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns "" ipv4.dns-search ""`	`nmcli con up "ens192"`

Contrôler le bail reçu :

ip -br a show ens192        # l'adresse porte la mention « dynamic »
ip route                      # une seule ligne « default via … »
nmcli -f DHCP4 device show ens192   # ou : networkctl status ens192

Cybersécurité : DHCP et adresse fixe face aux attaques

⚠️ Le serveur DHCP pirate (rogue DHCP)

Une machine en DHCP accepte la première offre reçue. Un attaquant — ou simplement une box branchée par erreur sur le réseau — qui répond plus vite que le vrai serveur peut distribuer sa propre passerelle et ses propres DNS : tout le trafic des victimes passe alors par lui (attaque de l’homme du milieu) ou vers de faux sites.

DHCP snooping sur les commutateurs : seuls les ports déclarés « de confiance » (ceux qui mènent au vrai serveur DHCP) ont le droit d’envoyer des offres DHCP.
Dynamic ARP Inspection (DAI), qui s’appuie sur la table du DHCP snooping, bloque l’usurpation d’adresses IP par empoisonnement ARP.
Port security limite le nombre d’adresses MAC par port et empêche l’épuisement de l’étendue (DHCP starvation), une attaque qui consomme toutes les adresses pour en priver les postes légitimes.
Authentification 802.1X des équipements avant tout accès au réseau.

Cybersécurité : les bons réflexes

Un changement de configuration réseau est une opération sensible : mal faite, elle rend un service indisponible (atteinte à la disponibilité) ; mal choisie, elle peut exposer une machine ou détourner son trafic (atteinte à la confidentialité et à l’intégrité).

Les réflexes avant, pendant et après l’intervention

⚠️ Avant d’intervenir

Modifier l’adresse d’une machine à laquelle tu es connecté en SSH coupe ta session. Sur une VM, travaille depuis la console de l’hyperviseur (console web de vCenter, Proxmox…) ; à défaut, utilise une méthode avec retour arrière automatique (netplan try) ou enchaîne les commandes sur une seule ligne dans une session tmux.
Vérifie que l’adresse est libre avant de l’attribuer (ping, consultation du DHCP et du DNS, plan d’adressage). Un doublon d’adresse provoque une coupure aléatoire des deux machines — c’est aussi la technique utilisée par un attaquant pour usurper une machine.
Travaille avec un compte d’administration dédié, pas avec un compte utilisateur aux droits élevés en permanence (principe du moindre privilège).
Relève et sauvegarde la configuration actuelle : en cas de problème, tu dois pouvoir revenir à l’état connu.

⚠️ Pendant et après l’intervention

Dans le LAN, n’utilise que des serveurs DNS du LAN — en DNS primaire comme en DNS secondaire, jamais 8.8.8.8 ou 1.1.1.1 sur un poste ou un serveur. Seul le serveur DNS interne interroge l’extérieur. Cette règle est essentielle : elle est détaillée plus bas, dans « Le DNS : dans le LAN, uniquement des serveurs du LAN ».
Vérifie la passerelle : c’est par elle que passe tout le trafic sortant. Une mauvaise passerelle (ou une passerelle usurpée) permet une interception de type « homme du milieu ».
Ne choisis pas un masque plus large que nécessaire : un masque trop grand fait communiquer la machine en direct avec des hôtes qu’elle devrait joindre à travers le pare-feu, et contourne donc le filtrage.
Contrôle les services qui écoutent après le changement : un service configuré pour écouter sur « toutes les interfaces » sera exposé sur la nouvelle adresse et sur le nouveau réseau.
Mets à jour les règles qui dépendent de l’adresse : pare-feu, listes blanches (Fail2ban, accès SSH ou RDP réservés à certaines IP), supervision. Une règle oubliée, c’est soit une panne, soit une ouverture non maîtrisée.

Le DNS : dans le LAN, uniquement des serveurs du LAN

Le DNS est le premier service sollicité pour chaque connexion : celui qui répond aux requêtes DNS décide vers quelle adresse partent les postes. C’est pourquoi le choix des serveurs DNS est une décision de sécurité, pas seulement de fonctionnement. La règle est simple : dans le LAN, les machines n’utilisent que des adresses appartenant au LAN, y compris pour le DNS. Les accès Internet passent par une chaîne à deux niveaux :

Poste / serveur du LAN	→ DNS interne	→ Redirecteurs vérifiés	→ Internet
`192.168.50.20` · DNS 1 et 2 = DNS internes	`192.168.50.10` / `.11` · répond seul pour `sio.lab`	opérateur, Quad9, DNS4EU… · pour les noms Internet	serveurs faisant autorité

⚠️ Le piège : un DNS externe « en secours » en DNS secondaire

C’est l’erreur la plus fréquente : DNS primaire interne, et 8.8.8.8 en secondaire « au cas où ».

Le résolveur interroge les serveurs de /etc/resolv.conf dans l’ordre, mais passe au suivant au moindre délai de réponse ; systemd-resolved peut même basculer sur l’autre serveur et y rester. Avec un DNS externe en secondaire, la machine se met à interroger Google ou Cloudflare, qui ne connaissent pas sio.lab : échecs aléatoires de résolution des noms internes, authentification SSSD/Kerberos qui ne trouve plus l’annuaire, montages réseau absents… La panne est intermittente, donc très difficile à diagnostiquer.

Et du point de vue de la sécurité, le poste contourne le filtrage et la journalisation du DNS interne, et révèle à un tiers les noms internes qu’il cherche.

Choisir les redirecteurs. Un DNS externe se choisit sur des critères précis :

Fiabilité et disponibilité : un opérateur reconnu, des adresses anycast, toujours deux adresses déclarées.
Filtrage proposé : blocage des domaines malveillants (hameçonnage, logiciels malveillants), voire des contenus inadaptés.
Confidentialité : politique de conservation des journaux — le résolveur voit tous les noms consultés par l’organisation.
Juridiction : un service relevant du droit européen n’offre pas les mêmes garanties qu’un service relevant du droit américain (RGPD, souveraineté).
Validation DNSSEC : le résolveur vérifie l’authenticité des réponses signées.

Résolveur	Adresses IPv4	Filtrage	À savoir
DNS de l’opérateur Internet	Fournies par le FAI	Variable, souvent aucun	Proches du réseau, donc rapides ; appliquent les blocages imposés par la justice
Cloudflare	`1.1.1.1` / `1.0.0.1`	Aucun	Très rapide ; société américaine
Cloudflare for Families	`1.1.1.2` / `1.0.0.2` `1.1.1.3` / `1.0.0.3`	Malveillants Malveillants + contenus adultes	Mêmes serveurs que Cloudflare, avec filtrage
Google Public DNS	`8.8.8.8` / `8.8.4.4`	Aucun	Très répandu ; société américaine
Quad9	`9.9.9.9` / `149.112.112.112`	Malveillants	Fondation à but non lucratif de droit suisse
DNS4EU « Protective »	`86.54.11.1` / `86.54.11.201`	Malveillants	Résolveur soutenu par l’Union européenne ; d’autres profils existent (protection de l’enfance, blocage publicitaire, non filtré)

Déclarer les redirecteurs sur le serveur DNS interne.

Sur un serveur BIND — fichier /etc/bind/named.conf.options (Debian) ou /etc/named.conf (Red Hat) :

options {
    // Redirecteurs : les seuls serveurs externes interrogés
    forwarders { 9.9.9.9; 149.112.112.112; };
    forward only;
    // Récursion réservée aux réseaux internes (jamais « any »)
    allow-recursion { 127.0.0.1; 192.168.50.0/24; };
    dnssec-validation auto;
};

Sur un serveur Unbound — fichier /etc/unbound/unbound.conf :

server:
    access-control: 192.168.50.0/24 allow
forward-zone:
    name: "."
    forward-addr: 9.9.9.9
    forward-addr: 149.112.112.112

Sur pfSense : System › General Setup › renseigner les serveurs DNS externes, puis Services › DNS Resolver › cocher Enable Forwarding Mode. Le résolveur de pfSense transmet alors les requêtes aux serveurs déclarés au lieu de résoudre lui-même depuis les serveurs racine.

Imposer la règle par le pare-feu. Sans filtrage, rien n’empêche un poste mal configuré — ou un logiciel malveillant — d’interroger directement un DNS externe. Les règles suivantes, sur le pare-feu de sortie, rendent la règle obligatoire :

Ordre	Source	Destination	Ports	Action
1	LAN	DNS internes (`192.168.50.10`, `.11`)	53 TCP/UDP	Autoriser
2	DNS internes	Redirecteurs déclarés (ex. Quad9)	53 TCP/UDP, 853 TCP	Autoriser
3	LAN	Toute destination	53 TCP/UDP, 853 TCP (DNS over TLS)	Bloquer (et journaliser)

Le DNS over HTTPS (DoH) passe par le port 443, comme le web : il ne peut pas être bloqué par port. On le neutralise par la configuration des navigateurs et des systèmes (stratégies de groupe, politiques d’entreprise) et par le blocage des résolveurs DoH connus sur le proxy ou le pare-feu.

Vérifier que la règle est respectée :

# La machine ne doit connaître que des DNS du LAN
resolvectl dns            # ou : cat /etc/resolv.conf
# Le pare-feu doit BLOQUER une requête directe vers un DNS externe (échec attendu)
dig @8.8.8.8 www.example.com +time=2 +tries=1
# … alors que la résolution via le DNS interne fonctionne
dig www.example.com

Vérifier et dépanner

On teste de l’intérieur vers l’extérieur, dans cet ordre : chaque test ne vaut que si le précédent a réussi. Cela permet de localiser immédiatement la couche en défaut.

Ordre	Test	Commande	Si ça échoue…
1	La configuration est-elle appliquée ?	`ip -br a` et `ip route`	Erreur de saisie, mauvaise interface, configuration non rechargée
2	La pile IP et ma propre adresse répondent ?	`ping -c 3 127.0.0.1` puis `ping -c 3 192.168.50.20`	Carte désactivée, pilote, adresse non attribuée
3	Je joins ma passerelle ?	`ping -c 3 192.168.50.254`	IP ou masque faux, mauvais VLAN / groupe de ports, câble
4	Je sors du réseau local ?	`ping -c 3 1.1.1.1` ou `tracepath -n 1.1.1.1`	Passerelle absente ou fausse, filtrage, routage
5	Les noms sont-ils résolus ?	`getent hosts srv-web.sio.lab` / `dig` / `resolvectl query`	DNS faux ou injoignable, suffixe manquant
6	Le service attendu est-il accessible ?	`nc -zv srv-web.sio.lab 443` ou `curl -I https://…`	Pare-feu, service arrêté, règle non mise à jour

Symptômes fréquents

Symptôme observé	Cause la plus probable
Adresse en `169.254.x.x`	Aucun serveur DHCP n’a répondu (câble, VLAN, service DHCP) — ou retour en DHCP mal fait
« Conflit d’adresse IP » / connexion qui coupe par intermittence	Adresse déjà utilisée par une autre machine
Les machines du réseau local répondent, rien au-delà	Passerelle absente, fausse ou hors du réseau
`ping 1.1.1.1` fonctionne, mais pas les noms	DNS absent, faux ou injoignable
Les sites Internet fonctionnent, pas les noms internes	DNS public configuré à la place du DNS interne, ou suffixe DNS manquant
Certaines machines du « même réseau » sont injoignables	Masque incohérent entre les machines

ip -br a                     # synthèse des adresses
ip route                     # table de routage — une seule ligne « default »
ip neigh                     # voisins IP ↔ MAC (détection de doublons)
sudo arping -D -I ens192 -c 3 192.168.50.20   # adresse libre ? (aucune réponse = libre)
sudo ss -tulpn               # services à l'écoute
sudo journalctl -u NetworkManager --since "10 min ago"

À toi de jouer

✍️ Exercice — Même besoin, deux distributions

Deux serveurs doivent être placés dans le réseau 172.20.8.0/22 : srv-deb (Debian 13, sans bureau) prend l’adresse 172.20.10.15, srv-alma (AlmaLinux 9) l’adresse 172.20.10.16. La passerelle est 172.20.11.254, les DNS 172.20.8.10 et 172.20.8.11, le domaine sio.lab.

Calcule le masque décimal, la plage utilisable et l’adresse de diffusion. Les adresses proposées sont-elles valides ? La passerelle est-elle dans le réseau ?
Indique pour chaque serveur la commande qui permet d’identifier le gestionnaire réseau, et le résultat attendu.
Écris la configuration complète de srv-deb (fichier et commandes) et de srv-alma (commandes nmcli).
Ces adresses sont-elles privées ou publiques ? Que se passerait-il si un collègue saisissait 172.40.10.16 par erreur ?
Liste les vérifications de sécurité à effectuer après l’intervention.
srv-alma était jusqu’ici en DHCP et a reçu l’adresse 172.20.10.16. Pourquoi est-il risqué de figer cette adresse telle quelle ? Propose deux solutions correctes.

© 2026 Bruno Jousseaume. Ce cours est publié sous licence CC BY-NC-SA 4.0 : vous pouvez le partager et l’adapter en citant l’auteur et un lien vers cette page, sans usage commercial, et en partageant vos adaptations sous la même licence.