Laboratoire personnel · DozyLab
Mon homelab, conçu et exploité seul en dehors de la formation et de l’alternance. Il me sert à bâtir une infrastructure complète, documentée au standard professionnel, et à expérimenter librement la virtualisation, le réseau, l’annuaire et la sécurité. Les réalisations présentées ici sont personnelles : elles ne relèvent ni du centre de formation ni de l’entreprise.
Le laboratoire DozyLab
En parallèle de la formation et de l’alternance, je conçois et j’exploite seul DozyLab, un homelab auto-hébergé. L’objectif : bâtir une infrastructure complète et cohérente, documentée comme en production, pour expérimenter librement la virtualisation, le réseau segmenté, les services d’annuaire et la sécurité.
Chaque service suit les mêmes règles : conteneurs LXC non privilégiés par défaut, conventions de nommage et d’adressage formalisées, aucun secret en clair grâce à un coffre Vaultwarden, et une procédure technique versionnée pour chaque déploiement (référence HL-PRC).
Les fiches issues du laboratoire portent la mention Homelab : ce sont des réalisations personnelles, distinctes de mes travaux en centre et en entreprise.
En bref
- Nature
- Laboratoire personnel
- Matériel
- Cluster Proxmox VE à 3 nœuds, pare-feu Juniper SRX300, commutateur Cisco SF302-08PP
- Réseau
- 9 VLAN 802.1Q, matrice de flux inter-VLAN
- En service
- DNS Technitium, Active Directory et AD CS, reverse proxy TLS, Vaultwarden, Wazuh, tableau de bord WatchTower
- Planifié
- Zabbix, Suricata, CrowdSec, step-ca, Keycloak
- Documentation
- Procédures HL-PRC versionnées dans Gitea
Architecture
Le matériel et la segmentation réseau sur lesquels reposent tous les services.
Infrastructure physique
- Virtualisation
- Cluster Proxmox VE à trois nœuds, 40 Go de mémoire au total
- Pare-feu
- Juniper SRX300 (Junos) : routage inter-VLAN, NAT, zones de sécurité
- Commutateur
- Cisco SF302-08PP : VLAN 802.1Q, recopie de port pour la capture
- Sans fil
- Point d’accès dédié au VLAN invité
- Capture
- Carte réseau dédiée sur un nœud, alimentée par recopie de port (SPAN)
Réseau segmenté
- VLAN 10
- ADM · administration
- VLAN 20
- SRV · serveurs
- VLAN 30
- DMZ · zone démilitarisée
- VLAN 40
- CLI · postes clients
- VLAN 50
- VOIP · téléphonie
- VLAN 60
- DEPLOY · déploiement PXE
- VLAN 70
- WIFI · réseau invité
- VLAN 80
- LAB · laboratoire IA
- VLAN 99
- CLUSTER · cohérence Corosync, non routé
Les flux entre VLAN sont filtrés par le SRX300 selon une matrice de flux définie.
Services
Ce qui tourne aujourd’hui et ce qui est prévu. Les services planifiés ne sont pas encore déployés.
En service
- Technitium DNS — DNS interne avec DNSSEC, en conteneur LXC En service
- Active Directory — annuaire, DHCP et autorité de certification racine (AD CS) sous Windows Server 2022 En service
- Nginx Proxy Manager — reverse proxy et terminaison TLS En service
- Vaultwarden — coffre de référence pour les secrets En service
- Wazuh — SIEM : manager, indexer et tableau de bord En service
- WatchTower — tableau de bord opérationnel développé sur mesure En service
Planifiés
- step-ca — autorité subordonnée et renouvellement automatique des certificats (ACME) Planifié
- Keycloak — authentification unique OIDC fédérée à l’annuaire Planifié
- Zabbix — supervision des métriques Planifié
- Loki et Grafana Alloy — centralisation des journaux des services critiques Planifié
- Suricata — détection d’intrusion passive sur la recopie de port Planifié
- CrowdSec — protection périmétrique Planifié
- Guacamole — passerelle d’accès distant Planifié
- FOG Project — déploiement de postes par PXE Planifié
- n8n — automatisation de workflows Planifié
Principes d’architecture
Les règles appliquées à chaque service, pour garder un ensemble cohérent et maintenable.
Conception
- Services en conteneurs LXC non privilégiés par défaut ; Docker uniquement en machine virtuelle, chaque exception étant nommée et documentée.
- Pas d’orchestration lourde : ni Ansible, ni Kubernetes.
- Nommage structuré par service et par zone, identifiants de machines dérivés du VLAN et de l’adresse.
- Une procédure technique versionnée (référence HL-PRC) pour chaque déploiement, stockée dans Gitea.
Sécurité
- Aucun secret en clair : Vaultwarden est le coffre de référence.
- PKI interne : autorité racine AD CS en RSA 4096, subordination par step-ca prévue.
- Segmentation stricte avec matrice de flux inter-VLAN.
- Durcissement systemd des conteneurs ; accès root par clé SSH uniquement, sans sudo.
- Capture réseau passive par recopie de port dédiée.
Projets développés
Deux outils conçus pour piloter le laboratoire.
WatchTower En service
Tableau de bord opérationnel développé sur mesure pour piloter le homelab : vue d’ensemble, topologie, hôtes, capacité Proxmox, PKI, écarts de configuration, accès, registre et journal des changements.
- FastAPI
- React
- Vite
- TypeScript
- Tailwind CSS
- PWA
Hermes Planifié
Agent IA autonome prévu pour opérer sur l’infrastructure sous contrôle strict : confiné au VLAN LAB sans clé SSH vers les autres machines, chaque action modifiant l’infrastructure passe par une file d’approbation humaine dans WatchTower. Échanges par Git et serveur MCP, journaux centralisés dans Wazuh, secrets fournis par Vaultwarden.
Réalisations du laboratoire
Les fiches conservent leur numéro d’origine. Filtrez par domaine ou par compétence, puis ouvrez une fiche pour le détail.
$ pvecm status Cluster information Name: labo Nodes: 3 Quorate: Yes $ pvesm status local-lvm lvmthin active
Cluster de virtualisation Proxmox VE à trois nœuds
Trois hyperviseurs Proxmox VE réunis en grappe, raccordés à un réseau segmenté en VLAN, avec un lien de cohérence dédié.
- Proxmox VE
- Corosync
- 802.1Q
- LVM-thin
- Debian
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Pourquoi cette mise en place
Regrouper plusieurs hyperviseurs en cluster centralise l’administration des machines virtuelles et des conteneurs. L’ordre des opérations est contraignant : nom de la grappe, noms d’hôtes et type de stockage deviennent quasi immuables une fois la grappe créée.
Objectifs
- Constituer une grappe cohérente et quorate
- Séparer le trafic d’administration et le trafic de cohérence
- Préparer l’hébergement des services du lab
Mise en œuvre
- Installation homogène des trois nœuds (même version, même stockage)
- Configuration des ponts réseau en mode VLAN aware et des interfaces étiquetées
- Bascule progressive de l’adressage d’administration avec console de secours
- Remplacement du dépôt d’entreprise par le dépôt communautaire
- Création de la grappe avec deux liens Corosync, puis adhésion des nœuds
- Déclaration des stockages restreints à leur nœud et création d’un groupe d’administration
Compétences validées
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation : groupe d’administration de la grappe et droits associés ; vérifier les conditions de la continuité d’un service : deux liens de cohérence Corosync et contrôle du quorum.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : installation homogène des trois nœuds et création de la grappe ; réaliser les tests d’intégration : vérification du quorum, des liens et des stockages.
Commutateur Cisco SF302-08PP : VLAN et administration
Remise à zéro, création des VLAN, trunk vers le pare-feu et migration du plan de gestion vers le VLAN d’administration en SSH.
- Cisco
- VLAN
- 802.1Q
- SSH
- PuTTY
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Pourquoi cette mise en place
Un commutateur administrable se segmente, se sécurise et s’administre à distance. Le point délicat : il ne dispose que d’une adresse de gestion, et un enchaînement mal ordonné coupe l’accès sans autre recours que la console.
Objectifs
- Segmenter le réseau en VLAN
- Raccorder le pare-feu par un trunk 802.1Q
- Administrer l’équipement à distance de façon sécurisée
Mise en œuvre
- Réinitialisation et prise en main par la console série (9600 8N1)
- Création et nommage des VLAN, affectation des ports d’accès
- Configuration du trunk d’uplink vers le pare-feu
- Mise en place d’un chemin de secours avant la bascule
- Migration de l’adresse de gestion vers le VLAN 10 et reprise en SSH
- Sauvegarde de la configuration après chaque étape validée
Compétences validées
- Gérer le patrimoine informatique — Vérifier les conditions de la continuité d’un service : chemin de secours établi avant la bascule et configuration enregistrée après chaque étape ; niveaux d’habilitation : administration limitée au VLAN d’administration, en SSH.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : segmentation en VLAN et trunk vers le pare-feu ; réaliser les tests d’intégration : validation du VLAN cible avant la migration du plan de gestion.
$ dig @10.10.20.11 wazuh.srv.dozylab.lan +short 10.10.20.20 $ dig @10.10.20.11 -x 10.10.20.20 +short wazuh.srv.dozylab.lan.
Serveur DNS interne Technitium
Serveur DNS récursif et autoritaire en conteneur LXC : zones directes et inverses, récursion restreinte, bascule des clients DHCP.
- Technitium DNS
- LXC
- DNS
- Proxmox VE
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Pourquoi cette mise en place
Sans DNS interne, pas de services nommés, pas d’infrastructure à clés publiques ni d’annuaire. Disposer d’une autorité DNS unique pour tous les segments est un préalable à la suite du laboratoire.
Objectifs
- Déployer un DNS interne récursif et autoritaire
- Créer les zones directes et inverses
- Basculer les clients sans coupure de service
Mise en œuvre
- Création d’un conteneur LXC non privilégié sur le VLAN serveurs
- Installation de Technitium après relecture du script d’installation
- Changement immédiat des identifiants par défaut de la console
- Création de la zone directe et des zones inverses
- Restriction de la récursion aux réseaux internes
- Bascule des pools DHCP segment par segment puis vérification avec
dig
Compétences validées
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : récursion restreinte aux réseaux internes, identifiants par défaut changés dès l’installation.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : DNS interne en conteneur, bascule des clients DHCP segment par segment ; réaliser les tests d’intégration : résolutions directes et inverses vérifiées avec dig.
$ systemctl is-active wazuh-manager \
wazuh-indexer wazuh-dashboard
active
active
active
$ ss -tlnp | grep -E '1514|1515|443'Supervision de sécurité avec Wazuh
Déploiement d'une instance Wazuh complète pour centraliser les événements de sécurité et gagner en visibilité sur l'infrastructure.
- Wazuh 4.14
- Ubuntu 24.04
- OpenSearch
- systemd
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Pourquoi cette mise en place
La surveillance des systèmes permet de détecter les événements importants. Wazuh centralise les informations remontées par les agents et permet d'analyser les événements de sécurité.
Objectifs
- Centraliser les événements des systèmes
- Améliorer la visibilité sur les postes et serveurs
- Documenter le déploiement
Mise en œuvre
- Préparation du serveur (paramètres noyau, limites de ressources)
- Installation tout-en-un de Wazuh
- Durcissement des services systemd et pare-feu local
- Intégration réseau : nom DNS interne, pare-feu local et accès HTTPS au tableau de bord
- Vérification des services et des ports en écoute
Technologies
- Wazuh 4.14
- Ubuntu 24.04
- OpenSearch
- systemd
Compétences validées
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : Wazuh en installation tout-en-un, durcissement systemd et pare-feu local ; réaliser les tests d’intégration : vérification des services, des ports en écoute et de l’accès au tableau de bord.
fw01# commit check configuration check succeeds fw01# commit confirmed 5 commit confirmed will be rolled back in 5 minutes fw01> ping 9.9.9.9 count 3
Mise en service d'un pare-feu Juniper SRX300
Pare-feu SRX300 en routeur inter-VLAN : zones de sécurité, politiques explicites, NAT, DHCP par VLAN et relais DNS.
- Juniper SRX300
- Junos
- NAT
- DHCP
- 802.1Q
Voir le détail
Contexte : Homelab · Réalisation personnelle menée dans mon laboratoire DozyLab, en dehors de la formation et de l’entreprise.
Pourquoi cette mise en place
Déployer un pare-feu, c'est décider quels flux passent. Le SRX300 route huit VLAN sur un trunk unique et bloque par défaut tout ce qui n'est pas explicitement autorisé.
Objectifs
- Mettre en service le pare-feu
- Router et filtrer les flux inter-VLAN
- Fournir DHCP, DNS et accès Internet
Mise en œuvre
- Remise à zéro et prise en main par la console série
- Trunk 802.1Q et sous-interfaces de VLAN
- Zones de sécurité, carnet d’adresses et politiques
- Serveur DHCP par VLAN et relais DNS
- NAT source vers Internet et compte d’administration nominatif
commit confirmed, vérifications finales et raccordement
Technologies
- Juniper SRX300
- Junos
- NAT
- DHCP
- 802.1Q
Compétences validées
- Gérer le patrimoine informatique — Mettre en place et vérifier les niveaux d’habilitation associés à un service : compte d’administration nominatif, connexion root par mot de passe refusée, SSH limité à la zone d’administration.
- Mettre à disposition des utilisateurs un service informatique — Déployer un service : routage inter-VLAN, DHCP, relais DNS et NAT ; réaliser les tests d’intégration : commit confirmed puis vérifications finales avant le raccordement.