Configurer une adresse IP statique sous Debian et Ubuntu

Quatre informations sans lesquelles il ne faut pas commencer

Une adresse statique est vite saisie. Si tant de serveurs restent malgré tout muets après le redémarrage, la cause tient rarement à la syntaxe : le plus souvent, l'une des quatre informations de base a été devinée au lieu d'être relevée. Ces quatre informations sont le nom de l'interface, l'adresse avec sa longueur de préfixe, la passerelle et les serveurs de noms. Relevez ces valeurs pendant que le système tourne, tant que la machine est encore joignable.

ip -brief address show
ip -4 route show
ip -6 route show
cat /etc/resolv.conf

La première ligne fournit le nom de l'interface. Sur les serveurs virtuels, elle s'appelle ens3, enp1s0 ou eth0 selon la plateforme, et souvent eno1 sur du bare metal. Recopiez ce nom, ne le devinez pas. Une faute de frappe à cet endroit produit une configuration syntaxiquement irréprochable, qui ne correspond simplement à aucune carte présente sur la machine.

La longueur de préfixe mérite une attention particulière. Beaucoup d'hébergeurs routent une seule adresse IPv4 en /32 vers le serveur, et la passerelle se situe alors en dehors du sous-réseau local. D'autres attribuent des réseaux /24 classiques. Le chemin réellement emprunté vous dit dans quel cas vous êtes :

ip route get 1.1.1.1

Créez ensuite une sauvegarde. Cela prend dix secondes et fait toute la différence entre un simple retour en arrière et un ticket au support.

cp -a /etc/netplan /root/netplan.bak
cp -a /etc/network/interfaces /root/interfaces.bak

Quel système pilote actuellement votre réseau ?

Debian et Ubuntu n'utilisent pas les mêmes outils, et la panne totale la plus fréquente survient quand deux d'entre eux configurent la même carte en même temps. Commencez donc par faire le point :

ls -l /etc/netplan/
ls -l /etc/network/interfaces /etc/network/interfaces.d/
ls -l /etc/systemd/network/

La règle empirique pour les quatre versions actuelles : Ubuntu 24.04 et Ubuntu 22.04 se configurent via netplan, qui pilote systemd-networkd en arrière-plan. Debian 13 et Debian 12 arrivent après une installation standard avec ifupdown et le fichier /etc/network/interfaces. systemd-networkd est présent sur Debian mais inactif, et netplan peut y être installé après coup, sans pour autant être la voie prévue.

Sur les images cloud, une couche supplémentaire s'ajoute : au premier démarrage, cloud-init écrit son propre fichier, typiquement /etc/netplan/50-cloud-init.yaml, ou sous Debian un bloc dans /etc/network/interfaces.d/. Si vous modifiez ce fichier sans neutraliser cloud-init, vous retrouverez l'ancienne configuration au redémarrage suivant.

Ubuntu 24.04 et 22.04 : adresse statique avec netplan

netplan lit tous les fichiers de /etc/netplan/ par ordre alphabétique et les traduit en configuration pour systemd-networkd. Ne créez pas un second fichier portant sur la même interface : modifiez celui qui existe, ou désactivez proprement l'ancien. Une configuration complète en IPv4 et IPv6 ressemble à ceci :

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 203.0.113.10/24
        - "2001:db8:1234::2/64"
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: "2001:db8:1234::1"
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112, 2620:fe::fe]

Trois points méritent une explication détaillée.

Premièrement, les routes par défaut se déclarent sous routes et non plus sous gateway4 ou gateway6. Ces deux clés sont obsolètes depuis netplan 0.103. Elles fonctionnent encore sur Ubuntu 22.04 et 24.04, mais chaque appel se solde par `gateway4` has been deprecated, use default routes instead. Toute configuration écrite aujourd'hui s'écrit donc avec des routes.

Deuxièmement, accept-ra: false désactive la configuration IPv6 automatique. Si vous la laissez active tout en attribuant une adresse fixe, la carte se retrouve avec deux adresses et deux routes par défaut, et c'est la métrique qui décide laquelle l'emporte, pas votre intention.

Troisièmement, les permissions du fichier. Depuis netplan 0.106, chaque appel émet un avertissement si le fichier YAML est lisible par les autres utilisateurs : Permissions for /etc/netplan/01-static.yaml are too open. Netplan configuration should NOT be accessible by others. Ce n'est pas de la cosmétique, car ce genre de fichier contient aussi des clés Wi-Fi et des données de tunnel.

chmod 600 /etc/netplan/*.yaml

Quand la passerelle se trouve en dehors du sous-réseau

Avec une adresse routée individuellement en /32, le noyau ne connaît aucun chemin direct vers la passerelle et refuse la route. Le journal affiche alors Could not set route: Network is unreachable, et une tentative manuelle avec ip route add répond RTNETLINK answers: Network is unreachable. La solution s'appelle on-link :

      addresses:
        - 203.0.113.10/32
      routes:
        - to: default
          via: 192.0.2.1
          on-link: true

En IPv6, le cas particulier est la règle : beaucoup de réseaux indiquent comme passerelle l'adresse link-local fe80::1. Comme netplan rattache toujours une route à une interface, via: "fe80::1" suffit dans le bloc de la carte concernée.

Neutraliser cloud-init

Si le répertoire contient un fichier 50-cloud-init.yaml, posez en plus un verrou, sinon votre travail sera écrasé au prochain démarrage :

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

netplan try : la commande qui ne vous enferme pas dehors

L'ordre est le suivant : vérifier, tester, valider. netplan generate traduit les fichiers YAML sans rien activer et signale immédiatement les erreurs de syntaxe. Le vrai test ne vient qu'ensuite.

netplan generate
netplan try --timeout 120
netplan apply

netplan try applique la nouvelle configuration et restaure automatiquement l'ancienne si vous n'appuyez pas sur la touche Entrée dans le délai imparti. La valeur par défaut est de 120 secondes. C'est exactement la raison pour laquelle on ne commence jamais par netplan apply sur un serveur distant : une faute de frappe dans l'adresse de la passerelle met fin à la session SSH, et sans filet de sécurité, l'affaire se termine devant la console ou par une réinstallation.

Ne vous fiez pas aveuglément à la restauration automatique. Des cas sont documentés où netplan try n'a pas rétabli la connexion après l'expiration du délai, en particulier lors de la modification du fichier généré par cloud-init. Après un retour arrière, vérifiez toujours que le fichier présent sur le disque est réellement revenu à son état antérieur.

Pour tout ce que netplan try ne couvre pas (et pour Debian avec ifupdown, où cette commande n'existe même pas), une seconde ceinture de sécurité a fait ses preuves : une tâche de secours qui restaure la sauvegarde si vous ne donnez pas signe de vie à temps.

nohup sh -c 'sleep 300; cp -a /root/netplan.bak/. /etc/netplan/; netplan apply' >/dev/null 2>&1 &

Notez le numéro de processus affiché en sortie. Si tout fonctionne, arrêtez la tâche avec kill. Si vous n'arrivez plus à vous connecter, elle se répare toute seule en cinq minutes. Travaillez en plus dans tmux ou screen, pour qu'une session SSH qui saute n'emporte pas votre éditeur en plein basculement.

Sur les serveurs root KVM, il reste en dernier recours la console de l'espace client, qui vous donne accès au système même sans réseau fonctionnel. Sur les machines dédiées, le chemin du retour est nettement plus laborieux, et la routine de précaution y compte double.

Debian 13 et 12 avec /etc/network/interfaces

Après une installation standard, c'est ifupdown qui pilote le réseau. La configuration est orientée ligne et prévoit des blocs séparés par famille d'adresses :

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1

iface ens3 inet6 static
    address 2001:db8:1234::2/64
    gateway 2001:db8:1234::1
    accept_ra 0

Le auto ens3 vaut pour les deux blocs, une seconde ligne auto est inutile. Si la passerelle se trouve en dehors du sous-réseau, la même idée que sous netplan s'applique, simplement formulée à la main :

iface ens3 inet static
    address 203.0.113.10/32
    post-up ip route add 192.0.2.1 dev ens3
    post-up ip route add default via 192.0.2.1
    pre-down ip route del default via 192.0.2.1

Le plus gros piège sous Debian n'est pas la syntaxe, mais l'activation. systemctl restart networking coupe brièvement la carte, et si la nouvelle configuration ne tient pas, la session est perdue. ifdown ens3 && ifup ens3 est encore plus délicat, car le ifup n'est jamais exécuté dès lors que la connexion se rompt déjà au moment du ifdown. Créez donc au préalable la tâche de secours décrite plus haut, puis lancez :

systemctl restart networking
systemctl status networking

Deux messages reviennent régulièrement ici. ifup: interface ens3 already configured signifie qu'ifupdown considère toujours la carte comme active, alors qu'elle ne l'est peut-être plus ; l'état est stocké dans /run/network/ifstate. Et Job for networking.service failed because the control process exited with error code n'est que l'enveloppe : la vraie raison se trouve dans journalctl -xeu networking, le plus souvent une route par défaut définie deux fois, avec RTNETLINK answers: File exists.

Le DNS sous ifupdown

La ligne évidente dns-nameservers 9.9.9.9 dans le fichier n'a d'effet que si un intermédiaire est installé pour la reporter dans /etc/resolv.conf, classiquement le paquet resolvconf. Sans cet intermédiaire, l'entrée reste sans conséquence, et cela ne se remarque qu'au moment où les noms ne se résolvent plus : Temporary failure in name resolution. Si vous ne voulez rien installer de plus, gérez /etc/resolv.conf directement et vérifiez avec ls -l /etc/resolv.conf si le fichier est un lien symbolique, donc géré par un autre service.

Faire tourner Debian avec systemd-networkd

Si vous utilisez de toute façon les outils systemd sur un serveur Debian, ou si vous gérez de nombreuses interfaces et tunnels, systemd-networkd vous apportera plus de cohérence. La bascule tient en trois étapes : créer la configuration, activer le nouveau service, mettre l'ancien hors service.

[Match]
Name=ens3

[Network]
Address=203.0.113.10/24
Address=2001:db8:1234::2/64
Gateway=203.0.113.1
Gateway=2001:db8:1234::1
DNS=9.9.9.9
DNS=2620:fe::fe
IPv6AcceptRA=no

Ce fichier a sa place dans /etc/systemd/network/10-ens3.network. Pour une passerelle située en dehors du sous-réseau, ajoutez un bloc de route dédié :

[Route]
Gateway=192.0.2.1
GatewayOnLink=yes

Vient ensuite la bascule, de préférence à nouveau avec une tâche de secours en réserve :

systemctl enable --now systemd-networkd
systemctl disable networking
networkctl status ens3

La sortie de networkctl status est le retour le plus honnête que ce sujet puisse offrir. Si elle indique State: routable (configured), le service a accepté le fichier et l'a appliqué. Si elle indique configuring ou degraded, il a essayé et échoué, peu importe que la commande de démarrage soit revenue sans erreur.

La partie DNS est indépendante sous Debian : systemd-networkd n'inscrit les serveurs de noms dans la résolution que si systemd-resolved tourne et que /etc/resolv.conf pointe vers son fichier.

apt-cache policy systemd-resolved

Cette requête dépend de la version, et elle trompe de façon très discrète. Un paquet systemd-resolved autonome n'existe qu'à partir de Debian 12 et d'Ubuntu 24.04, où la commande affiche donc un numéro de version. Sur Ubuntu 22.04 en revanche, le service est encore intégré au paquet systemd lui-même, et la commande s'exécute sans erreur mais n'affiche strictement rien. Une installation échoue alors avec Unable to locate package systemd-resolved. Une sortie vide ne signifie donc pas que le résolveur est absent, mais que le paquet n'existe pas dans cette version. Sur les systèmes plus anciens comme Debian 11, le comportement est identique. Sur ces versions, vérifiez plutôt ceci :

apt-cache policy systemd
systemctl status systemd-resolved

Le service s'active avec systemctl enable --now systemd-resolved, après quoi le lien symbolique habituel pointe vers /run/systemd/resolve/stub-resolv.conf. Si vous ne le souhaitez pas, laissez systemd-resolved de côté et inscrivez les serveurs de noms en dur dans /etc/resolv.conf. Ce qu'il ne faut surtout pas faire : les deux à moitié.

Ajouter des adresses IP supplémentaires

Les adresses supplémentaires ne sont pas un cas particulier, mais simplement une entrée de plus. Sous netplan, la liste s'allonge :

      addresses:
        - 203.0.113.10/24
        - 203.0.113.11/24
        - 203.0.113.12/24
        - "2001:db8:1234::2/64"
        - "2001:db8:1234::3/64"

Sous systemd-networkd, écrivez plusieurs lignes Address= les unes sous les autres. Sous ifupdown, complétez la définition existante au lieu d'en créer une deuxième :

iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    post-up ip addr add 203.0.113.11/24 dev ens3
    post-up ip addr add 203.0.113.12/24 dev ens3
    pre-down ip addr del 203.0.113.11/24 dev ens3
    pre-down ip addr del 203.0.113.12/24 dev ens3

L'ancienne notation avec ens3:0 fonctionne toujours, mais c'est un vestige de l'époque antérieure à l'outil ip. Elle ne crée pas de véritables périphériques supplémentaires, seulement des étiquettes, et elle sème dans les règles de pare-feu plus de confusion qu'elle n'apporte d'utilité.

Trois choses tournent mal de façon récurrente avec les adresses supplémentaires. Premièrement, l'adresse n'est pas attribuée côté serveur ; aucune configuration de système d'exploitation au monde ne fera fonctionner une IP qui n'est pas routée vers votre serveur, et c'est pourquoi un coup d'œil dans l'espace client est la première étape, pas la dernière. Deuxièmement, une seconde adresse issue du même réseau n'appelle pas une seconde route par défaut ; une deuxième entrée de passerelle par défaut vous vaudra RTNETLINK answers: File exists ou, pire, des chemins de réponse changeants. Troisièmement, en IPv6, le /64 complet est presque toujours routé vers le serveur : vous pouvez donc choisir librement dans cette plage, mais seule l'adresse indiquée par l'hébergeur est réellement nécessaire comme adresse d'interface configurée.

Pour savoir si une adresse supplémentaire porte réellement vers l'extérieur, testez-la en imposant l'adresse source :

ping -c 3 -I 203.0.113.11 1.1.1.1

Comment savoir que la configuration tient vraiment

Le fait qu'une commande se soit exécutée sans message d'erreur ne dit pas grand-chose de l'état du réseau. Ces cinq vérifications, en revanche, sont parlantes :

1. L'adresse est bien sur la bonne carte : ip -brief address show affiche exactement les adresses voulues et aucun reste de l'ancienne configuration.
2. Le chemin vers l'extérieur est correct, adresse source comprise : ip route get 1.1.1.1 indique la passerelle attendue et le src attendu.
3. IPv6 dispose de sa propre route par défaut : ip -6 route show default ne doit pas être vide, sinon tout passe silencieusement par IPv4.
4. La résolution de noms fonctionne indépendamment de la joignabilité : getent hosts deb.debian.org renvoie une adresse, pas seulement du silence.
5. Le seul vrai test est un redémarrage. C'est seulement après que vous saurez si la configuration vient du fichier ou encore de la mémoire.

Sous Ubuntu, netplan status --all fournit en plus un résumé compact, et networkctl status rend le même service sous systemd-networkd. En cas de doute, les deux montrent qu'une adresse figure certes dans le fichier, mais qu'elle n'a jamais été appliquée.

Les messages d'erreur, mot pour mot

Les quatre distributions en comparaison directe

Si vous mettez le pare-feu en service juste après la configuration réseau, veillez à ce que les règles pour la nouvelle adresse et celles pour IPv6 soient traitées séparément. Notre guide sur UFW sous Debian et Ubuntu explique comment procéder proprement, et sécuriser un serveur SSH montre comment protéger l'accès ensuite.

Résumé pour le prochain serveur

Relever les valeurs au lieu de les deviner, créer une sauvegarde, écrire la configuration, tester avec netplan try ou une tâche de secours maison, valider, redémarrer, et cocher la case seulement à ce moment-là. Qui respecte cet ordre perd cinq minutes dans le pire des cas. Qui l'abrège perd le serveur dans le pire des cas, jusqu'à ce que quelqu'un s'installe devant la console.