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 l'outil de configuration réseau par défaut d'Ubuntu et de ses dérivées (Ubuntu Server, Kubuntu, distributions bâties dessus). Debian l'empaquète (netplan.io 1.1.2 sur Debian 13), mais une installation classique configure le réseau par /etc/network/interfaces ou NetworkManager ; sur RHEL, AlmaLinux ou Fedora, il n'est même pas dans les dépôts, et tout 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 signale les permissions trop larges à chaque lecture.

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éclenche l'avertissement Permissions for /etc/netplan/... are too open. Netplan configuration should NOT be accessible by others. à chaque netplan generate ou netplan apply. Ce n'est qu'un avertissement : la configuration s'applique quand même, et le fichier reste lisible par tous tant que vous ne corrigez pas.

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 hors de toute séquence try (voir l'avertissement plus bas)
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 analyse vos YAML et échoue sur une erreur de syntaxe sans reconfigurer la moindre interface. C'est un test à blanc commode.

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.

Ne lancez pas netplan generate juste avant netplan try

C'est le piège le plus grave de cette page, parce qu'il désarme le filet de sécurité au moment précis où vous croyez le tendre.

Le retour arrière de netplan try ne relit pas vos fichiers YAML : il restaure une copie de /run/systemd/network/ et de /run/NetworkManager/system-connections/, prise au tout début de la commande. Or /run/systemd/network/, c'est exactement ce que netplan generate vient de réécrire avec votre nouvelle configuration.

La sauvegarde photographie donc la nouvelle configuration, et « revenir en arrière » vous y ramène. Mesuré sur Ubuntu 24.04 (netplan.io 1.1.2) : une interface passée de 10.50.0.1 à 10.60.0.1, puis netplan try --timeout 5 laissé sans réponse, revient bien à 10.50.0.1 ; la même séquence précédée d'un netplan generate affiche Reverting. et laisse l'interface en 10.60.0.1. Lisible aussi dans le code livré par le paquet netplan.io : configmanager.revert() ne restaure que les deux répertoires de /run/, et try_command.py réapplique ensuite avec run_generate=False, donc sans jamais repasser par /etc/netplan. Le détail qui achève de tromper : backup() copie bien /etc/netplan, mais cette copie n'est jamais utilisée par le retour arrière.

La règle correcte : netplan try d'abord, directement. Il fait son propre generate en interne et refuse un YAML invalide avec un code de retour 78 avant de toucher au réseau. Vous ne perdez donc rien à sauter l'étape, et vous gardez un filet qui fonctionne.

Quand vous déboguez, sachez où regarder. 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 casse le réseau au moment même où vous appliquez.

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, le choix naturel 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 pour l'autre. Déclarer renderer: NetworkManager sur un serveur où NetworkManager n'est pas installé fait échouer netplan apply avec Failed to start NetworkManager.service: Unit NetworkManager.service not found. suivi d'une trace Python, et l'interface perd au passage sa configuration : networkd a lâché l'interface, que personne ne reprend. En SSH, c'est la coupure assurée ; netplan try vous ramène, lui, à l'état précédent.

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, netplan generate refuse 4095 avec allowed values are 0 to 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

Sur un poste de bureau, la configuration Wi-Fi se déclare avec le renderer NetworkManager, qui gère déjà le Wi-Fi de l'interface graphique. Sur un serveur sans NetworkManager, renderer: networkd fonctionne aussi : Netplan génère alors un service netplan-wpa-wlan0.service qui lance wpa_supplicant (paquet à installer). Dans les deux cas, 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. Trois 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-
netplan apply échoue sur Unit NetworkManager.service not found	renderer: NetworkManager sur une machine sans NetworkManager	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 guidé Pratique

Apprendre à faire

Configurer une IP statique et une route avec netplan

$ dsoxlab run lfcs-netplan-static

Environnement : VM·Durée : ~25 min

Vérification : 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.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start lfcs-netplan-static vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

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. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

Challenge · conditions d'examen Preuve

Résoudre sans procédure détaillée

Drill : réseau statique en conditions d'examen

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

Environnement : VM·Durée : ~20 min ·Réussite : 70 % du barème

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

Vérification : 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.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start drill-network vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

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. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

• Netplan est l'outil par défaut d'Ubuntu : il ne remplace ni nmcli sur RHEL, ni /etc/network/interfaces sur une Debian installée classiquement.
• 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.
• Ne lancez jamais netplan generate juste avant netplan try : il réécrit /run/systemd/network/, c'est-à-dire ce que le retour arrière restaure, et le filet ne ramène alors plus rien.
• 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.

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

×

📖 Voir la documentation →