Un HomeLab, ça commence souvent par une machine posée sur une étagère, et ça finit par une petite infrastructure qu’on n’ose plus éteindre. Le mien n’échappe pas à la règle.
Cet article n’est pas un tutoriel : je ne détaille ni les installations ni les configurations (chaque brique a, ou aura, son article dédié). L’idée est de présenter les pierres fondatrices de mon HomeLab actuel, et surtout pourquoi j’ai fait ces choix.
Le matériel : un Aoostar WTR Max au centre
Tout repose aujourd’hui sur une seule machine : un Aoostar WTR Max. Je l’ai déjà présenté dans un article dédié, je ne reviens que sur ce qui a motivé mon choix.
Le WTR Max vu de face : les baies disques et le petit écran de suivi. Image : Aoostar.
Un réseau à la hauteur
- 2 ports SFP+ 10 Gb/s
- 2 ports Ethernet 2.5 Gb/s
C’est rare dans ce format. Cela permet de séparer proprement les flux (accès Internet, réseaux internes, stockage) sans que le réseau devienne le goulot d’étranglement.
La face arrière : les deux SFP+, les deux ports 2.5 Gb, l’USB4 et l’OCuLink. Image : Aoostar.
Un stockage généreux
- 6 baies 2.5” / 3.5” pour les disques
- 5 emplacements NVMe pour les données rapides
Je peux ainsi séparer les usages : le système et les applications sur du NVMe rapide, les données volumineuses (médias, photos, sauvegardes) sur des disques de grande capacité.
Une évolutivité réelle
Le WTR Max dispose d’un port OCuLink, une liaison PCIe externe qui permet de brancher une carte graphique via un dock eGPU. Utile pour de l’accélération vidéo ou de l’IA locale le jour où le besoin se présentera.
À vérifier avant d'acheter
Tous les docks eGPU OCuLink ne sont pas garantis compatibles avec cette machine. Si la carte graphique est un critère décisif, vérifie la compatibilité du dock avant de l’acheter.
Proxmox VE : le socle de virtualisation
Pour faire tourner tout ça, j’ai choisi Proxmox VE.
Mes raisons :
- Open source, sans licence obligatoire pour un usage personnel
- Une énorme communauté : tutoriels, forums, documentation très complète. Quand on bloque à 23 h, on trouve presque toujours la réponse
- VM et conteneurs LXC dans la même interface
- Une intégration native avec les sauvegardes (on y vient plus bas)
Je privilégie les conteneurs LXC : légers, rapides à créer, économes en ressources. Chaque service dispose ainsi de son propre conteneur, isolé des autres. Les VM sont réservées aux cas qui l’exigent, comme le pare-feu et le serveur de sauvegarde.
L’Infrastructure as Code : tout est décrit, tout est versionné
Un HomeLab qui grossit devient vite impossible à reconstruire de mémoire. Ma réponse : ne rien créer à la main quand je peux l’écrire.
- OpenTofu décrit l’infrastructure : quels conteneurs et quelles VM existent, avec quelles ressources et sur quel réseau.
- Ansible configure ce qui tourne dedans : installation des services, durcissement, mises à jour.
- La documentation du lab est elle aussi écrite en texte, à côté du code.
Tout cela vit dans des dépôts Git hébergés sur ma propre forge (Forgejo). Chaque modification passe par une branche puis une pull request que je relis avant de la fusionner.
Ce que ça m’apporte :
- l’historique : je sais ce qui a changé, quand, et pourquoi ;
- le retour arrière : une erreur se corrige en annulant un commit ;
- la reproductibilité : reconstruire un service, c’est relancer du code plutôt que refaire des clics de mémoire ;
- une documentation fidèle : elle suit le code au lieu de dériver.
Même ce blog suit ce chemin
Les articles du blog sont dans un dépôt Git. Quand je fusionne une modification, la forge construit le site automatiquement : d’abord sur une préversion en local pour relecture, puis en production.
La sécurité : VLAN et OPNsense
C’est la pierre la plus importante à mes yeux. Un HomeLab qui héberge des services (voire ceux d’autres personnes) ne peut pas vivre sur un réseau « à plat ».
Le cloisonnement par VLAN
Le réseau est découpé en VLAN par domaine. Chacun a un rôle précis et ne voit que ce qu’il a besoin de voir. Si un appareil connecté est compromis, il ne peut pas atteindre mes serveurs ni mes données.
| VLAN | Nom | Objectif | Exemples |
|---|---|---|---|
| 10 | MGMT | Administrer l’infrastructure | Proxmox, sauvegardes, supervision, pare-feu |
| 20 | Servers | Services internes, non exposés | Forge Git, runner CI, préversion du blog |
| 30 | Users | Équipements du quotidien | Smartphones, ordinateurs |
| 40 | DMZ Perso | Mes services accessibles de l’extérieur | Photos (Immich), médias (Jellyfin, *arr), finances (Kresus) |
| 50 | DMZ Asso | Services hébergés pour des associations | Gestion de parc (GLPI) |
| 60 | IoT | Objets connectés peu fiables | Caméras, distributeur de croquettes, poêle |
| 70 | Wi-Fi invité | Visiteurs, Internet seulement | Appareils de passage |
| 80 | Domotique | La maison connectée | Home Assistant, Gladys, Zigbee2MQTT |
| 90 | Ingress | Point d’entrée des tunnels | Client Newt (voir plus bas) |
Le principe de la DMZ : un service accessible de l’extérieur est, par nature, plus exposé. Je le place donc dans un VLAN à part, d’où il ne peut pas rebondir vers mes réseaux internes.
OPNsense dans une VM
Le routage et le filtrage entre ces réseaux sont assurés par OPNsense, un pare-feu open source, virtualisé dans une VM Proxmox. La règle est simple : tout est refusé par défaut, puis j’ouvre uniquement les flux nécessaires, VLAN par VLAN.
Voici l’architecture complète, de la box opérateur jusqu’aux services :
Le trafic Internet arrive sur la box opérateur, qui le transmet à l’Aoostar. OPNsense, à l’intérieur, décide de ce qui peut circuler entre les VLAN. Les services exposés vivent dans les DMZ, jamais sur le réseau d’administration.
Pangolin : accéder à mes services sans ouvrir un seul port
Voilà la brique qui change la donne côté exposition. Je n’ouvre aucun port sur ma box. Pas de redirection, pas d’adresse du domicile exposée.
À la place, j’utilise Pangolin, installé sur un serveur dédié externe :
- le HomeLab établit lui-même un tunnel sortant et chiffré vers ce serveur (via un petit client, Newt) ;
- le serveur joue le rôle de reverse proxy et de point de rencontre avec Internet ;
- Internet ne parle jamais directement à ma maison.
Je distingue deux types de ressources :
| Ressources publiques | Ressources privées | |
|---|---|---|
| Accès | Depuis Internet, en HTTPS | Uniquement via le client VPN |
| Pour qui | Services que je veux partager | Interfaces d’administration, services internes |
| Chemin | Serveur Pangolin → tunnel → VLAN Ingress | Serveur Pangolin → tunnel → VLAN MGMT |
Concrètement, si je veux consulter une interface d’administration depuis mon smartphone en déplacement, j’active le client VPN : la ressource n’existe tout simplement pas pour le reste d’Internet.
Pourquoi un VLAN dédié pour le tunnel ?
Le client de tunnel est le seul point d’entrée du HomeLab. Je l’isole donc dans un VLAN minuscule à un seul hôte, avec uniquement des connexions sortantes autorisées. Si un jour il était compromis, il ne verrait presque rien.
La sauvegarde : Proxmox Backup Server et règle 3-2-1-1
Une infrastructure sans sauvegarde n’est qu’une panne qui attend son heure.
Proxmox Backup Server
Je m’appuie sur Proxmox Backup Server (PBS), le choix naturel dans un environnement Proxmox :
- sauvegardes incrémentales : seuls les changements sont transférés ;
- déduplication : chaque donnée n’est stockée qu’une fois ;
- vérification d’intégrité des sauvegardes ;
- restauration simple d’une VM ou d’un conteneur complet, depuis la même interface ;
- sauvegardes planifiées, sans intervention de ma part.
La règle 3-2-1-1
Ma ligne directrice est la règle 3-2-1-1, une évolution de la célèbre 3-2-1 :
- 3 copies des données (l’original + 2 sauvegardes) ;
- 2 supports différents ;
- 1 copie hors site ;
- 1 copie immuable, qu’on ne peut ni modifier ni effacer, même en cas d’attaque.
La dernière copie, immuable, est stockée sur un disque externe. C’est ma protection contre le pire scénario : un ransomware ou une erreur qui détruirait à la fois mes données et mes sauvegardes en ligne. J’ai détaillé cette règle dans mon article sur la restructuration du HomeLab.
Une sauvegarde non testée n'existe pas
Le plus important n’est pas de sauvegarder, c’est de savoir restaurer. Je teste donc régulièrement la restauration de quelques services.
Supervision, mises à jour et sécurité
Quand on a une dizaine de conteneurs, on ne peut plus se contenter de « regarder si ça marche ».
La supervision avec Zabbix
Zabbix surveille l’ensemble : machines, conteneurs, pare-feu, utilisation des ressources, espace disque, disponibilité des services. D’un coup d’œil, je sais si quelque chose dérive avant que ça ne devienne une panne.
Le suivi des mises à jour
Zabbix suit aussi l’état des mises à jour de chaque machine : combien de paquets sont en attente, et surtout si des mises à jour de sécurité traînent trop longtemps. Les mises à jour elles-mêmes sont déclenchées avec Ansible, de façon reproductible. Je garde la main sur le moment : pas de mise à jour surprise un vendredi soir.
La veille sur les failles (CVE)
Les logiciels auto-hébergés ont des failles, c’est inévitable. Ce qui compte, c’est de les connaître avant qu’elles soient exploitées. Je suis donc les vulnérabilités publiées (CVE) qui concernent mes services, pour savoir lesquels corriger en priorité.
Les notifications
Une supervision qui ne prévient personne n’est qu’un joli tableau de bord. Je mets donc en place des notifications pour être alerté d’une panne, d’une mise à jour de sécurité en attente ou d’une faille qui touche un service. Le but : que l’information vienne à moi plutôt que l’inverse.
Ce qui tourne dessus
Sans entrer dans le détail, voici ce qui occupe aujourd’hui mon serveur :
- une forge Git auto-hébergée (Forgejo) et son runner de CI, qui déploie justement ce blog ;
- la gestion de photos (Immich) ;
- la pile multimédia (Jellyfin et la suite *arr) ;
- la domotique (Home Assistant et Gladys Assistant) ;
- la gestion de parc (GLPI) et un correcteur grammatical (LanguageTool) ;
- un gestionnaire de finances personnelles (Kresus) ;
- et bien sûr la supervision, les accès distants et le pare-feu.
Ce que j’en retiens
Cinq principes guident l’ensemble :
- Centraliser sans fragiliser : une machine puissante, mais des services isolés et sauvegardés.
- Cloisonner par défaut : VLAN et pare-feu avant tout.
- N’ouvrir aucun port : les accès passent par un tunnel sortant.
- Sauvegarder et surveiller : sans cela, le reste ne sert à rien.
- Tout décrire en code, tout versionner : pour pouvoir tout reconstruire, et tout documenter.
Ces fondations évolueront, mais elles me permettent d’ajouter un service en quelques heures plutôt que quelques week-ends. Dans les prochains articles, je détaillerai chaque brique : le réseau et OPNsense, Pangolin, les sauvegardes PBS, la supervision, l’automatisation.
Et toi, quelles sont les pierres fondatrices de ton HomeLab ?