La première machine du projet ne rend aucun service pédagogique : elle route, traduit les adresses, résout les noms et distribue les adresses. Tout le reste en dépend — et c'est pour cela qu'on la construit d'abord, et qu'on la valide entièrement avant de continuer.
Deux interfaces, un script de passerelle idempotent, et une zone DNS interne validée avant tout rechargement.
Deux interfaces, deux mondes
La machine reçoit deux cartes réseau :
- côté extérieur — en DHCP, elle reçoit automatiquement route par défaut et serveurs de noms. C'est la sortie vers Internet ;
- côté réseau pédagogique — en adresse fixe, sans passerelle définie.
Cette absence de passerelle sur l'interface interne est volontaire et mérite l'explication : une machine ne peut avoir qu'une seule route par défaut. La définir des deux côtés produit un comportement erratique — du trafic qui part parfois du mauvais côté, et des diagnostics impossibles.
La configuration passe par netplan, avec un réflexe à prendre : valider la syntaxe avant d'appliquer. Sur une machine distante, une faute d'indentation appliquée directement, c'est une console de secours à ouvrir.
Router et traduire : le script de passerelle
Deux opérations transforment la machine en routeur : activer le transfert de paquets dans le noyau, et mettre en place la traduction d'adresses pour que le réseau interne, adressé en privé, puisse sortir.
Le choix de nftables plutôt qu'iptables se justifie simplement : c'est le standard de la distribution, la syntaxe est lisible, et les règles s'appliquent de façon atomique. Trois propriétés du script méritent d'être soulignées :
- les paramètres sont centralisés en tête — noms d'interfaces et plage du réseau. Une évolution se fait en une ligne, pas en cherchant les occurrences ;
- la table est détruite puis recréée à chaque exécution : le script est idempotent, on peut le relancer sans effet cumulatif et sans dépendre de l'état antérieur ;
- la politique de transit est « tout rejeter », avec seulement deux autorisations : le trafic du réseau interne vers l'extérieur, et les réponses aux connexions déjà établies. Rien ne traverse la passerelle par accident.
Le script est enfermé dans un service systemd de type oneshot, ce qui garantit sa réapplication à chaque démarrage. Sans cela, un redémarrage suffit à faire perdre le réseau à toute la salle.
Le DNS interne : la brique qu'on sous-estime
La passerelle héberge un serveur de noms qui remplit deux rôles :
- autoritaire sur la zone interne du projet — c'est lui qui sait où sont l'annuaire, le serveur de fichiers, le management ;
- relais pour tout le reste, transmis à un serveur amont.
Deux réglages conditionnent la sécurité de l'ensemble : la récursion limitée au réseau interne — un résolveur ouvert à tous est une arme d'amplification pour attaques par déni de service —, et l'écoute restreinte aux interfaces concernées.
Côté exploitation, deux réflexes : incrémenter le numéro de série de la zone à chaque modification, et vérifier la configuration et la zone avant de recharger. Un fichier modifié sans incrément est un fichier qui semble ne rien changer — c'est l'erreur la plus fréquente du domaine.
Pourquoi tant d'attention à cette brique ? Parce que la suite en dépend entièrement : le certificat de l'annuaire sera émis pour son nom DNS, les clients le contacteront par ce nom, et le serveur de fichiers vérifiera ce nom. Un DNS approximatif produit des erreurs de certificat qu'on cherchera ailleurs pendant des heures.
Le DHCP : au service du déploiement
Le service d'attribution d'adresses ne sert pas seulement au confort. Il fournit aux postes la passerelle, le serveur de noms interne et le nom de domaine — trois informations sans lesquelles un poste fraîchement installé ne trouve ni l'annuaire ni le serveur de fichiers.
Il prépare surtout l'industrialisation : c'est lui qui orientera plus tard les postes vers le serveur de démarrage réseau. Un déploiement automatisé sans DHCP maîtrisé n'existe pas.
Trois règles d'hygiène : un seul serveur d'adresses sur le réseau — deux produisent des conflits difficiles à diagnostiquer —, une écoute limitée à l'interface interne, et une plage dynamique séparée des adresses fixes des serveurs.
La validation, avant de passer à la suite
Trois contrôles, et aucun n'est facultatif : depuis un poste du réseau interne, obtenir une adresse automatiquement, sortir sur Internet, et résoudre un nom interne. Tant que ces trois points ne sont pas acquis, installer un annuaire est une perte de temps : ses erreurs seront illisibles.
La série EduLibre
De la décision à l'industrialisation du parc :
- 1. Pourquoi un socle libre pour un parc informatique
- 2. L'architecture globale, brique par brique
- 3. La passerelle : routage, NAT, DNS et DHCP — vous y êtes
- 4. L'annuaire LDAP, brique de voûte
- 5. NFS : profils, classes et quotas
- 6. PXE et Ansible : le parc en zero-touch