Cours accéléré Netplan pour serveurs dédiés Ubuntu

Ce qu'est Netplan, et si vous l'utilisez

Netplan est la couche de configuration réseau qu'Ubuntu fournit par défaut depuis la 17.10. Vous écrivez vos interfaces, adresses, routes et DNS en YAML dans /etc/netplan/, et un générateur transforme cette description unique en configuration pour le backend qui pilote le réseau en dessous, quel qu'il soit : systemd-networkd sur Ubuntu Server, NetworkManager sur Ubuntu Desktop. Vous modifiez un seul format de fichier ; Netplan rend la configuration spécifique au backend en dessous.

Si vous avez loué un serveur dédié et y avez installé Ubuntu, vous avez Netplan. Ce guide est écrit pour exactement cette machine : un serveur, une adresse IPv4 publique statique (et souvent une allocation IPv6), pas de Wi-Fi, et SSH comme seul point d'entrée. Ce dernier détail donne le ton de tout l'article, car une erreur réseau sur un serveur distant est précisément la manière dont on se retrouve enfermé dehors. Netplan dispose d'un outil spécifique pour empêcher cela, et nous nous appuyons dessus à chaque fois que nous modifions quelque chose en direct.

Ce cours accéléré couvre :

• l'emplacement des fichiers de configuration, et la règle de permission qui piège pas mal de monde
• le modèle à deux backends, et ce qui change quand vous reprenez une config d'un tutoriel écrit pour l'autre
• une configuration statique IPv4 et IPv6 complète que vous pouvez adapter ligne par ligne
• les commandes que vous utilisez au quotidien : generate, try, apply et status
• les VLANs, les bonds LACP, et une bridge pour les hôtes de VM
• pourquoi vos modifications disparaissent parfois après un redémarrage, et le réglage cloud-init qui corrige cela

Une brève précision sur les versions. Ubuntu 26.04 LTS « Resolute Raccoon », sortie le 23 avril 2026, livre la série Netplan 1.2. La LTS précédente, 24.04 « Noble Numbat », livrait Netplan 1.0, la première version stable, datée du 29 février 2024. La série upstream est en 1.2.x au moment de la rédaction ; consultez la page des releases pour la version actuelle. Tout ce qui suit s'applique aux deux, avec les différences signalées là où elles apparaissent. Si vous hésitez encore sur la version à faire tourner, le guide des LTS Ubuntu Server couvre les délais de support.

Où se trouve la configuration

Chaque fichier *.yaml dans /etc/netplan/ compte. Deux autres répertoires interviennent aussi : /run/netplan/ pour la configuration d'exécution et /lib/netplan/ pour les valeurs par défaut du fournisseur. Les fichiers sont lus par ordre lexicographique de nom et fusionnés en un seul modèle. Quand la même clé est définie deux fois, le fichier le plus récent l'emporte. Si un fichier du même nom existe dans plusieurs répertoires, la copie dans /run/netplan/ prime sur /etc/netplan/, qui prime lui-même sur /lib/netplan/.

Cet ordre explique pourquoi un fichier nommé 50-cloud-init.yaml compte autant. Sur la plupart des images cloud et serveur dédié, cloud-init écrit vos réglages réseau initiaux exactement dans ce fichier, et son préfixe 50- se situe tôt dans l'ordre de tri. Placez votre propre 90-static.yaml à côté et le vôtre l'emporte à la fusion, mais cloud-init peut réécrire son propre fichier au prochain démarrage et annuler les hypothèses que vous aviez posées. La solution propre arrive plus loin, dans le dépannage. Pour l'instant, sachez que 50-cloud-init.yaml est généré, pas écrit à la main, et traitez-le comme tel.

Une règle piège presque tout le monde au moins une fois. Chaque fichier sous /etc/netplan/ devrait appartenir à root et n'être lisible que par root, mode 600. Netplan stocke dans ces fichiers des identifiants comme les mots de passe Wi-Fi et les clés de tunnel, donc une config lisible par tous expose des secrets. Depuis la version 0.106, l'outil affiche un avertissement dès qu'il trouve un fichier lisible par quelqu'un d'autre que root :

** (generate:1234): WARNING **: Permissions for /etc/netplan/50-cloud-init.yaml
are too open. Netplan configuration should NOT be accessible by others.

Corrigez cela en une seule commande :

chmod 600 /etc/netplan/*.yaml

Cet avertissement est facile à ignorer parce que le réseau continue de fonctionner, mais resserrer les permissions fait partie de toute passe de durcissement du serveur et ne coûte rien.

Une source YAML, deux backends

Netplan lui-même ne gère aucune interface directement. Il génère la configuration pour un renderer, et c'est le renderer qui fait le travail. Il en existe deux, et celui qui tourne par défaut dépend de la façon dont Ubuntu a été installé :

Sur un serveur, vous changez rarement cela. systemd-networkd démarre tôt dans la séquence de démarrage, n'a aucune dépendance graphique, et c'est le bon backend pour une machine que vous atteignez par SSH. Vous pouvez le nommer explicitement avec renderer: networkd en haut du fichier, même si c'est déjà le défaut sur Ubuntu Server.

Pourquoi cette distinction compte : une configuration reprise d'un tutoriel orienté desktop peut définir renderer: NetworkManager ou s'appuyer sur des clés propres à NetworkManager, et elle se comportera différemment, ou refusera de s'appliquer, sur un serveur networkd. Quand vous empruntez un extrait, vérifiez quel backend il suppose avant de le coller.

Une configuration statique complète

Voici une configuration statique complète pour une seule interface, avec IPv4 et IPv6. Elle assigne les adresses, définit les routes par défaut et configure le DNS. Les noms d'interface sur un Ubuntu récent suivent le schéma prévisible, la vôtre s'appelle donc probablement enp1s0, eno1, ou quelque chose de similaire ; lancez ip -br link pour voir comment votre noyau l'appelle.

# /etc/netplan/90-static.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.0.2.10/24
        - "2001:db8::10/64"
      routes:
        - to: default
          via: 192.0.2.1
        - to: default
          via: "2001:db8::1"
      nameservers:
        addresses:
          - 192.0.2.53
          - 2001:db8::53
        search:
          - example.com

version: 2 est la version de format Netplan et elle est obligatoire. dhcp4: false est déjà la valeur par défaut dès que vous fournissez des adresses statiques, mais l'indiquer explicitement rend votre intention claire pour la prochaine personne qui lira ce fichier. Chaque adresse porte sa longueur de préfixe en notation CIDR. Le bloc routes est la partie qui mérite d'être lue deux fois.

Vous trouverez d'anciens tutoriels qui définissent la passerelle ainsi :

      gateway4: 192.0.2.1

Cette clé est deprecated. Netplan met en garde contre gateway4 et gateway6 depuis la version 0.103, et le message est direct :

gateway4 has been deprecated, use default routes instead.

Le remplacement est l'entrée routes avec to: default, exactement comme dans l'exemple complet ci-dessus. Elle fait le même travail, fonctionne pour IPv4 et IPv6 via un seul mécanisme, et vous permet d'ajouter plus tard des routes non par défaut sans changer de style. Utilisez-la, et laissez de côté gateway4 même s'il fonctionne encore.

Ne réutilisez pas telles quelles les IP et les noms d'interface montrés ici. Les adresses proviennent des plages TEST-NET et de documentation réservées aux exemples ; substituez les valeurs que votre fournisseur vous a données.

Le jeu de commandes : generate, try, apply

Netplan ne touche pas à votre réseau actif tant que vous n'exécutez pas l'une de trois commandes. Connaître la différence entre elles, c'est ce qui garde une session distante en vie.

netplan generate rend votre YAML en configuration backend sous /run/systemd/network/ (pour networkd) sans toucher au réseau en cours d'exécution. Elle sert aussi de validateur : si votre YAML contient une erreur de syntaxe ou une clé inconnue, generate échoue et vous dit où, et rien n'a encore changé. Lancez-la en premier dès que vous avez un doute.

La commande qui modifie le système actif est netplan apply. Elle régénère la config puis l'applique d'un coup, reconfigurant l'interface sur place lors d'un changement d'adresse statique. Sur une machine distante, le danger est immédiat : si la nouvelle config est erronée, vous venez de couper votre propre session SSH, et il n'y a pas de retour en arrière possible depuis où vous êtes assis.

netplan try est la réponse à ce danger, et sur un serveur distant, c'est la commande à privilégier par défaut. Elle applique la configuration, puis démarre un compte à rebours ; si vous ne confirmez pas avant la fin du délai, elle annule le changement pour revenir à l'état précédent. Le délai par défaut est de 120 secondes, ajustable avec --timeout :

netplan try --timeout 90

Appuyez sur Entrée pour conserver le changement, ou attendez et laissez-le s'annuler. Si votre nouvelle config casse la connectivité, vous perdez la session, ne confirmez jamais, et deux minutes plus tard le serveur a restauré la configuration qui fonctionnait et votre SSH est de nouveau joignable. Cette annulation automatique est tout l'intérêt de la commande. Elle n'est pas infaillible : certains changements impliquant des renommages d'interface ou certaines transitions de backend ne s'annulent pas proprement, et c'est précisément là qu'un serveur dédié avec une console IPMI ou iKVM justifie son prix. L'accès console hors bande est le filet de sécurité pour le jour où try ne peut pas vous sauver, et cela vaut la peine de vérifier que vous l'avez avant d'en avoir besoin.

Une fois le réseau actif, netplan status vous montre ce que le backend a fait de votre config :

     Online state: online
    DNS Addresses: 192.0.2.53
       DNS Search: example.com

●  2: enp1s0 ethernet UP (networkd: enp1s0)
      MAC Address: 52:54:00:11:22:33
        Addresses: 192.0.2.10/24
                   2001:db8::10/64
           Routes: default via 192.0.2.1 (static)
                   default via 2001:db8::1 (static)

(La sortie est donnée à titre d'illustration.) netplan status est arrivée avec la version 0.106. À partir de la 1.0, netplan status --diff montre en plus où l'état en cours d'exécution diffère de votre YAML, ce qui est le moyen le plus rapide de repérer une config qui a bien été générée mais pas entièrement appliquée.

Deux commandes supplémentaires lisent et écrivent le modèle fusionné sans ouvrir d'éditeur. netplan get affiche la configuration actuelle en YAML, et netplan set change une seule valeur via un chemin à points :

netplan get ethernets.enp1s0.addresses
netplan set ethernets.enp1s0.dhcp4=false

netplan set écrit par défaut dans /etc/netplan/90-netplan-set.yaml, ce qui est pratique pour les scripts et déroutant si vous oubliez qu'elle le fait ; consultez ce fichier si une valeur semble apparaître de nulle part.

Aide-mémoire

Les tâches que vous répétez, et le fragment YAML ou la commande pour chacune :

VLANs, bonds et bridges

Trois constructions reviennent assez souvent sur les serveurs pour rester à portée de main. Chacune s'appuie sur le même fichier ; les types d'interface passent dans leur propre bloc de premier niveau.

Un VLAN tagué sur un uplink

Quand votre fournisseur vous donne un VLAN tagué pour un réseau privé, définissez-le comme une entrée vlans qui référence l'interface physique via son link :

network:
  version: 2
  ethernets:
    enp1s0: {}
  vlans:
    enp1s0.100:
      id: 100
      link: enp1s0
      addresses:
        - 198.51.100.10/24

L'id est le tag 802.1Q, et link nomme l'interface parente, qui reste définie (ici avec un {} vide) pour que Netplan l'active. Le trafic non tagué continue d'utiliser le parent ; les trames taguées pour le VLAN 100 empruntent la nouvelle interface logique.

Deux NIC en bond avec LACP

Un bond agrège plusieurs liens en une seule interface logique, pour la bande passante ou la redondance. Le mode 802.3ad est LACP, et il exige que le côté switch soit configuré en conséquence :

network:
  version: 2
  ethernets:
    eno1: {}
    eno2: {}
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses:
        - 192.0.2.20/24
      routes:
        - to: default
          via: 192.0.2.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100

LACP est un accord entre les deux extrémités. Si les ports du switch en amont ne sont pas dans un groupe LACP correspondant, le bond ne montera pas, donc coordonnez-vous avec la personne qui gère le switch avant d'appliquer ceci.

Un bridge pour les machines virtuelles

Si le serveur est un hôte KVM ou LXD, un bridge permet aux invités de partager la NIC physique comme s'ils étaient branchés sur un switch. L'adresse de l'hôte migre sur le bridge, et l'interface physique devient un port de bridge sans adresse propre :

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp1s0]
      addresses:
        - 192.0.2.30/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [192.0.2.53]
      parameters:
        stp: false
        forward-delay: 0

C'est la même idée que Proxmox met en œuvre avec son vmbr0, si vous l'avez déjà rencontré. Désactiver le spanning-tree et le forward delay convient à un bridge d'hôte à uplink unique ; ne les laissez actifs que lorsque le bridge a plusieurs ports physiques susceptibles de former une boucle.

Quand la configuration ne prend pas : dépannage

La plupart des problèmes Netplan se répartissent en quelques catégories.

Indentation YAML. Le YAML de Netplan utilise des espaces pour l'indentation et rejette catégoriquement les tabulations. Une tabulation égarée, ou une indentation incohérente, produit une erreur de parsing. Lancez netplan generate après chaque modification : c'est le validateur le moins coûteux dont vous disposez, et il refuse d'écrire une config cassée plutôt que de l'appliquer.

Le changement a été généré, mais l'interface semble incorrecte. Demandez au backend ce qu'il a fait plutôt que de faire confiance au YAML. ip addr et ip route montrent les adresses et routes installées sur le lien ; networkctl status enp1s0 montre la vue de systemd-networkd ; resolvectl status montre les serveurs DNS en vigueur. Si netplan status --diff signale un écart entre votre fichier et l'état en cours d'exécution, l'apply n'a pas pleinement pris, et l'une de ces commandes vous montrera où.

Vos modifications disparaissent après un redémarrage. C'est l'écrasement par cloud-init, la surprise la plus courante sur un serveur dédié ou cloud. cloud-init régénère /etc/netplan/50-cloud-init.yaml au démarrage à partir de sa propre source de données, en écrasant tout ce qu'il pense posséder. La solution prise en charge consiste à dire une bonne fois à cloud-init d'arrêter de gérer le réseau :

echo 'network: {config: disabled}' | \
  tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Après cela, cloud-init laisse /etc/netplan/ tranquille et votre propre fichier devient la seule source de vérité. Vous pouvez ensuite supprimer ou réécrire 50-cloud-init.yaml, et cela restera ainsi. Faites cela avant d'investir du temps dans une config écrite à la main, pas après avoir combattu deux fois le même redémarrage.

Quand vous n'avez pas Netplan

Netplan est un défaut propre à Ubuntu, pas une constante universelle sous Linux. Dans la famille RHEL (RHEL, AlmaLinux, Rocky) et sur la plupart des distributions de bureau, il n'y a pas de couche Netplan : NetworkManager gère les interfaces directement, et vous le configurez avec nmcli, nmtui, ou des fichiers de connexion. Si votre parc est mixte, le cours accéléré NetworkManager qui l'accompagne couvre ce côté avec le même angle serveur.

Debian est le presque-cas. Le paquet netplan.io se trouve dans les dépôts de Debian, vous pouvez donc l'installer et l'utiliser, mais Debian ne l'emploie pas par défaut ; un serveur Debian standard configure toujours le réseau via ifupdown et /etc/network/interfaces, ou NetworkManager sur le bureau. Si vous hésitez entre les deux, la comparaison Ubuntu contre Debian détaille où chacun trouve sa place, et le guide de choix de distribution plus large oppose Netplan par défaut aux alternatives.

Déployer sur Serverside

Netplan n'est utile qu'à la mesure du réseau qui se trouve dessous. Un serveur dédié Serverside tourne sur notre propre réseau (AS55285), donc les adresses IPv4 et IPv6 statiques que vous écrivez dans ce YAML se trouvent derrière un routage que nous contrôlons, avec une mitigation DDoS permanente devant l'interface publique. Le provisioning prend moins d'une minute : un serveur Ubuntu tout neuf est déployé en moins d'une minute, une image LTS avec Netplan déjà en place, prête avant même que vous ayez fini de rédiger la config qui va tourner dessus.

Questions fréquentes

Quelle est la différence entre netplan apply et netplan try ?

netplan apply régénère la configuration backend et l'applique immédiatement au système actif, sans retour en arrière possible si cela coupe votre connexion. netplan try applique la même configuration, mais démarre un compte à rebours de 120 secondes et annule automatiquement le changement si vous ne confirmez pas avec Entrée. Sur un serveur distant, utilisez try dès que vous modifiez quelque chose qui pourrait affecter la liaison par laquelle vous êtes connecté, et réservez apply aux changements dont vous êtes certain ou que vous effectuez depuis la console.

Pourquoi mes changements réseau disparaissent-ils après un redémarrage ?

Presque toujours cloud-init. Sur les images cloud et serveur dédié, cloud-init régénère /etc/netplan/50-cloud-init.yaml à chaque démarrage à partir de sa propre source de données et écrase les modifications qu'il pense posséder. Arrêtez cela en créant /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg avec le contenu network: {config: disabled}, puis gérez /etc/netplan/ vous-même. Après cela, vos fichiers persistent d'un redémarrage à l'autre.

Comment définir les serveurs DNS dans Netplan ?

Ajoutez un bloc nameservers à l'interface, avec une liste addresses et, en option, une liste de domaines search. Les résolveurs s'appliquent dès que vous exécutez netplan apply ou netplan try, et vous pouvez les vérifier avec resolvectl status. Sur les systèmes systemd-networkd, le DNS est géré par systemd-resolved, donc les serveurs que vous définissez apparaissent là plutôt que directement dans /etc/resolv.conf.

Netplan est-il la même chose que NetworkManager ?

Non. Netplan est une couche de configuration qui génère la config pour un backend ; NetworkManager est l'un des deux backends qu'il peut cibler, l'autre étant systemd-networkd. Ubuntu Server utilise le backend networkd par défaut, Ubuntu Desktop utilise NetworkManager, et les deux sont pilotés via le même YAML Netplan. Sur les systèmes sans Netplan, comme les serveurs de la famille RHEL, vous configurez NetworkManager directement à la place.

Je migre depuis /etc/network/interfaces. Netplan le remplace-t-il ?

Oui, sur Ubuntu. L'ancienne pile ifupdown et son fichier /etc/network/interfaces sont ce que Netplan a remplacé quand Ubuntu l'a adopté en 17.10. Vous ne modifiez pas les deux : convertissez chaque bloc iface en l'entrée ethernets Netplan équivalente, avec son adresse, ses routes et ses nameservers, et laissez Netplan produire la config backend. Debian utilise toujours /etc/network/interfaces par défaut, une différence à prévoir en changeant de l'un à l'autre.