Configurer le réseau avec Netplan

Netplan décrit la configuration réseau d'une machine Ubuntu dans un fichier YAML posé sous /etc/netplan/, puis la traduit pour le service qui pilote réellement les interfaces : systemd-networkd sur un serveur, NetworkManager sur un poste de travail. Ce guide vous montre comment poser une adresse IP fixe, un VLAN, un bridge, un bond ou une route statique, comment les appliquer sans perdre votre session SSH grâce à netplan try, et comment vérifier chaque étape. Il s'adresse aux administrateurs à l'aise avec la ligne de commande Linux.

Portée : Ubuntu, pas « le réseau Linux »

Netplan est un outil spécifique à Ubuntu et à ses dérivées (Ubuntu Server, Kubuntu, distributions bâties dessus). Sur Debian, la configuration passe classiquement par /etc/network/interfaces ou NetworkManager ; sur RHEL, Rocky ou Fedora, elle passe par NetworkManager et nmcli. Ce guide relève donc du socle Ubuntu, pas du tronc commun Linux, et il est hors périmètre RHCSA. Pour la voie NetworkManager, voyez Configurer le réseau avec NetworkManager.

Ce que vous allez apprendre

• Identifier le backend actif (networkd ou NetworkManager) avant d'écrire la moindre ligne de configuration.
• Écrire un fichier Netplan valide : adresse statique, DHCP, routes, serveurs DNS.
• Appliquer un changement sans vous couper l'accès distant, avec netplan try et son retour arrière automatique.
• Vérifier chaque action avec ip, resolvectl et netplan status.
• Décliner la configuration sur les cas courants : VLAN, bridge, bonding LACP, Wi-Fi.
• Diagnostiquer les échecs classiques : YAML invalide, fichier écrasé, permissions trop ouvertes.

Premier exemple : une adresse IP fixe

Le cas le plus fréquent sur un serveur : remplacer l'adresse DHCP héritée de l'installation par une adresse statique. Commencez par relever le nom réel de votre interface, car les noms modernes d'Ubuntu (enp3s0, ens18) ne ressemblent plus au vieux eth0 des tutoriels :

ip -br link

La sortie liste les interfaces et leur état (UP ou DOWN). Retenez le nom de celle qui vous relie au réseau, c'est lui qui servira de clé YAML.

Créez ensuite /etc/netplan/99-static.yaml. Le préfixe 99- garantit qu'il est lu après le fichier 50-cloud-init.yaml posé par l'installateur, donc que ses valeurs l'emportent :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 9.9.9.9
          - 149.112.112.112

Chaque bloc a un rôle précis, et c'est cette grammaire que vous réutiliserez partout ensuite :

• version: 2 : la version du format Netplan, la seule en usage aujourd'hui.
• renderer : le backend qui exécutera la configuration, networkd sur un serveur.
• ethernets : la famille d'interfaces physiques ; la clé enp3s0 est le nom de l'interface.
• addresses : l'adresse IP et son masque en notation CIDR (/24).
• routes avec to: default : la passerelle par défaut, c'est-à-dire la route empruntée par tout trafic sortant du réseau local.
• nameservers : les résolveurs DNS interrogés par la machine.

`gateway4` et `gateway6` sont dépréciés

De nombreux tutoriels utilisent encore gateway4: 192.168.1.1. Cette directive est dépréciée depuis Netplan 0.103 (2021) : sur Ubuntu 22.04 et suivantes, netplan apply affiche un avertissement, et le support finira par disparaître. Utilisez la forme routes: montrée ci-dessus, valable pour IPv4 comme IPv6.

Protégez le fichier avant toute chose : il contiendra tôt ou tard un mot de passe Wi-Fi ou une clé, et Netplan refuse désormais les permissions trop larges.

sudo chown root:root /etc/netplan/99-static.yaml
sudo chmod 600 /etc/netplan/99-static.yaml
ls -l /etc/netplan/99-static.yaml

La sortie doit afficher -rw------- 1 root root. Toute autre valeur déclenchera un avertissement Permissions for /etc/netplan/... are too open au prochain netplan apply.

Appliquer sans se couper l'accès SSH

C'est le point critique de cette page. Une erreur de passerelle ou un masque mal posé et votre session SSH meurt sur le champ, sur une machine parfois située à des centaines de kilomètres. Netplan fournit précisément le garde-fou qui évite ça : netplan try.

sudo netplan try

La commande applique la configuration, puis attend votre confirmation. Si vous n'appuyez pas sur Entrée dans le délai imparti, elle restaure automatiquement la configuration précédente : votre session SSH étant morte, vous ne confirmez rien, et la machine revient d'elle-même à un état joignable. Le délai par défaut est de 120 secondes, ajustable avec --timeout :

sudo netplan try --timeout 60

Une fois la nouvelle configuration confirmée par netplan try, elle est déjà active et persistante. netplan apply sert aux cas où vous êtes sur la console locale ou certain de votre coup : il applique immédiatement, sans filet de retour arrière.

sudo netplan apply

Ne lancez jamais `netplan apply` en aveugle à distance

netplan apply n'a aucun mécanisme d'annulation. Sur un serveur distant sans console de secours (KVM sur IP, console cloud, accès physique), une erreur de routes vous laisse une machine injoignable et un déplacement à prévoir. Le réflexe à automatiser : netplan try d'abord, toujours.

Vérifier le résultat

Appliquer ne suffit pas : il faut prouver que l'état voulu est en place. Trois commandes couvrent l'essentiel, de l'interface jusqu'à la résolution de noms. Vérifiez d'abord l'adresse et l'état de l'interface :

ip -br addr show enp3s0

La sortie doit contenir UP et l'adresse 192.168.1.100/24. Si l'adresse attendue manque, la configuration n'a pas été prise en compte, ou un autre fichier de /etc/netplan/ l'a écrasée.

Vérifiez ensuite la route par défaut, celle qui conditionne toute sortie vers Internet :

ip route show default

Vous devez lire default via 192.168.1.1 dev enp3s0. Une passerelle absente ou erronée donne une machine qui ping son voisin mais rien au-delà.

Vérifiez enfin la résolution DNS, gérée par systemd-resolved quand le renderer est networkd :

resolvectl status enp3s0

La ligne DNS Servers: doit lister vos résolveurs. Sur Ubuntu 24.04 LTS, la commande netplan status --all offre une vue de synthèse (interfaces, adresses, routes, DNS) et netplan status --diff signale les écarts entre l'état réel du système et vos fichiers YAML.

Les commandes Netplan à connaître

Netplan expose peu de commandes, et savoir laquelle sert à quoi vous évite de manipuler des fichiers à l'aveugle. Elles se répartissent en deux familles : celles qui transforment vos YAML en configuration backend, et celles qui vous aident à lire l'état courant.

Commande	Ce qu'elle fait	Quand l'utiliser
netplan generate	Traduit les YAML en fichiers backend sous /run/	Valider la syntaxe sans toucher au réseau
netplan try	Applique avec retour arrière automatique	Toute modification à distance
netplan apply	Applique définitivement, sans filet	Console locale, changement trivial
netplan get	Affiche la configuration fusionnée de tous les fichiers	Comprendre qui gagne entre deux fichiers
netplan status	Montre l'état réel des interfaces	Vérification après application

Glissez pour voir

netplan generate est le meilleur test à blanc : il analyse vos YAML et échoue bruyamment sur une erreur de syntaxe, sans reconfigurer la moindre interface. C'est la commande à lancer juste après avoir édité un fichier.

sudo netplan generate

Aucune sortie signifie que la syntaxe est valide. Les fichiers produits atterrissent dans des répertoires volatiles, régénérés à chaque démarrage.

Où regarder quand vous déboguez

Les fichiers générés vivent sous /run/, jamais sous /etc/ : /run/systemd/network/ pour systemd-networkd, et /run/NetworkManager/system-connections/ pour NetworkManager. Le répertoire /etc/NetworkManager/system-connections/ contient les connexions propres à NetworkManager, créées hors Netplan : chercher vos fichiers générés là-bas vous enverrait sur une fausse piste. Rien de ce qui est sous /run/ ne doit être édité à la main, tout y est écrasé au prochain netplan generate.

Comprendre les deux backends

Netplan ne configure rien lui-même : il génère la configuration d'un autre service, appelé renderer (backend). Deux existent, et choisir le mauvais donne une configuration silencieusement inopérante.

systemd-networkd est le backend des serveurs, notamment Ubuntu Server. Minimaliste et intégré à systemd, il convient aux interfaces statiques qui ne bougent pas entre deux redémarrages. C'est la valeur renderer: networkd.

NetworkManager est le backend des postes de travail (Ubuntu Desktop et dérivés graphiques). Il gère le Wi-Fi, les VPN, les réseaux mobiles et les interfaces qui apparaissent et disparaissent. C'est la valeur renderer: NetworkManager, obligatoire pour les configurations wifis: sur un poste de bureau.

Vérifiez lequel tourne réellement avant d'écrire votre renderer :

systemctl is-active systemd-networkd NetworkManager

La commande renvoie une ligne par service : active pour celui qui pilote le réseau, inactive ou unknown pour l'autre. Déclarer renderer: NetworkManager sur un serveur où seul systemd-networkd tourne produit une configuration qui ne s'applique jamais, sans message d'erreur évident. C'est un piège classique.

Structure des fichiers et ordre d'application

Tous les fichiers de /etc/netplan/ se terminant par .yaml sont lus, puis fusionnés dans l'ordre alphabétique de leurs noms. D'où la convention des préfixes numériques : 50-cloud-init.yaml (posé par l'installateur ou cloud-init) est lu avant 99-static.yaml, et en cas de clé identique, le dernier lu gagne.

Cette règle explique la panne la plus déroutante du débutant : une configuration correcte, appliquée sans erreur, et pourtant sans effet, parce qu'un fichier de nom supérieur redéfinit la même interface. Pour voir la configuration réellement retenue après fusion :

sudo netplan get

La sortie est le YAML consolidé, tous fichiers confondus. Si l'adresse que vous y lisez n'est pas la vôtre, c'est qu'un autre fichier prime : renommez le vôtre avec un préfixe plus élevé, ou corrigez le fichier fautif.

Configurations types

Les blocs suivants réutilisent la même grammaire, en changeant simplement la famille d'interfaces déclarée sous network:. Adaptez les noms d'interfaces à ceux relevés par ip -br link : enp3s0 est un exemple, pas une valeur universelle. Chaque exemple est suivi de sa commande de vérification.

DHCP, la configuration minimale

Sur un réseau où un serveur DHCP distribue les adresses, la déclaration tient en une ligne utile. C'est le cas des postes clients et de beaucoup de machines virtuelles :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: true

Après sudo netplan try, vérifiez que le bail DHCP a bien été obtenu avec ip -br addr show enp3s0 : une adresse doit apparaître, et ip route show default doit afficher la passerelle annoncée par le serveur DHCP.

IPv6, en dynamique et en statique

L'IPv6 suit exactement la même grammaire que l'IPv4, ce qui limite l'effort d'apprentissage. En dynamique, dhcp6: true demande une adresse au réseau ; en statique, on pose l'adresse et sa longueur de préfixe (/64), puis la route par défaut :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp6: false
      addresses:
        - 2001:db8:85a3::8a2e:370:7334/64
      routes:
        - to: default
          via: 2001:db8:85a3::1
      nameservers:
        addresses:
          - 2620:fe::fe
          - 2620:fe::9

Netplan déduit la famille d'adresses de la valeur de via : la même clé routes: sert à IPv4 et IPv6. Vérifiez avec ip -6 route show default, qui doit afficher la passerelle IPv6 sur la bonne interface.

Routes statiques supplémentaires

Une route statique dirige un réseau précis vers une passerelle autre que la passerelle par défaut, typiquement un réseau interne joignable par un routeur dédié. On empile alors plusieurs entrées sous routes:, la clé metric réglant la priorité quand deux routes se recouvrent (la plus basse gagne) :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
        - to: 10.20.0.0/16
          via: 192.168.1.254
          metric: 100

Vérifiez avec ip route show, qui doit lister à la fois la route default et la ligne 10.20.0.0/16 via 192.168.1.254. Une route absente vient presque toujours d'une passerelle hors du sous-réseau de l'interface : via doit être joignable directement.

VLAN

Un VLAN (réseau local virtuel, norme 802.1Q) fait circuler plusieurs réseaux logiques sur un seul câble, chaque trame portant une étiquette numérotée. Côté Netplan, on déclare l'interface physique, puis une interface virtuelle avec son id et son link :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
  vlans:
    vlan30:
      id: 30
      link: enp3s0
      addresses:
        - 192.168.30.10/24

La clé id porte l'étiquette VLAN (de 0 à 4094) et link désigne l'interface physique porteuse, qui reste volontairement sans adresse. Le port du commutateur en face doit être configuré en mode « tagged » pour ce VLAN, sinon les trames sont jetées. Vérifiez avec ip -d link show vlan30 : la sortie doit mentionner vlan protocol 802.1Q id 30.

Bridge réseau

Un bridge (pont) fait se comporter plusieurs interfaces comme un seul commutateur logiciel. C'est la base de la virtualisation : les machines virtuelles s'y raccordent et apparaissent directement sur le réseau physique. L'interface physique est déclarée sans adresse, car c'est le bridge qui porte l'IP :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      dhcp4: true
      interfaces:
        - enp3s0

L'interface enp3s0 est ajoutée au bridge via la liste interfaces:, et c'est br0 qui obtient l'adresse en DHCP. Laisser une adresse sur enp3s0 est l'erreur classique : le trafic part alors par la mauvaise interface. Vérifiez avec ip -br addr show br0 (l'adresse doit être sur br0, pas sur enp3s0) puis bridge link show, qui doit lister enp3s0 comme membre.

Bonding (agrégation de liens)

Le bonding agrège plusieurs cartes réseau en un lien logique unique, pour la tolérance de panne ou pour cumuler la bande passante. Le choix du mode est la décision structurante, car il détermine ce qu'il faut configurer côté commutateur :

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: false
    eno2:
      dhcp4: false
  bonds:
    bond0:
      interfaces:
        - eno1
        - eno2
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

Le mode 802.3ad correspond à l'agrégation LACP : les deux liens sont actifs en même temps, ce qui additionne leur débit et assure la reprise si l'un tombe. Il exige que le commutateur soit configuré pour LACP en face, sinon le lien ne monte pas. Le mode active-backup garde au contraire une seule interface active et bascule sur l'autre en cas de panne : il ne demande aucune configuration du commutateur, mais n'additionne pas les débits. mii-monitor-interval: 100 fixe la fréquence (en millisecondes) de surveillance des liens physiques.

Vérifiez l'état réel du bond dans le noyau :

cat /proc/net/bonding/bond0

La sortie doit indiquer le mode négocié et le statut up de chaque esclave. En LACP mal configuré côté commutateur, vous verrez les ports rester inactifs.

Wi-Fi

La configuration Wi-Fi passe obligatoirement par le renderer NetworkManager sur un poste de bureau. On déclare le SSID et sa clé sous access-points: :

network:
  version: 2
  renderer: NetworkManager
  wifis:
    wlan0:
      access-points:
        "MonSSID":
          password: "motdepassewifi"
      dhcp4: true

La clé access-points associe le nom du réseau à ses paramètres, ici un simple mot de passe WPA. Ce mot de passe est stocké en clair dans le fichier : les permissions 600 vues plus haut ne sont pas une coquetterie. Vérifiez l'association avec nmcli device wifi list, où votre SSID doit apparaître avec un astérisque, puis ip -br addr show wlan0 pour l'adresse obtenue.

Sécurité et points de vigilance

La configuration réseau est un point d'exposition : elle décide de ce que la machine peut joindre et de ce qui peut la joindre. Quatre réflexes réduisent le risque sans effort. D'abord les permissions : chmod 600 sur tout fichier de /etc/netplan/, parce qu'ils portent des secrets Wi-Fi et révèlent votre plan d'adressage à n'importe quel utilisateur local.

Ensuite le rollback : avant toute modification à distance, gardez un moyen d'accès de secours (console cloud, KVM sur IP) et passez par netplan try. Ce duo est ce qui distingue un changement réversible d'un déplacement sur site.

Enfin la persistance : un changement Netplan doit survivre au redémarrage. La configuration vivant sous /etc/netplan/, elle est rejouée au boot, mais rien ne remplace la vérification réelle. Après un reboot de la machine, relancez ip -br addr show et ip route show default : vous devez retrouver exactement l'état attendu. Un serveur qui perd son adresse au reboot vient le plus souvent d'un fichier /etc/netplan/ non enregistré ou d'un conflit avec 50-cloud-init.yaml.

Dépannage

Les échecs Netplan se ressemblent beaucoup et se diagnostiquent vite, à condition de savoir où regarder. Ce tableau couvre les symptômes les plus fréquents en production ; il s'utilise du haut vers le bas, du plus courant au plus subtil.

Symptôme	Cause probable	Correction
netplan generate renvoie une erreur de parsing	Tabulation ou indentation invalide dans le YAML	Remplacer toute tabulation par des espaces, relancer sudo netplan generate
Permissions for /etc/netplan/... are too open	Fichier lisible par d'autres utilisateurs	sudo chmod 600 /etc/netplan/*.yaml
La configuration s'applique sans erreur mais l'IP ne change pas	Un fichier de nom alphabétique supérieur (souvent 50-cloud-init.yaml) redéfinit l'interface	sudo netplan get pour voir la fusion, renommer votre fichier en 99-
L'interface n'est pas configurée du tout	renderer déclaré vers un backend absent ou inactif	systemctl is-active systemd-networkd NetworkManager, aligner le renderer
Ping du voisin OK, Internet KO	Route par défaut absente ou passerelle erronée	ip route show default, corriger routes: - to: default
Avertissement de dépréciation à l'apply	gateway4 ou gateway6 encore présent	Migrer vers routes: - to: default, via: ...
Accès SSH perdu après un changement	netplan apply utilisé au lieu de netplan try	Reprendre la main par la console, puis appliquer la règle netplan try

Glissez pour voir

Quand le tableau ne suffit pas, les journaux système livrent la cause exacte. Interrogez le backend concerné, journalctl -u systemd-networkd ou journalctl -u NetworkManager, et lancez sudo netplan --debug apply pour voir chaque étape du rendu et le fichier fautif.

D'où vient Netplan

Netplan est apparu dans Ubuntu 17.10, à une époque où la configuration réseau se répartissait entre /etc/network/interfaces (avec les outils ifup et ifdown), NetworkManager et systemd-networkd, chacun avec sa syntaxe. Canonical a voulu une description unique du réseau, indépendante du service qui l'exécute, ce qui a beaucoup servi à l'essor des images cloud : cloud-init produit du YAML Netplan, sans se soucier du backend de la machine cible. C'est tout l'intérêt de l'outil, et aussi sa limite, puisque cette unification s'arrête aux frontières d'Ubuntu.

Mettre en pratique

Configurez vous-même une IP statique et une route persistantes avec netplan sur une VM, puis vérifiez la connectivité. Un drill en conditions d'examen reprend l'exercice sans indices, sur RHEL ou Ubuntu.

Lab pratique

Configurer une IP statique et une route avec netplan

$ dsoxlab run lfcs-netplan-static

Environnement : VM·Durée : ~25 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run lfcs-netplan-static
dsoxlab check lfcs-netplan-static

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Drill · conditions d'examen

Drill : réseau statique en conditions d'examen

$ dsoxlab check drill-network --target rhel|ubuntu

Environnement : VM·Durée : ~20 min

Format : sans indices, chronométré, bi-distribution (rhel ou ubuntu) : un seul contenu pour RHCSA et LFCS.

Validé : le score est calculé sans indice et en temps limité, comme à l'examen.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run drill-network
dsoxlab check drill-network

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Netplan est spécifique à Ubuntu : il ne remplace ni nmcli sur RHEL, ni /etc/network/interfaces sur Debian.
• Netplan ne configure rien lui-même : il génère la configuration de systemd-networkd (serveurs) ou de NetworkManager (postes), désigné par la clé renderer.
• netplan try annule automatiquement après 120 secondes sans confirmation : c'est le seul geste sûr à distance. netplan apply n'a aucun retour arrière.
• netplan generate valide la syntaxe YAML sans toucher au réseau, et écrit sous /run/systemd/network/ ou /run/NetworkManager/system-connections/, jamais sous /etc/NetworkManager/system-connections/.
• gateway4 et gateway6 sont dépréciés depuis Netplan 0.103 : utilisez routes: - to: default, identique en IPv4 et IPv6.
• Les fichiers de /etc/netplan/ sont fusionnés dans l'ordre alphabétique : en cas de configuration sans effet, cherchez le fichier qui vous écrase avec netplan get.
• Permissions 600 et propriétaire root obligatoires : ces fichiers contiennent des mots de passe Wi-Fi en clair.
• Après chaque changement, vérifiez avec ip -br addr, ip route show default et resolvectl status, puis retestez après un redémarrage.

×

📖 Voir la documentation →