Les fondamentaux du réseau Linux

Cette page ouvre le module Réseau du parcours Linux. Elle vous donne le modèle mental commun à toutes les leçons qui suivent : une interface porte une adresse IP, une table de routage décide par où sortent les paquets, un résolveur DNS traduit les noms en adresses. Vous repartez d'ici en sachant lire l'état réseau d'un serveur, choisir l'outil de configuration correspondant à votre distribution, et savoir dans quelle leçon aller chercher la manipulation précise. Les commandes de configuration détaillées vivent dans les leçons dédiées, pas ici.

Ce que vous allez apprendre

Lire l'état réseau d'un serveur avec ip et repérer l'interface qui porte le trafic.
Distinguer les quatre briques indispensables : interface, adresse, route par défaut, DNS.
Choisir entre adressage statique et DHCP selon le rôle de la machine.
Identifier l'outil de configuration réellement en place : systemd-networkd, Netplan ou NetworkManager.
Appliquer un changement réseau avec la bonne commande selon la distribution, sans couper votre session SSH.
Situer chaque leçon du module et ce qu'elle couvre.

Les leçons du module, dans l'ordre

Le module suit une progression volontaire : d'abord observer avec ip, ensuite configurer de façon persistante avec l'outil de votre distribution, puis diagnostiquer quand cela ne répond plus, transférer des fichiers entre machines, et enfin faire tourner deux services réseau du quotidien : l'heure et la répartition de charge. Suivez cet ordre si vous débutez : chaque leçon suppose acquise la précédente. Si vous cherchez une manipulation précise, allez directement à la leçon concernée, regroupées ci-dessous par usage.

Observer, puis configurer. La leçon ip apprend à lire et modifier interfaces, adresses, routes et voisinage en ligne de commande, sans rien rendre persistant. La persistance dépend de la distribution : Netplan en YAML sur Ubuntu Server, NetworkManager avec nmcli sur RHEL et ses dérivés. La leçon bond et bridge ajoute une interface redondante et un pont pour vos VM, avec une bascule prouvée.

Diagnostiquer. Diagnostiquer un problème réseau remonte la chaîne interface, adresse, route, DNS et service, en partant du symptôme observé.

Transférer des fichiers. Trois outils, trois usages, tous au-dessus de SSH : SCP pour une copie ponctuelle, SFTP pour une session interactive, rsync pour le transfert différentiel des sauvegardes et des gros volumes.

Faire tourner deux services réseau. chrony garde l'heure juste sur chaque serveur, en NTP comme en NTS chiffré, et HAProxy place un point d'entrée unique devant plusieurs serveurs, avec reprise en cas de panne.

Les quatre briques à identifier sur un serveur

Avant de modifier quoi que ce soit, il faut savoir ce qui est déjà en place. Toute connectivité Linux repose sur quatre éléments, et un incident réseau vient presque toujours de l'un d'eux. Une interface (la carte réseau, physique ou virtuelle) porte une ou plusieurs adresses IP avec leur masque de sous-réseau. La table de routage contient au minimum une route par défaut vers la passerelle, sans laquelle rien ne sort du réseau local. Le résolveur DNS traduit les noms en adresses. Retenez cet ordre : c'est celui du diagnostic.

Les noms d'interface

Chaque carte réseau porte un nom, et ce nom dépend de la convention en vigueur sur la machine. Les anciens eth0, eth1 suivaient l'ordre de détection matérielle, ce qui rendait le nom instable au redémarrage. Les noms prédictibles de systemd (enp0s3, ens33) dérivent de la position sur le bus PCI et ne bougent plus. Les interfaces sans fil apparaissent en wlan0 ou wlp3s0. Ne codez jamais eth0 en dur dans un script sans vérifier le nom réel de la machine cible.

La commande ip a affiche l'inventaire complet, interfaces et adresses confondues :

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:4f:bf:53 brd ff:ff:ff:ff:ff:ff
    altname enx00155d4fbf53
    inet 172.19.104.109/20 brd 172.19.111.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe4f:bf53/64 scope link
       valid_lft forever preferred_lft forever

Trois informations comptent dans cette sortie. L'état UP signale que le lien est actif ; une interface DOWN explique à elle seule une panne totale. L'adresse inet donne l'IPv4 et son masque (/20 ici, soit 255.255.240.0). Le scope global indique une adresse routable, par opposition au scope host de la boucle locale lo. Toutes les options de la commande sont détaillées dans la leçon ip.

Adresse, route et DNS

Une adresse seule ne suffit pas à joindre Internet. Il faut aussi une route par défaut, que vous vérifiez avec ip r : la ligne default via doit pointer vers la passerelle de votre sous-réseau. Il faut enfin une résolution DNS fonctionnelle, sinon les adresses IP répondent mais aucun nom de domaine ne se résout : le serveur répond au ping sur une IP, et pourtant aucune mise à jour ni aucun appel d'API ne passe.

ip r                      # La route par défaut existe-t-elle ?
ping -c 3 192.168.1.1     # La passerelle répond-elle ?
dig +short debian.org     # Le DNS résout-il un nom ?
ss -tulpn                 # Quels services écoutent, sur quels ports ?

Ces quatre commandes forment votre premier réflexe de diagnostic, dans cet ordre. Si ip r ne montre aucune route default, inutile de chercher plus loin côté DNS. Si ping passe sur l'IP mais que dig ne renvoie rien, le problème est strictement DNS. La méthode complète, avec les cas où le paquet part mais ne revient pas, est traitée dans Diagnostiquer un problème réseau.

Statique ou DHCP : trancher avant de configurer

Une interface reçoit ses paramètres soit automatiquement via DHCP (Dynamic Host Configuration Protocol), soit manuellement en statique. Ce choix n'est pas cosmétique : il conditionne la façon dont votre serveur est joignable, et donc la fiabilité de vos enregistrements DNS, de vos règles de filtrage et de vos accès SSH. Un serveur dont l'adresse change au gré des baux DHCP est un serveur qu'on finit par perdre.

Cas d'usage	Recommandation
Serveur en production (web, DNS, base de données)	IP statique
Poste utilisateur, portable	DHCP
VM de test, environnement jetable	DHCP (statique si le service est exposé)
Machine accessible en SSH depuis l'extérieur	IP fixe

En statique, vérifiez toujours que l'adresse choisie est exclue du pool DHCP ou réservée sur le serveur DHCP. Sans cette précaution, le serveur distribuera un jour la même adresse à une autre machine, et vous récolterez un conflit d'adresse intermittent, l'une des pannes les plus pénibles à diagnostiquer parce qu'elle n'apparaît qu'au renouvellement d'un bail.

Un seul outil de configuration par machine

Il n'existe pas d'outil universel de configuration réseau sous Linux. Trois mécanismes se partagent le terrain, et la règle d'or est qu'un seul doit piloter une interface donnée. Faire cohabiter NetworkManager et systemd-networkd sur la même carte, c'est se garantir une configuration qui « revient toute seule » après un redémarrage.

systemd-networkd est le composant réseau de systemd. Déclaratif, léger, sans dépendance graphique, il lit des fichiers .network et .netdev dans /etc/systemd/network/. C'est le moteur qui applique réellement la configuration sur un Ubuntu Server, même si vous ne l'écrivez jamais directement.

Netplan est la surcouche YAML d'Ubuntu. Vous écrivez un fichier dans /etc/netplan/, et Netplan génère la configuration pour le moteur sous-jacent (networkd sur serveur, NetworkManager sur desktop). Un exemple minimal d'IP statique :

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

La route par défaut se déclare bien dans un bloc routes:. L'ancienne clé gateway4: est dépréciée depuis Netplan 0.103 : elle fonctionne encore mais déclenche un avertissement à chaque netplan apply, et elle finira par disparaître. Si vous recopiez un tutoriel qui l'utilise, migrez-la. Les permissions du fichier, le rollback automatique et les cas bond/VLAN sont couverts dans Configurer le réseau avec Netplan.

NetworkManager est le gestionnaire par défaut de RHEL et de ses dérivés, ainsi que des postes de travail Fedora et Ubuntu Desktop. Il raisonne en connexions (des profils nommés), pas en fichiers plats, et se pilote avec nmcli en ligne de commande ou nmtui en interface texte. C'est aussi l'outil attendu à l'examen RHCSA. La création de profils, l'IP statique et la persistance après reboot sont détaillées dans Configurer le réseau avec NetworkManager.

Outil	Où vous le trouvez	Quand le préférer
systemd-networkd	Ubuntu Server, images cloud minimales	Serveurs, conteneurs, configuration scriptée
Netplan	Ubuntu (surcouche de networkd)	Toute machine Ubuntu récente
NetworkManager	RHEL, Rocky, Fedora, postes de travail	RHEL/RHCSA, Wi-Fi, VPN, profils multiples

Appliquer un changement sans se couper le bras

C'est ici que beaucoup de tutoriels se trompent. La commande systemctl restart networking n'est pas générique : le service networking.service appartient à ifupdown, la pile historique de Debian avec /etc/network/interfaces. Il n'existe pas sur une Ubuntu Server récente (Netplan et systemd-networkd), ni sur RHEL (NetworkManager). La lancer sur ces systèmes renvoie simplement Unit networking.service not found. La bonne commande dépend de l'outil qui pilote l'interface.

Distribution / pile	Appliquer la configuration
Ubuntu (Netplan)	`sudo netplan apply`
Ubuntu / images minimales (systemd-networkd seul)	`sudo systemctl restart systemd-networkd`
RHEL, Rocky, Fedora (NetworkManager)	`sudo nmcli connection reload` puis `sudo nmcli connection up enp1s0`
RHEL, en dernier recours	`sudo systemctl restart NetworkManager`
Debian avec ifupdown (`/etc/network/interfaces`)	`sudo systemctl restart networking`

Sur RHEL, préférez nmcli connection up au redémarrage complet de NetworkManager : recharger un profil ne touche qu'une interface, alors que redémarrer le service réapplique tout, y compris ce que vous n'aviez pas l'intention de changer. Sur Ubuntu, sudo netplan try applique la configuration puis la rembobine automatiquement au bout de 120 secondes si vous ne confirmez pas : c'est le filet de sécurité qui vous sauve quand vous travaillez à distance en SSH sur la seule interface de la machine.

Ce que ce module ne couvre pas

Un module doit annoncer ses limites. Le module réseau s'arrête à la configuration et au diagnostic de la connectivité : il ne traite pas le filtrage pare-feu, alors que ufw, firewalld et nftables sont des compétences attendues au LFCS et au RHCSA.

Le sujet n'est pas absent de la formation pour autant : il a sa place dans le module Sécuriser, qui lui consacre quatre leçons. Comprendre les pare-feu Linux pose le modèle mental, UFW couvre Debian et Ubuntu, firewalld couvre RHEL et ses dérivés, et nftables montre le moteur qui se trouve dessous. Les VLAN et le routage avancé (plusieurs tables, routage par politique) ne sont pas non plus traités dans ce module ; l'agrégation de liens (bonding) et le bridge, eux, ont leur leçon.

À retenir

Une connectivité repose sur quatre briques : interface UP, adresse IP avec masque, route par défaut, résolution DNS. Diagnostiquez-les dans cet ordre.
ip a, ip r, ping, dig et ss -tulpn situent la brique en défaut avant d'ouvrir un fichier de configuration.
Statique pour les serveurs, DHCP pour les postes. Une IP statique doit toujours être exclue du pool DHCP, sinon conflit d'adresse garanti.
Un seul outil pilote une interface : systemd-networkd, Netplan ou NetworkManager. Les faire cohabiter produit des configurations qui reviennent après reboot.
En Netplan, la route par défaut s'écrit dans un bloc routes: ; la clé gateway4: est dépréciée.
systemctl restart networking n'existe que sur Debian avec ifupdown. Sur Ubuntu, c'est netplan apply ; sur RHEL, nmcli connection up.
En SSH, une configuration réseau ratée vous coupe la session : utilisez netplan try ou gardez une console de secours.
Le module ne traite pas le pare-feu : ufw, firewalld et nftables se travaillent dans le module Sécuriser de la formation.