Interfaces, routes et résolution locale

Prérequis : Réseaux ch. 1 et 4 (modèles, routage).

Pourquoi

Côté hôte, le réseau se configure (systemd-networkd/NetworkManager/netplan) et se dépanne (ip, pas ifconfig fossilisé). Savoir où vit la conf évite le « ça marchait jusqu'au reboot ».

Concepts

• ip remplace tout : ip addr (adresses), ip route (routes), ip link (état MTU/mac), ip neigh (table ARP : qui est qui en local). ifconfig/route/arp = fossiles à oublier.
• Où vit la conf : Debian = /etc/network/interfaces(d) ou systemd-networkd ; Ubuntu = netplan (YAML → backend). Après modif : appliquer (netplan apply, networkctl reload) + tester + persister (sinon reboot = surprise).
• Résolution locale : /etc/hosts (prioritaire !), /etc/resolv.conf (ou résolu par systemd-resolved : resolvectl status pour voir le VRAI serveur utilisé), /etc/nsswitch.conf (l'ordre : files puis dns ?).
• Prévisibilité : noms d'interfaces persistants (enp0s3, pas eth0 qui change !). Règles udev/systemd pour les cas spéciaux.

Exemple : le trio de vérité

ip -br addr && ip route | head -3 && resolvectl status | grep -A2 "Current DNS"
# IP ? route par défaut ? VRAI DNS ? — 10 secondes, zéro hypothèse

Cas réel

« DNS cassé » après update : en fait resolv.conf écrasé (lien symbolique géré !) + systemd-resolved avec un DNS mort en cache. resolvectl l'a montré en 30 s ; 2 h perdues avant à tester dig qui utilisait… un autre résolveur que l'app.

Pièges

• Éditer resolv.conf à la main (lien géré) : écrasé au reboot/reconnect. Configurer la source (DHCP, netplan, resolved).
• eth0 en dur dans les scripts : noms persistants modernes (enp0s3) — ou prédictibles via .link.
• Conf appliquée mais non persistée : marche jusqu'au reboot. Toujours les deux (appliquer + fichier).

À retenir

ip (pas ifconfig), conf persistée + appliquée, resolvectl pour le vrai DNS, noms persistants.