Infrastructure GSB
Projet mené en binôme sur Hyper-V — je gérais la partie réseau, infrastructure, sécurité et Active Directory. L'objectif : déployer une infrastructure complète d'entreprise fictive avec LAN, DMZ, services internes et supervision, en partant de zéro sur des VMs. GSB (Galaxy Swiss Bourdin) est une entreprise fictive du BTS SIO dont l'infrastructure doit respecter des contraintes réalistes de cloisonnement, haute disponibilité et gestion de parc.
Contexte et objectifs
Le projet GSB est le projet fil rouge du BTS SIO — il s'étend sur toute l'année et simule le déploiement d'une infrastructure d'entreprise réelle. Le cahier des charges impose une séparation stricte entre le réseau interne (LAN) et la zone exposée (DMZ), une haute disponibilité sur les services critiques, une gestion centralisée des postes et un système de supervision couvrant l'ensemble des machines.
Travail en binôme : mon binôme gérais la partie applicative et web (développement des services métier GSB), je gérais la partie réseau, systèmes et sécurité — pare-feu, Active Directory, load balancing, supervision, routage dynamique. Tout virtualisé sur Hyper-V, chaque machine déployée manuellement depuis l'ISO.
Schéma de l'infrastructure
L'infrastructure est découpée en trois zones distinctes séparées par IPFire. La zone LAN (192.168.227.x) regroupe les services internes : contrôleur de domaine Active Directory, GLPI, les postes clients et les routeurs Cisco. La zone DMZ (10.69.1.x) héberge les services exposables : HAProxy en load balancer devant deux serveurs web Debian, Ubuntu Nagios pour la supervision, et un poste client de test. Le pare-feu IPFire filtre et route tous les flux entre les trois zones.
Composants déployés
IPFire — Pare-feu périmétrique
Première brique déployée. IPFire sépare le WAN, le LAN (192.168.227.x) et la DMZ (10.69.1.x) en trois interfaces réseau distinctes. Configuration des règles NAT pour l'accès internet depuis le LAN, règles de filtrage applicatif inter-zones, et mise en place d'un VPN site-à-site pour simuler une connexion sécurisée entre sites. Chaque flux inter-zone est explicitement autorisé ou bloqué — rien ne passe sans règle.
Active Directory — Windows Server 2019
Déploiement du contrôleur de domaine principal sur Windows Server 2019 (192.168.227.1, domaine srvweb.com). Configuration des Unités Organisationnelles (OU) par département, création des groupes de sécurité, et déploiement de GPO couvrant : politique de mots de passe, verrouillage de compte, déploiement logiciel, restrictions d'accès aux paramètres système. Jonction au domaine des quatre postes Win10 clients et vérification de l'application des stratégies. Le DNS et le DHCP sont colocalisés sur le même serveur.
HAProxy — Load Balancing DMZ
HAProxy (10.69.1.5) est déployé en DMZ comme reverse proxy devant deux serveurs web Debian Apache (10.69.1.1 et 10.69.1.2). Configuration en mode round-robin avec health checks TCP et HTTP actifs : si un backend tombe, HAProxy le détecte en moins de 10 secondes et redirige tout le trafic vers le backend sain sans interruption de service. Les ACLs filtrent les requêtes par header HTTP pour router vers le bon backend selon le virtual host demandé.
GLPI — Gestion de parc
GLPI déployé sur Debian (192.168.227.9) avec la base MariaDB. L'agent OCS Inventory est installé sur chaque poste du domaine pour remonter automatiquement l'inventaire matériel et logiciel dans GLPI. Authentification des techniciens via LDAP connecté à l'Active Directory — les comptes AD sont utilisés directement sans doublon. Mise en place du module de tickets d'incidents pour les demandes utilisateurs et de la CMDB pour suivre les assets réseau.
Nagios — Supervision
Nagios déployé sur Ubuntu (10.69.1.4) en DMZ. Le plugin NRPE est installé sur chaque machine de l'infrastructure (LAN et DMZ) pour permettre à Nagios de récupérer les métriques locales : charge CPU, espace disque, état des services. Supervision ICMP pour la disponibilité de base, checks SSH et HTTP sur les services exposés, SNMP sur les routeurs Cisco pour les métriques réseau. Alertes mail configurées vers les adresses techniques en cas de seuil dépassé.
HSRP & OSPF — Routeurs Cisco
Simulé dans Packet Tracer, le routage dynamique de l'infrastructure utilise OSPF multi-area pour la convergence automatique des routes. HSRP est configuré sur deux routeurs Cisco en parallèle pour assurer la haute disponibilité : en cas de panne du routeur actif, le routeur standby prend le relai en moins de 10 secondes via l'IP virtuelle partagée. Tests de bascule effectués en coupant manuellement l'interface du routeur principal et vérification de la continuité du ping.
Difficultés rencontrées
Des paquets étaient perdus silencieusement entre le LAN et la DMZ sans aucun message d'erreur visible. Le ping timeout sans ICMP unreachable. Diagnostic : le chemin aller passait par IPFire mais la réponse empruntait une route différente. Fix : ajout d'une route statique retour explicite côté DMZ après activation du logging détaillé dans IPFire pour visualiser les flux réels.
L'agent OCS installé sur les postes LAN n'arrivait pas à remonter ses données vers le serveur GLPI en DMZ. La règle firewall générique LAN→DMZ ne suffisait pas car OCS utilise un port non-standard. Fix : création d'une règle IPFire ciblée sur le port OCS exact avec un compte de service dédié ayant les droits en écriture sur l'API GLPI.
Les machines jointes au domaine ne recevaient pas les GPO correctement. gpresult /r indiquait que le contrôleur de domaine n'était pas joignable pour la résolution. Cause : les cartes réseau des VMs Hyper-V pointaient vers le DNS public plutôt que vers le contrôleur de domaine. Fix : forçage du DNS primaire vers 192.168.227.1 sur toutes les interfaces réseau via DHCP.
HAProxy marquait les deux backends Debian comme DOWN alors que les serveurs Apache répondaient normalement. Cause : le health check HTTP envoyait une requête générique sur port 80, mais Apache était configuré pour répondre uniquement au virtual host spécifique — toute autre requête retournait un 403. Fix : ajout d'un header Host: srvweb.com explicite dans la configuration HAProxy du health check.
Le plugin NRPE installé sur les machines LAN refusait les connexions en provenance de l'IP Nagios (DMZ). Par défaut, NRPE n'accepte que les connexions localhost. Fix : modification du fichier nrpe.cfg sur chaque machine pour autoriser l'IP 10.69.1.4, couplé à une règle firewall IPFire autorisant le port 5666 depuis la DMZ vers le LAN.
Les deux routeurs Cisco ne s'échangeaient pas leurs routes OSPF. Cause : les interfaces appartenant à des zones OSPF différentes n'avaient pas de correspondance area. Fix : vérification avec show ip ospf neighbor — les routeurs n'établissaient pas d'adjacence. Correction de la configuration area sur les interfaces d'interconnexion et validation par show ip route ospf.
Ce que ce projet m'a appris
Penser en termes de zones et de flux — avant ce projet, je configurais des règles firewall de façon réactive. Ici, modéliser l'infrastructure en zones (LAN, DMZ, WAN) avec des flux explicitement définis entre chaque zone force à raisonner sur la sécurité dès la conception, pas en correction.
Le débogage réseau méthodique — face à un paquet perdu sans message d'erreur, la méthode compte autant que les connaissances. Ping, traceroute, tcpdump sur les interfaces IPFire, logs Nagios, gpresult : chaque outil a sa place dans une séquence logique de diagnostic.
L'interdépendance des services — GLPI dépend de l'AD pour l'authentification, Nagios dépend de NRPE pour les métriques, HAProxy dépend de la résolution DNS. Comprendre ces dépendances dans l'ordre de déploiement évite des heures de débogage inutile.
Travailler en binôme sur une infrastructure commune — coordonner les déploiements avec quelqu'un qui travaille sur la couche applicative au-dessus de ton infrastructure, ça force à documenter, à communiquer les adresses IP et les ports, et à ne pas casser ce que l'autre a mis en place.