HOMELAB ETUDIANT
Conception et Administration d’un Serveur Proxmox tout-en-un | 6 à 12 mois
Présentation et définition
Au départ, l’idée initiale était simple : construire un NAS pour stocker des fichiers de manière pratique et économique. Mais progressivement, mes ambitions ont grandi : pourquoi ne pas y intégrer du streaming vidéo ? Un serveur de jeu pour des amis ? Un environnement de cours isolé ? J’ai rapidement réalisé que je ne construisais pas un simple NAS, mais une infrastructure réseau complète. Autant la concevoir dans les règles de l’art.
L’objectif s’est transformé en la création d’un serveur tout-en-un capable de gérer : le stockage centralisé (NAS avec redondance), du streaming vidéo (Jellyfin), un serveur de jeu (Minecraft) et des machines virtuelles (VM) de cours isolées pour l’apprentissage. Le tout sécurisé, accessible à distance, et sans dépendre d’un hébergeur commercial.
Pour le matériel, le budget visé était d’environ 400 €, finalement ajusté entre 450 et 550 €. Voici la spécification exacte :
Matériel :
- CPU : Intel Core i7 8e génération (occasion) – 6 cœurs / 12 threads
- RAM : 32 Go DDR4 (critique pour Proxmox, ZFS, Docker et Windows)
- GPU : NVIDIA RTX 3060 12 Go (pour le transcodage Jellyfin en temps réel et le jeu)
- Stockage OS : SSD NVMe 500 Go (dédié à Proxmox VE)
- Stockage Données : 5 disques HDD de 4 To en RAIDZ2 (ZFS) → 12 To utiles avec redondance sur 2 disques
- Routeur : Freebox Revolution (DHCP principal)
- Réseau : Xiaomi en mode Point d’Accès (pour éviter le double NAT)
- Réseau interne : 192.168.1.x
Budget détaillé :
- CPU + RAM + GPU (occasion) : ~300 €
- SSD NVMe : ~50 €
- 5x HDD 4 To : ~200 €
- Total : ~550 € (contre 300 à 500 € par mois chez un hébergeur)
Objectifs, contexte, enjeux, risques
L’objectif principal était de concevoir une infrastructure virtualisée stable, sécurisée et économe en énergie. Il ne s’agissait pas d’un simple environnement de test éphémère : tout devait fonctionner en production (24/7) et offrir des services fiables.
Le contexte : Un projet personnel d’apprentissage permettant d’expérimenter sans impact critique, tout en maintenant une infrastructure opérationnelle utilisée par des tiers (serveur de jeu, stockage de données sensibles).
Les enjeux : Concevoir une architecture où chaque service est isolé (si une application défaille, le stockage reste intact), obtenir une observabilité complète des événements via un SIEM (Splunk), sécuriser l’accès distant (VPN Tailscale et listes de contrôle d’accès) et optimiser les ressources (CPU, RAM, stockage, électricité).
Les risques : Une instabilité récurrente liée à un défaut d’isolation, une perte de données due à une absence de redondance, des vulnérabilités critiques (ports ouverts, identifiants codés en dur) ou encore une surconsommation énergétique.
Les étapes
L’infrastructure logicielle : virtualisation complète sous Proxmox VE. L’ensemble de l’environnement est virtualisé sous Proxmox VE. Chaque composant dispose d’une machine virtuelle isolée ayant un rôle strictement défini :
- VM TrueNAS Scale (Le Stockage) : Le cœur du système. Les 5 disques HDD sont assignés en accès direct (passthrough) au contrôleur SATA (Proxmox n’intervient pas). TrueNAS gère le système de fichiers ZFS en RAIDZ2, les partages SMB/NFS, les permissions granulaires et les points de restauration (snapshots).
- VM Windows (Jeu) : Un serveur dédié hébergeant Minecraft, disposant d’un accès au NAS, d’une assignation directe du GPU pour le rendu, et accessible de manière sécurisée via le VPN Tailscale.
- VM Debian + CasaOS (Multimédia & Applications) : Elle héberge les services critiques conteneurisés via Docker, dont Jellyfin (streaming avec transcodage GPU), Nextcloud (cloud personnel), Pi-hole (serveur DNS et bloqueur de publicités) et Home Assistant (domotique).
- VM Debian (Environnement de cours) : Un bac à sable (sandbox) jetable destiné à l’apprentissage, permettant de tester des configurations sans mettre en péril l’infrastructure principale.
Le défi de la centralisation des logs avec Splunk
Initialement, les journaux d’événements (logs) étaient dispersés sur chaque composant, n’offrant aucune visibilité ni alerte centralisée. L’intégration d’un SIEM s’est donc imposée. Déployer Splunk exige une configuration technique pointue. J’ai dû installer les agents de collecte sur chaque source, formater et structurer (parser) les logs à l’aide d’expressions régulières (Regex) et concevoir des tableaux de bord pertinents pour filtrer le bruit. La complexité principale a résidé dans la détection des attaques par force brute. Lors d’une simulation, les tentatives de connexion remontaient bien dans Splunk, mais les règles de détection n’étaient pas correctement étalonnées. En ajustant les seuils (par exemple : le déclenchement d’une alerte après plus de 5 échecs d’authentification en moins de 2 minutes) et en affinant la correspondance des motifs, le système est devenu pleinement opérationnel. Aujourd’hui, je dispose d’une observabilité en temps réel sur le démarrage des VM, la sollicitation du GPU ou l’état du réseau.
TrueNAS et les complexités du stockage réel
Configurer un système ZFS en RAIDZ2 demande une grande rigueur. Tolérer la perte de deux disques sans perte de données est rassurant en théorie, mais son implémentation pratique (compréhension de la parité, ordre des disques dans les grappes, gestion fine des droits SMB/NFS, stratégie de sauvegarde) requiert une véritable maîtrise, acquise par l’étude de la documentation officielle. Cela m’a permis de consolider mes compétences opérationnelles en administration de stockage.
La sécurité : Tailscale et politique « zéro port ouvert »
La philosophie que j’ai adoptée a été stricte : aucun port n’est exposé sur le routeur de la box internet. Tout le trafic distant transite par le VPN Tailscale, installé sur chaque VM, couplé à des listes de contrôle d’accès (ACL) granulaires :
- Administrateur : Accès global à Proxmox, TrueNAS et à toutes les VM.
- Invités : Accès strictement limité au serveur de jeu et au streaming. L’adresse IP de l’interface d’administration leur est inaccessible.
Ce modèle applique les principes du Zero Trust à l’échelle d’une infrastructure domestique, garantissant une exposition distante hautement sécurisée.
L’automatisation : extinction et réveil programmés
Afin de rationaliser la consommation électrique, j’ai mis en place une automatisation complète du cycle d’alimentation. Les simples tâches planifiées s’étant révélées trop fragiles, j’ai développé un script Bash robuste qui :
- Journalise chaque étape pour faciliter les diagnostics.
- Attend l’arrêt propre de TrueNAS avec un délai de grâce de 60 secondes.
- Force l’arrêt en dernier recours pour éviter un blocage permanent du serveur.
- Éteint méthodiquement les autres VM avant d’éteindre l’hyperviseur Proxmox.
Le réveil s’effectue automatiquement via le BIOS (RTC Wake-up), et le séquençage de démarrage des VM est orchestré nativement par Proxmox (le NAS démarrant en premier pour fournir le stockage aux autres services).
Ce script :
- Logue chaque étape (utile pour debugger si ça casse)
- Attend que TrueNAS s’éteigne proprement avec timeout de 60s
- Force l’arrêt si ça traîne (fallback, évite un hang infini)
- Éteint les autres VMs avant Proxmox
- Gère les timeouts pour éviter les surprises
S’exécute chaque soir via cron :
Pour le réveil : RTC Wake-up en BIOS (réglé une fois à 09h00, ça réveille automatiquement chaque matin).
Pour le séquençage des VMs : Configuré dans Proxmox (Start/Shutdown order) :
- TrueNAS : order 1, delay 0
- CasaOS : order 2, delay 60 (attend que le NAS soit prêt)
- Windows : order 3, delay 90
Les services bonus : Pihole et Home Assistant
Tournent aussi en VMs dans Proxmox :
- Pihole : DNS au niveau réseau + blocage des pubs (tous les appareils en bénéficient)
- Home Assistant : Domotique complète (lumières, thermostats, automations)
Les logs de tout ça remontent dans Splunk pour une centralisation complète.
Les acteurs
Bien qu’il s’agisse d’un projet personnel, j’ai eu des utilisateurs réguliers (amis accédant au serveur de jeu ou au streaming) qui constituaient de véritables utilisateurs finaux. Leurs retours sur la stabilité, la latence et les performances m’ont permis d’affiner l’infrastructure en continu.
Pourquoi pas un hébergeur
Au départ j’ai regardé : « Et si je mets ça sur AWS/OVH/Hetzner ? » Les tarifs ? 300 à 500€ par mois pour du comparable. Mon infra coûte ~550€ en hardware et presque rien en électricité. En 6 à 12 mois, mon HomeLab s’est payé.
Plus important : j’apprends énormément plus en construisant qu’en utilisant une plateforme clé-en-main. Les erreurs, les débugs, les optimisations (c’est du vrai apprentissage). Les hébergeurs, tu cliques sur des boutons. Chez toi, tu fais tourner des services.
Aujourd’hui, ça tourne 24/7. Streaming vidéo autonome, serveur de jeu pour les amis, stockage centralisé sécurisé, monitoring complet. C’est cool de voir qu’on a bâti quelque chose qui fonctionne vraiment.
Métriques :
- Coût total : 550€ (vs 300-500€/mois hébergeur)
- Économie électricité : 40% (shutdown/wake programmés)
- Capacité stockage: 12 To utilize (5x4To RAIDZ2)
- Redondance : 2-disques perdus = zéro perte de données
- Uptime : 99%+ (zéro intervention depuis 6+ mois)
- Services tournant : 5 VMs + 4 services critiques (Jellyfin, Nextcloud, Pihole, Home Assistant)
Les résultats
- Pour moi : Une montée en compétences techniques exceptionnelle. Le passage de la théorie réseau à la pratique avancée (routage, DHCP, VPN, accès distant, transfert GPU, gestion ZFS, conteneurisation, SIEM) a été un formidable accélérateur d’apprentissage. J’ai désormais une vision concrète du travail en centre opérationnel de sécurité (SOC) grâce à la maîtrise de Splunk.
- Pour les services : La mise en production d’une infrastructure fiable, fonctionnant de manière autonome, offrant des services multimédias et ludiques fluides tout en sécurisant un stockage de plusieurs téraoctets.
- Sur le plan budgétaire : Avec un investissement matériel maîtrisé, ce laboratoire s’est rentabilisé en quelques mois face aux offres d’hébergement classiques.
Les lendemains
- Immédiat : L’infrastructure a atteint un niveau de stabilité optimal après quelques semaines d’ajustements.
- À distance : Le système maintient une disponibilité (uptime) supérieure à 99 % depuis plus de 6 mois, sans nécessiter d’intervention majeure. Les scripts d’automatisation opèrent de manière invisible.
- Aujourd’hui : Ce projet instaure une dynamique d’amélioration continue. Il a surtout éveillé mon intérêt pour l’automatisation à grande échelle : déployer manuellement 4 VM est très formateur, mais les défis de demain (des dizaines de serveurs, des centaines d’utilisateurs) exigeront la maîtrise de l’Infrastructure as Code (Ansible, Terraform), ce qui constitue ma prochaine étape d’apprentissage.
Regard critique
- Virtualisation (Proxmox) : L’isolation des services n’est pas un confort, c’est une exigence de conception. La séparation des rôles permet de circonscrire les défaillances et constitue le socle de toute infrastructure résiliente.
- Sécurité & Réseau (Tailscale + ACL) : Exposer un port sur internet représente un risque critique et souvent inutile. L’utilisation de solutions modernes d’accès distant combinées à des ACL fines est la définition même d’une sécurité proactive et adaptative.
- Automatisation & Scripting : L’automatisation réduit la charge mentale, élimine les erreurs de saisie et optimise la consommation énergétique. C’est un principe fondamental de l’administration moderne.
- Supervision et observabilité : Exploiter un SIEM m’a enseigné qu’une supervision efficace ne consiste pas à surveiller un tableau de bord, mais à comprendre la structure des logs et à corréler les événements pour identifier des anomalies complexes.
Compétences rattachées à cette réalisation
- Virtualisation (isolation des services, passthrough hardware, gestion des VMs)
- Ingénierie réseau (Tailscale VPN, ACLs granulaires, zero-trust architecture)
- Automatisation & Scripting (Wake-on-LAN, shutdown programmés, gestion de l’énergie)
- Administration Système (TrueNAS, ZFS, gestion du stockage)