J'ai eu une idée de système à mettre en place sur un réseau local, pour gérer les adresses IP, et surveiller un peu tout ça. Je sais c'est long à lire C'est une bonne idée ou je vais dans le mur ? Merci pour vos futurs avis
 
Introduction
 
Ce projet a pour but de simplifier la gestion des adresses IP sur un réseau, sur lequel les adresses IP ne sont pas forcément fixes. Le réseau est constitué d'une trentaine de postes utilisateurs connectés soit en ethernet, soit via wifi. Un autre aspect important est qu'il faut sécuriser la connexion internet : savoir quel utilisateur accède quand au web, mais que le fonctionnement soit transparent pour lui. La connexion se fait par l'intermédiaire d'une passerelle sous GNU/Linux, associé à un proxy Squid, configuré en mode transparent.
 
Le serveur de gestion aura plusieurs rôles :
 
• Proposer un front-end à dhcpd, permettant de générer un fichier de configuration, à partir d'un modèle. Ce fichier modèle sera complété avec des réservations. Les adresses mac et les ip correspondantes seront stockées dans une base de données mysql.
• Générer un script iptables, afin d'autoriser uniquement certaines combinaisons adresses ip/adresses mac sur la passerelle.
• Permettre à l'administrateur de visualiser rapidement et simplement quels postes sont connectés à tout moment, et d'avoir un minimum d'historiques sur les connexions des postes au réseau local.
 
Cet ensemble utilisera un système GNU/Linux, associé à plusieurs outils : Apache/Php pour l'interface de gestion et la génération des scripts, Perl pour la lecture de fichiers de logs, et Mysql pour le stockage des informations.
 
Détail des différents modules :
Dhcpd
 
Le module de gestion de dhcpd va avoir plusieurs rôles : le premier va être de créer un fichier de configuration valide pour dhcpd, en y ajoutant une réservation par poste client référencé sur le serveur. Ce fichier doit être re-généré et appliqué une fois la saisie d'un nouveau poste faite.
L'interface graphique passera par des pages web, et permettra de saisir de nouveaux clients, de définir les créneaux horaires, et de recréer le fichier de configuration puis relancer le service DHCP.
 
Iptables
 
La passerelle Linux doit permettre l'accès à internet uniquement aux clients référencés. Deux plages horaires sont définies : une plage journée, et une plage nuit. Tous les clients connus peuvent se connecter dans la journée, alors que seules certaines machines ont accès à internet durant la nuit (typiquement des serveurs). La passerelle Linux va télécharger sur le serveur un script iptables, qui en plus des éléments par défaut, va autoriser uniquement les combinaisons adresses mac/ip autorisées par rapport à la période donnée de la journée. Le script doit être rafraîchi sur la passerelle assez souvent, de manière à autoriser rapidement les nouveaux clients enregistrés. Le délai entre les mises à jour sera de dix minutes dans la journée, et d'une heure pendant la nuit.
 
Monitoring
 
Ce module doit permettre à l'administrateur du réseau de voir à un moment donné quels sont les postes clients connectés, et à quel utilisateur le poste correspond. Le poste doit être détecté comme connecté même si un firewall est installé sur la machine, et empêche la réponse à une commande ping. A cela doivent d'ajouter certaines options d'historique de la machine : premières et dernières date et heure de connexion, ainsi qu'un historique des baux DHCP pour la machine.
 
Aspect technique
Dhcpd
 
Un modèle de base de fichier de configuration du daemon dhcpd est enregistré, soit dans un fichier, soit dans la base de données. En plus des paramètres de base (range d'adresses ip), le modèle doit comporter plusieurs informations nécessaires à la connexion des clients : l'adresse IP de la passerelle Linux comme route par défaut, et les adresses du ou des serveurs DNS. Cette valeur pourra soit pointer sur une adresse interne, soit un serveur externe, typiquement celui du FAI. La page suivante présente un modèle de fichier de configuration : http://www.tldp.org/HOWTO/DHCP/x369.html#AEN403
 
A la suite de ce modèle seront ajoutés les différentes réservations pour les clients enregistrés. Ces réservations se présentent de la façon suivante :
 
 

 
 Autant de blocs que de clients seront ajoutés au fichier modèle.
 
Lorsqu'un nouveau fichier sera généré (suite à une modification ou un ajout de client), le fichier destination sur le serveur ( /etc/dhcpd.conf ) sera écrasé par une nouvelle version. Pour pallier à toute erreur, le fichier précédent devra être sauvegardé avant d'être écrasé.
Iptables
 
Un modèle de tables Iptables va être enregistré sur la passerelle Linux. Celui-ci doit simplement contenir de quoi avoir une connexion à internet, et n'autoriser comme seule machine sur le réseau local le serveur de supervision du réseau. Toutes les dix minutes pendant la journée (et toutes les heures pendant la nuit), la passerelle va aller appeler un script php (via http et wget) sur le serveur de supervision. Ce script va contenir les lignes iptables à entrer sur la passerelle pour autoriser l'accès uniquement aux machines qui ont le droit de se connecter au moment présent de la journée.
 
Le script php sur le serveur de supervision utilisera la base de données des adresses MAC et IP des clients pour générer les lignes. Le délai de dix minutes permettra aux nouveaux postes enregistrés de se connecter rapidement à Internet.
 
Si jamais le serveur de supervision est inaccessible et que la passerelle ne peut pas télécharger le script Iptables, la version actuelle du script devra être conservée.
Monitoring
 
Partie visible de l'application, il s'agira d'une page web, représentant un tableau avec plusieurs informations :
 
• L'adresse IP
• L'adresse MAC qui correspond à la réservation pour cette IP
• Le nom du propriétaire de la machine associée
• Le statut DHCP : poste connecté ou non, signalé par la couleur de la case, le dernier bail DHCP accordé, ainsi que deux liens ouvrant des popups permettant d'afficher la liste de tous les baux DHCP, l'heure correspondante, et un outil pour tester la connexion vers la machine.
 
Le script php ne doit pas se servir des données présentes dans la base de données pour les différentes adresses : il doit parcourir tout le sous réseau (soit 253 adresses pour un sous réseau en 192.168.0.x / 24), et pour chacune voir s'il existe une entrée dans la base de données. Si les données existent, la ligne correspondante est affichée, avec la case Statut DHCP ayant un fond coloré selon la connexion ou non de la machine. Dans le cas contraire, la ligne est signalée avec un fond gris, et aucune information.
 
Pour tester la connexion de la machine, la commande ping n'est pas fiable, étant donné qu'il peut y avoir un firewall bloquant la réponse installé sur la machine. Dans ce cas là, il est souhaitable d'utiliser la commande arping ( http://www.habets.pp.se/synscan/pr [...] rog=arping ) qui permet de passer outre cette contrainte. Lors de la génération de la page, il faut voir s'il est possible de lancer simultanément la commande arping vers toutes les adresses MAC, pour ne pas attendre le timeout de la commande et se trouver bloquer par le temps maximal d'exécution du script PHP sur le serveur.
Surveillance du fichier de log du dhcp
 
Afin de constituer l'historique des baux DHCP, le fichier de log du DHCP doit être lu. Le temps de passage entre deux vérifications doit être inférieur à la durée de chaque bail, de manière à pouvoir voir tous les baux. Si un nouveau bail non enregistré est détecté, une entrée est ajoutée à la base de données. Le script de vérification sera écrit en langage Perl, et appelé grâce à cron.

bonjour,
votre sujet est très intéressant j'aimerai bien savoir les nouvelles de ce sujet car j'ai une idée qui ressemble un petit à votre idée
merci de me répondre

Bonjour
je suis très interessée par votre application, en fait j'ai un projet qui converge en ce sens!! ben je souhaite que vous me donniez un coup de main    il sera vraiment le bien venu
merci de me repondre dans les plus bref delai
cordialment

Pas de souci ! Un petit café pendant qu'on vous prépare tout cela ?