Cours Ubuntu 26.04 / Configurer une IP fixe et le DNS avec un plan de récupération

Pour fixer une adresse IP sur Ubuntu sans perdre l’accès, préparez la console et la sauvegarde, identifiez le fichier Netplan réellement utilisé, puis testez la nouvelle configuration avec un délai de confirmation. Vérifiez séparément adresse, routes, DNS et connexion cliente ; une syntaxe correcte ne prouve pas que le réseau fonctionne.

Vérifier la topologie et le propriétaire des paramètres

Ce laboratoire utilise deux interfaces filaires gérées par systemd-networkd. La première conserve l’accès Internet par NAT, traduction d’adresses fournie par l’hyperviseur, avec ses paramètres obtenus par DHCP, le protocole d’attribution automatique. La seconde appartient au réseau privé entre hôte et VM créé dans la préparation de la machine virtuelle Ubuntu.

/24 indique le préfixe du sous-réseau. Ces adresses sont un plan de laboratoire, pas des valeurs à appliquer sur un réseau existant. Contrôlez l’absence de conflit avec les autres appareils et le DHCP de l’hyperviseur ; un ping sans réponse ne prouve pas qu’une adresse est libre.

ip -br link
ip -br address
ip route
ip -6 route
sudo netplan get

Sur ce laboratoire où systemd-resolved est actif, relevez également resolvectl status. Conservez les noms réels des interfaces, leurs adresses MAC, le moteur et les routes actuelles, conformément à la lecture de Netplan et de ses gestionnaires. Le YAML fusionné peut contenir des secrets ; gardez sa copie dans un emplacement d’administration protégé.

Dans l’exemple, enp0s3 correspond au NAT et enp0s8 au réseau privé. Vérifiez cette correspondance avec les adresses MAC de la VM avant toute édition. Si NetworkManager ou le fournisseur cloud gère réellement l’interface, utilisez son parcours de configuration ; ne changez pas de moteur pour copier cet exemple.

Préparer la console et sauvegarder la source avant modification

Connectez-vous d’abord à la console de la VM et vérifiez que vous disposez du compte et de sudo. Conservez l’ancienne session SSH lorsqu’elle existe, mais prévoyez une seconde session pour les tests : une connexion déjà établie ne valide pas un nouvel accès.

(
set -eu
backup=$(sudo mktemp -d /root/netplan-backup.XXXXXX)
sudo cp -a /etc/netplan "$backup/"
printf 'Sauvegarde : %s\n' "$backup"
)

Notez le chemin uniquement si le bloc se termine avec succès. Il sauvegarde /etc/netplan ; si la configuration persistante à modifier provient d’un autre emplacement ou d’un outil externe, sauvegardez aussi cette source par sa procédure. Le sous-shell évite de laisser set -eu activé dans votre terminal.

Repérez exactement le fichier et la définition de chaque interface. Consultez les autres YAML avant d’ajouter un fichier : les définitions sont fusionnées et certaines listes s’additionnent. Un fichier tardif ne garantit pas l’effacement des anciennes adresses. Gardez un relevé des fichiers ajoutés, modifiés et de leurs permissions.

Définir l’adresse privée en conservant la route et le DNS du NAT

Ouvrez le fichier source confirmé avec sudoedit, puis adaptez le contenu aux interfaces réelles. Voici un exemple minimal complet pour le nouveau laboratoire ; il ne doit pas remplacer intégralement une configuration qui contient d’autres interfaces, du routage, des ponts ou des VLAN :

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      dhcp4: false
      addresses:
        - 192.168.56.20/24

Utilisez des espaces pour l’indentation et conservez les niveaux montrés. enp0s3 garde les paramètres DHCP, dont la route et le DNS fournis dans ce laboratoire. enp0s8 reçoit seulement une adresse IPv4 fixe. N’ajoutez pas 192.168.56.1 comme passerelle ou DNS : la présence de l’hôte à cette adresse ne lui confère pas ces services.

Le trafic entre .20 et .10 reste directement sur ce réseau privé ; il n’a pas besoin de route par défaut ni de transfert de port NAT. Une seconde route par défaut mal choisie pourrait détourner le trafic Internet. L’utilisation des adresses statiques avec Netplan distingue les besoins d’adresse et de passerelle selon la topologie.

Vérifiez propriétaire et permissions du fichier. Sur un fichier administré localement, confirmez le chemin réel avant d’y appliquer sudo chmod 600 : cette restriction doit porter sur le YAML visé, pas sur tout un répertoire ou des fichiers du fournisseur. Conservez les politiques IPv6 existantes, notamment DHCPv6 et annonces de routeur ; cet exemple IPv4 ne demande pas leur suppression.

Choisir les serveurs DNS sans créer de fausse passerelle

Dans la configuration ci-dessus, gardez le DNS reçu sur l’interface NAT. Consultez resolvectl status pour confirmer le serveur réellement retenu. Une adresse locale telle que 127.0.0.53 dans /etc/resolv.conf peut désigner le relais local de resolved, plutôt que le serveur DNS amont.

Si votre réseau impose un DNS précis, obtenez ses adresses et ses domaines auprès de l’administrateur, puis définissez nameservers et sa liste addresses dans la définition de l’interface qui doit le joindre. Les valeurs sont celles d’un vrai résolveur accessible, pas l’adresse de l’hôte choisie au hasard. La configuration DNS d’Ubuntu décrit aussi les domaines de recherche.

Avec networkd, ajouter un DNS statique alors que DHCP fournit encore ses propres DNS peut laisser ces derniers prioritaires. dhcp4-overrides: use-dns: false permet de refuser ceux reçus en DHCP lorsque cette politique est réellement souhaitée. Vérifiez aussi les apports DHCPv6 et des annonces IPv6 au lieu de croire que ce seul réglage contrôle tous les DNS. Les options DHCP et DNS de Netplan précisent leur portée et les contraintes quand DHCPv4 et DHCPv6 sont tous deux activés.

Pour le premier essai, ne changez pas simultanément le DNS du NAT si votre objectif est seulement de fixer l’adresse interne. Vous pourrez ainsi attribuer un échec à un changement précis et revenir à l’état précédent.

Générer puis essayer la configuration avec confirmation

Depuis la console préparée, lancez la génération puis l’essai uniquement si elle réussit :

sudo netplan generate && sudo netplan try --timeout 120

netplan generate prépare les fichiers des moteurs et détecte des erreurs de configuration ; en session normale, cette génération n’applique pas le nouveau réseau. Elle écrit néanmoins des fichiers générés, et ce n’est pas un simple test abstrait de YAML. Si elle échoue, corrigez le fichier et la ligne signalés avant de recommencer.

netplan try applique réellement les paramètres et attend ici jusqu’à 120 secondes. Pendant cette attente, utilisez un autre terminal pour vérifier l’adresse, les routes, le DNS et la connexion cliente. Confirmez seulement après des résultats corrects ; sinon, laissez l’essai revenir en arrière ou rejetez-le selon son invite.

Le délai n’est pas une garantie absolue de récupération, notamment avec certains périphériques virtuels. Après annulation ou expiration, vérifiez l’état réseau et le YAML sur disque depuis la console. Ne redémarrez pas à l’aveugle en supposant que tout a été restauré.

Tester depuis le serveur et le client sur le bon chemin

Configurez séparément la seconde VM du laboratoire, avec ses noms d’interfaces vérifiés et 192.168.56.10/24 sur son interface privée. Préservez son NAT en DHCP et appliquez la même préparation de sauvegarde et d’essai. Ne recopiez pas l’adresse .20 du serveur sur le client.

Sur le serveur, les contrôles suivants ciblent le client .10 :

ip -br address
ip route
ip route get 192.168.56.10
resolvectl status
resolvectl query ubuntu.com

route get doit choisir l’interface privée pour .10, avec l’adresse source .20 dans ce plan. La route Internet par défaut doit continuer à emprunter le NAT. Le résultat DNS doit fournir une réponse cohérente via un résolveur attendu ; cette requête n’établit pas à elle seule qu’un service web est accessible.

Depuis le client, inversez la destination pour examiner le chemin vers le serveur :

ip route get 192.168.56.20
ping -c 3 192.168.56.20

Un pare-feu peut bloquer ICMP, le protocole utilisé par ping. Testez aussi une nouvelle connexion au service prévu, par exemple SSH seulement s’il est déjà installé, en écoute et autorisé. Ne désactivez pas le pare-feu ni le contrôle d’identité SSH pour faire réussir un test. Une ancienne session ouverte ne remplace pas cette nouvelle connexion.

Récupérer la configuration connue puis vérifier la persistance

1. En cas de perte d’accès, utilisez la console. Relevez les adresses, routes et messages de l’essai avant d’ajouter de nouveaux paramètres.
2. Comparez le fichier modifié à sa copie dans le répertoire de sauvegarde noté. Rétablissez uniquement ce fichier ou les valeurs de l’intervention ; pour un fichier nouvellement créé, retirez seulement cet ajout après vérification de son contenu.
3. Relisez netplan get pour contrôler la fusion. Une ancienne définition restée ailleurs peut maintenir le paramètre indésirable.
4. Exécutez generate sur la configuration restaurée, puis essayez-la par la console et vérifiez le retour des anciennes adresses, routes et DNS.

Ne remplacez pas tout /etc/netplan et ne supprimez pas les autres YAML pour accélérer la récupération. Si un gestionnaire externe réécrit la configuration, corrigez la source par sa procédure au lieu de multiplier les surcharges locales.

Quand les tests en direct sont bons et que le YAML sur disque est celui attendu, planifiez un redémarrage. Après celui-ci, répétez les relevés de routes, la résolution de noms et les nouvelles connexions clientes. Un succès avant redémarrage peut encore dépendre d’un état temporaire ; l’accès console doit rester disponible jusqu’à la fin de cette vérification.