DNS, DHCP, VPN : administration des services réseau en production

Pendant le stage, j'ai administré - sous encadrement - trois services centraux du réseau : le DNS (résolution de noms), le DHCP (attribution d'adresses) et le VPN (accès distants). Opérations réalisées : création et modification d'enregistrements, gestion de plages et de réservations, ouverture d'accès.

DNS : des modifications qui engagent

Une modification DNS se propage et se met en cache : une erreur publiée peut rendre un service injoignable pendant toute la durée du TTL. Méthode adoptée : préparer chaque modification, abaisser le TTL avant un changement sensible, vérifier la résolution immédiatement après application.

# vérifier la résolution après une modification de zone
dig app.exemple.lan @serveur-dns +short

# suivre un bail DHCP attribué à un poste
journalctl -u isc-dhcp-server | grep "DHCPACK"

Supervision : détecter avant les utilisateurs

Second volet de la mission : la surveillance de ces services (disponibilité, espace disque, certificats). Avec une supervision en place, les incidents sont détectés par des alertes plutôt que signalés par les utilisateurs, et les interventions deviennent planifiables. C'est un changement de fonctionnement mesurable, pas un confort.

L'outil retenu est Grafana. Il faut être précis sur son rôle : Grafana ne collecte rien lui-même, il lit des métriques déjà remontées par les machines et les met en forme. C'est la couche visible d'une chaîne qui commence sur chaque hôte - ce point m'a demandé un moment pour être clair, parce qu'on parle couramment de « mettre en place Grafana » comme si l'outil faisait tout le travail.

Les indicateurs suivis se sont stabilisés autour de quatre familles :

• Disponibilité des services critiques : si le DNS tombe, tout ce qui en dépend devient injoignable, et le symptôme observé n'a rien à voir avec la cause.
• Espace disque par machine : la panne la plus banale, la plus évitable, et celle qui casse le plus de choses d'un coup.
• Expiration des certificats : une échéance connue des mois à l'avance ne devrait jamais provoquer d'incident.
• Charge des machines virtuelles côté hyperviseur : pour distinguer un service lent d'un hôte saturé.

L'alerte la plus fréquente pendant le stage a été le franchissement de seuil sur l'espace disque. Le cas typique : une partition qui se remplit non pas à cause des données du service, mais des journaux qu'il produit. La réaction immédiate - purger - règle le symptôme pour quelques jours. Le vrai correctif est ailleurs : configurer la rotation des journaux pour que le problème ne revienne pas. C'est la première fois que j'ai vu concrètement la différence entre traiter un incident et le résoudre.

La leçon qui m'a le plus servi ensuite porte sur les seuils. Une alerte trop sensible se déclenche en permanence, on prend l'habitude de l'ignorer, et le jour où elle signale un vrai problème elle est devenue invisible. Une alerte doit correspondre à une action à mener : si personne ne fait rien quand elle arrive, elle n'aurait pas dû être écrite.

Connaissances mobilisées

• Cours de réseau Ynov (adressage, protocoles) : indispensables pour comprendre ce que je manipulais.
• Linux en ligne de commande : tout se fait en SSH, à distance, sans interface graphique.
• Rigueur documentaire : chaque intervention consignée - un réflexe directement réutilisable en entreprise.

Ce volet réseau complète directement mon profil de développeur : connaître l'environnement d'exécution permet de concevoir de meilleures applications. La suite - conteneurisation et CI/CD - fait l'objet de l'article suivant.