Préparer un entretien : SRE/DevOps Engineer

Le fichier rendu est le suivant :

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.50.10/24
      routes:
        - to: default
          via: 192.168.50.1
          metric: 100
      nameservers:
        addresses:
          - 192.168.50.53

Comme dhcp4 vaut false, aucune adresse IPv4 n'est demandée par DHCP : l'adresse, la route par défaut et le résolveur DNS sont tous déclarés explicitement, sans mélange avec une configuration DHCP qui rendrait la route ambiguë. Ce fichier se dépose dans /etc/netplan/ sous une extension .yaml. Il s'agit d'un exercice de rédaction sur une VM isolée où réseau, passerelle et résolveur sont supposés disponibles pour l'exemple ; écrire le fichier ne modifie pas l'interface réseau tant qu'aucune commande d'application n'est lancée.

Le bloc YAML complet est rendu tel quel, dhcp4 est à false sans mélange avec une route DHCP ambiguë, addresses/routes/nameservers utilisent les valeurs fictives demandées, et aucune application réelle n'est prétendue.

Sous l'hypothèse posée qu'il n'existe ni autre route, ni autre résolveur configuré, ni autre interface active sur la machine, deux problèmes distincts se cumulent. D'une part, sans route par défaut déclarée sous routes avec to: default et via l'adresse de la passerelle, aucun chemin n'existe vers l'extérieur du sous-réseau : les paquets pour des destinations hors 192.168.50.0/24 sont abandonnés, ce qui bloque les connexions sortantes. D'autre part, sans nameservers.addresses sur cette interface et sans résolveur système par ailleurs, aucun serveur DNS n'est disponible pour cette machine, donc les noms ne peuvent pas être résolus même si une adresse IP directe répond au ping. Le correctif ajoute une entrée routes avec to: default et via: 192.168.50.1, puis nameservers avec addresses: [192.168.50.53] :

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.50.10/24
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses:
          - 192.168.50.53

Ce correctif est rédigé pour l'exercice ; aucune application sur un réseau réel n'est promise.

L'hypothèse d'absence d'autres routes, résolveurs et interfaces actives est explicitée, l'échec de connexion sortante et l'échec de résolution DNS sont diagnostiqués séparément, et le correctif YAML ajoute précisément routes et nameservers sans promesse d'application réelle.

netplan try applique la configuration puis attend une action de l'utilisateur, par défaut pendant 120 secondes réglables avec --timeout. Confirmer et annuler sont deux actions distinctes : une confirmation interactive (touche Entrée) ou l'envoi du signal SIGUSR1 valide la configuration testée de façon permanente, tandis que l'envoi du signal SIGINT annule l'essai et rejette la configuration testée avant même la fin du délai. Si aucune confirmation n'arrive dans le délai imparti, l'essai est considéré non confirmé et l'outil tente de restaurer automatiquement la configuration précédente. La documentation officielle signale cependant des cas connus où cette restauration automatique peut échouer partiellement ; elle n'est donc pas présentée comme une garantie absolue. Sur une VM d'entraînement, il faut donc vérifier à la fois l'état réel de l'interface et le contenu des fichiers Netplan sur disque après le délai, plutôt que de supposer un retour automatique parfait, sans jamais appliquer ce test sur un réseau réel.

Le délai par défaut de 120 secondes est correct, SIGUSR1 est bien associé à la confirmation et SIGINT à l'annulation/rejet, la vérification porte à la fois sur l'état réel et sur les fichiers disque, aucun rollback n'est présenté comme garanti, et aucune manipulation du réseau réel n'est suggérée.