223 lines
11 KiB
Markdown
223 lines
11 KiB
Markdown
---
|
||
title: "IPAM Web : piloter dnsmasq avec une interface PHP et SQLite"
|
||
description: Si dnsmasq est l'un des serveurs DNS/DHCP les plus légers et robustes pour les réseaux locaux, sa configuration passe traditionnellement par l'édition de fichiers textes via SSH. Pour simplifier l'exploitation quotidienne — sans pour autant sortir l'artillerie lourde — nous avons développé une suite de scripts PHP permettant de gérer son infrastructure réseau depuis un navigateur.
|
||
tags: [dnsmasq, dns, dhcp, gui]
|
||
date: 2026-02-27 22:42
|
||
lastmod: 2026-02-27 23:56
|
||
type:
|
||
category:
|
||
- "[[Guide]]"
|
||
status: brouillon
|
||
---
|
||
|
||
# IPAM Web : piloter dnsmasq avec une interface PHP et SQLite
|
||
|
||
**IPAM** est l'acronyme de **Internet Protocol Address Management** (en français : Gestion des adresses IP). C'est une méthodologie, souvent accompagnée d'un logiciel qui permet de planifier, de suivre et de gérer l'espace d'adressage IP au sein d'un réseau. L'inventaire, la corrélation (DNS/DHCP) et la détection des conflits sont les 3 piliers qui définissent l'IPAM.
|
||
|
||
`dnsmasq` s’est imposé comme une référence pour fournir des services DNS et DHCP sur des réseaux locaux grâce à sa simplicité, sa faible empreinte et sa grande stabilité. En contrepartie, son administration reste historiquement centrée sur l’édition manuelle de fichiers de configuration, ce qui peut rapidement devenir chronophage et source d’erreurs lorsque l’infrastructure évolue.
|
||
|
||
L’interface **IPAM Web** répond à ce besoin : proposer une couche d’administration graphique légère, sans remettre en cause la philosophie minimaliste de `dnsmasq`. L’objectif n’est pas de remplacer l’outil, mais d’en améliorer l’ergonomie et la fiabilité opérationnelle.
|
||
|
||
Projet : [https://git.abonnel.fr/cedricAbonnel/dnsmasq-gui](https://git.abonnel.fr/cedricAbonnel/dnsmasq-gui)
|
||
|
||
---
|
||
|
||
## Une approche : conserver la simplicité, ajouter de l’intelligence
|
||
|
||
Le système transforme un serveur Linux standard en véritable solution d’**IP Address Management**.
|
||
La logique est volontairement simple :
|
||
|
||
- **SQLite** stocke l’état de référence (DNS, réservations, métadonnées).
|
||
|
||
- Des scripts PHP génèrent les fichiers de configuration.
|
||
|
||
- `dnsmasq` reste l’unique moteur d’exécution.
|
||
|
||
|
||
Cette séparation garantit que l’on conserve une infrastructure transparente, lisible et facilement réversible : les fichiers produits restent compatibles avec une exploitation classique en ligne de commande.
|
||
|
||
---
|
||
|
||
## Gestion DNS : un référentiel unique et cohérent
|
||
|
||
Le module `admin_dns.php` introduit une gestion centralisée de la résolution locale.
|
||
|
||
Plutôt que de disperser l’information dans différents fichiers, chaque enregistrement est stocké en base. Cette approche permet d’assurer la cohérence des données, de limiter les doublons et de tracer les modifications.
|
||
|
||
Le système génère ensuite automatiquement un fichier dédié contenant les directives `address=/nom/IP`, directement exploitables par `dnsmasq`.
|
||
La gestion de la résolution inverse est intégrée : les enregistrements PTR sont créés automatiquement afin de garantir une correspondance bidirectionnelle entre noms et adresses, indispensable pour le diagnostic réseau et certains usages applicatifs.
|
||
|
||
---
|
||
|
||
## DHCP : relier observation et configuration
|
||
|
||
Le module `admin_dhcp.php` se positionne comme un outil d’exploitation plutôt que de simple configuration.
|
||
|
||
Il analyse en continu le fichier `dhcp.leases` afin de refléter l’état réel du réseau : machines présentes, adresses attribuées, durées de bail.
|
||
À partir de cette observation, il devient possible de transformer un bail dynamique en réservation permanente en une seule action, ce qui simplifie fortement la stabilisation d’un parc.
|
||
|
||
Cette logique réduit les opérations manuelles et limite les risques d’erreur lors de la création de réservations, puisque les informations (MAC, IP, hostname) proviennent directement de la réalité du réseau.
|
||
|
||
---
|
||
|
||
## Visibilité réseau : confronter le modèle et le réel
|
||
|
||
Le module `free-ip.php` apporte une dimension d’audit souvent absente des outils légers.
|
||
|
||
Plutôt que de se baser uniquement sur les fichiers de configuration, il confronte :
|
||
|
||
- le **plan d’adressage théorique** (DNS et DHCP) ;
|
||
|
||
- l’**état observé** via un scan ARP.
|
||
|
||
|
||
Cette corrélation permet d’identifier immédiatement :
|
||
|
||
- les équipements présents mais non déclarés ;
|
||
|
||
- les incohérences de configuration ;
|
||
|
||
- les plages réellement disponibles.
|
||
|
||
|
||
On obtient ainsi une vision fiable du réseau, utile pour préparer des déploiements ou diagnostiquer des conflits d’adresses.
|
||
|
||
---
|
||
|
||
## Architecture et modules
|
||
|
||
La solution est structurée de manière modulaire afin de rester lisible et extensible.
|
||
|
||
| Script | Fonction | Rôle opérationnel |
|
||
| ---------------------- | -------------- | ----------------------------------------------------- |
|
||
| index.php | Point d’entrée | Accès aux modules et vue synthétique |
|
||
| admin_dns.php | Gestion DNS | Création et export des enregistrements |
|
||
| admin_dhcp.php | DHCP | Visualisation des baux et réservations |
|
||
| free-ip.php | Audit IP | Détection des adresses utilisées/libres |
|
||
| ddns.php | DNS dynamique | Mise à jour via API sécurisée (pas encore implémenté) |
|
||
| migrate_to_sqlite.php | Initialisation | Import des configurations existantes |
|
||
| configurer-dnsmask.php | Paramétrage | Gestion des options globales |
|
||
|
||
---
|
||
|
||
## Modèle de sécurité : contrôle fin des privilèges
|
||
|
||
L’interface doit pouvoir écrire dans `/etc/dnsmasq.d/` tout en évitant d’exposer des privilèges root complets au serveur web.
|
||
|
||
Le choix retenu repose sur l’utilisation ciblée de commandes autorisées via `sudo`, typiquement `sudo tee` pour l’écriture contrôlée de fichiers.
|
||
Cette approche limite la surface d’attaque tout en conservant une automatisation complète du cycle de configuration.
|
||
|
||
---
|
||
|
||
## Positionnement de la solution
|
||
|
||
IPAM Web se situe volontairement entre deux mondes :
|
||
|
||
- plus ergonomique qu’une administration purement en ligne de commande ;
|
||
|
||
- plus léger et transparent qu’une solution IPAM d’entreprise.
|
||
|
||
|
||
Il permet de conserver la maîtrise totale de l’infrastructure tout en améliorant la fiabilité opérationnelle, la visibilité réseau et la rapidité d’intervention.
|
||
|
||
---
|
||
|
||
## Pistes d’amélioration du projet
|
||
|
||
Le socle actuel remplit déjà efficacement son rôle d’interface d’exploitation. Les évolutions pertinentes consistent surtout à renforcer la fiabilité, la traçabilité et l’ouverture vers d’autres usages, tout en conservant la philosophie de simplicité.
|
||
|
||
### Fiabilité et robustesse
|
||
|
||
La robustesse du système peut être accrue par l'introduction d'un mécanisme de validation "pre-flight". En isolant les modifications dans des fichiers éphémères avant déploiement, nous pouvons soumettre chaque itération à un test de cohérence applicatif. Ce garde-fou empêche toute corruption de la configuration active.
|
||
|
||
Parallèlement, la mise en place d'un archivage horodaté des états offre une capacité de restauration critique en cas de régression. Cette architecture gagne à être complétée par une abstraction des fichiers de configuration via **Jinja2**, séparant ainsi la "source de vérité" (données) de sa représentation technique (forme).
|
||
|
||
### Journalisation et audit
|
||
|
||
L’ajout d’un journal applicatif structuré permettrait de tracer :
|
||
|
||
- qui a effectué une modification ;
|
||
|
||
- quand elle a été appliquée ;
|
||
|
||
- quelle était la valeur précédente.
|
||
|
||
|
||
Au-delà du diagnostic, cela transforme l’outil en véritable référentiel d’exploitation et facilite la conformité dans des environnements plus sensibles.
|
||
|
||
### Modélisation réseau plus riche
|
||
|
||
Aujourd’hui centré sur les adresses IP et les noms, le modèle pourrait intégrer des notions supplémentaires :
|
||
|
||
- segments ou VLAN ;
|
||
|
||
- plages IP avec statut (réservé, dynamique, infrastructure, invités) ;
|
||
|
||
- métadonnées d’équipement (type, localisation, propriétaire).
|
||
|
||
|
||
Cette structuration rendrait la recherche et la visualisation beaucoup plus pertinentes, en rapprochant l’outil d’un IPAM complet tout en restant léger.
|
||
|
||
### Visualisation et compréhension du réseau
|
||
|
||
Une représentation graphique simple (cartographie logique ou vue par plage IP) améliorerait la compréhension globale du réseau.
|
||
Sans aller vers une cartographie automatique complexe, une visualisation basée sur les données connues (réservations, baux, détection ARP) suffirait déjà à offrir une lecture immédiate de l’occupation.
|
||
|
||
### API et automatisation
|
||
|
||
L’exposition d’une API REST documentée permettrait d’intégrer l’outil dans des workflows existants :
|
||
|
||
- scripts d’installation automatisés ;
|
||
|
||
- intégration avec un inventaire ou un outil de provisioning ;
|
||
|
||
- mise à jour dynamique depuis des équipements.
|
||
|
||
|
||
Le module DDNS existant constitue déjà une base naturelle pour cette ouverture mais n'est pas encore exploité. Il faudrait qu'il alimente une table `machines` dans notre base SQLite. Ainsi, notre tableau de bord `index.php` pourra afficher une liste complète de notre parc avec :
|
||
|
||
- Le nom de la machine.
|
||
|
||
- Sa dernière IP connue.
|
||
|
||
- Son système d'exploitation (extrait de `hostnamectl`).
|
||
|
||
- La date de sa dernière "vue" (Last Seen).
|
||
|
||
### Sécurité applicative
|
||
|
||
Plusieurs axes peuvent renforcer la posture de sécurité :
|
||
|
||
- authentification forte (OIDC ou SSO) ;
|
||
|
||
- gestion de rôles (lecture seule, exploitation, administration) ;
|
||
|
||
- protection CSRF et durcissement des entrées utilisateur.
|
||
|
||
|
||
Ces éléments deviennent essentiels dès que l’outil dépasse un usage strictement personnel.
|
||
|
||
### Expérience d’exploitation
|
||
|
||
Enfin, quelques améliorations ergonomiques ont un impact immédiat :
|
||
|
||
- recherche globale (IP, nom, MAC) ;
|
||
|
||
- actions rapides contextuelles ;
|
||
|
||
- indicateurs d’état (conflit IP, doublon DNS, incohérence PTR).
|
||
|
||
|
||
Ces fonctions réduisent le temps d’analyse et rapprochent l’outil d’une console d’exploitation quotidienne.
|
||
|
||
## Gestion de l'Idempotence
|
||
|
||
Le script `migrate_to_sqlite.php` vide la table (`DELETE FROM dns_records`) à chaque lancement. C'est risqué.
|
||
|
||
**Amélioration :** Adoptez une logique de synchronisation :
|
||
|
||
1. Lire le fichier.
|
||
|
||
2. Comparer chaque ligne avec la base SQLite.
|
||
|
||
3. `INSERT` si nouveau, `UPDATE` si différent, et ne rien faire si identique. Cela évite de perdre des données si le script s'arrête en plein milieu. |