Au cours de ma formation, j’ai mis en place plusieurs serveurs chez moi, qui s’organisent autour d’un Homelab. Son intérêt est multiple :
Tester facilement des concepts et technologies vues en formation ou dans le cadre de ma veille technologique
Organiser et sécuriser mon identité professionnelle
- Déployer des outils utilisables au quotidien (Cloud personnel, stockage, sauvegarde…)
De par sa nature, mon Homelab est en constante évolution. Néanmoins, je vais vous présenter ici un état des lieux de l’infrastructure et des services associées, ainsi que des raisons et choix qui y ont mené.
I - Du matériel majoritairement recyclé ou d’occasion
Deux sites hébergent tout le matériel : La majeure partie se situe dans le placard de mon bureau (ventilé) dont une photo est exposée ci-dessous, et une machine est chez une personne de confiance à quelques kilomètres.
1 - Cluster de 3 hyperviseurs Proxmox
Le cœur de l’infrastructure est un cluster de 3 hyperviseurs sous Proxmox, hébergeant la majorité des serveurs sous forme de machines virtuelles ou conteneurs.
Il est composé de 3 anciennes stations de travail HP avec quelques ajouts :
HP Z400 v2
Processeur
Intel Xeon X5680 6 cœurs / 12 threads
RAM
36 Go DDR3 1600MHz ECC
Stockage
2 SSD 120 Go en RAID 1 pour l’OS
3 SSD 512 Go pour les données, intégrés au système Ceph
Réseau
5 Gigabit Ethernet (1 carte PCIe 4 ports rajoutée)
4 SFP+ (2 cartes PCIe 2 ports rajoutées)
HP Compaq 8200 Elite SFF
Processeur
Intel Core i5 2400 4 cœurs / 4 threads
RAM
32 Go DDR3 1600MHz
Stockage
2 SSD 120 Go en RAID 1 pour l’OS
3 SSD 512 Go pour les données, intégrés au système Ceph
Réseau
3 Gigabit Ethernet (1 carte PCIe 2 ports rajoutée)
1 SFP+ (1 carte PCIe 2 ports rajoutée)
HP Z400 v2
Processeur
Intel Xeon X5680 6 cœurs / 12 threads
RAM
32 Go DDR3 1600MHz ECC
Stockage
2 SSD 120 Go en RAID 1 pour l’OS
3 SSD 512 Go pour les données, intégrés au système Ceph
Réseau
5 Gigabit Ethernet (1 carte PCIe 4 ports rajoutée)
4 SFP+ (2 cartes PCIe 2 ports rajoutées)
On peut voir le détail des informations des systèmes sur l’interface web de Proxmox, et gérer tous les serveurs depuis une seule page web :
2 - Deux NAS pour la sauvegarde et l’archivage
Pour la sauvegarde des machines et le stockage de gros volume, une machine sert de NAS avec TrueNAS Scale.
Une sauvegarde hors-site est également configurée sur un serveur TrueNas Scale à quelques kilomètres.
Gigabyte Z390 UD
Processeur
Intel Core i5 8500T 6 cœurs / 6 threads
RAM
20 Go DDR4 2333MHz
Stockage
1 SSD NVMe 512 Go pour l’OS
3 HDD 4 To Seagate IronWolf-Pro en RAID 5 soit 8 To d’espace disponible
2 HDD 1 To de récupération en RAID 1 pour des tests
Réseau
1 Gigabit Ethernet
2 2.5 GbE (1 carte PCIe 2 ports rajoutée)
2 SFP+ (1 carte PCIe 2 ports rajoutée)
Processeur
Intel Core i7 4770 4 cœurs / 8 threads
RAM
16 Go DDR3 1600MHz
Stockage
2 SSD 120 Go en RAID 1 pour l’OS
3 HDD 4 To Seagate IronWolf-Pro en RAID 5 soit 8 To d’espace disponible
Réseau
2 Gigabit Ethernet (1 carte PCI rajoutée)
3 - Matériel réseau et protection électrique
Le réseau est configuré sur des liens à 10 Gb en majorité. Technologie récente oblige, la majorité des équipements réseaux sont donc neufs contrairement au reste du Homelab. L’organisation du réseau est décrite en partie 2, ici sera seulement exposé le matériel utilisé.
Site Principal
pfSense gère l’essentiel du filtrage du réseau. Il assure un rôle de pare-feu avec état, agit en en reverse proxy avec HAProxy et permet différents filtrages via pfblockerng et crowdsec.
Le pare-feu intégré à PVE permet aussi de filtrer au niveau de chaque machine virtuelle.
Une machine virtuelle pfSense agit comme routeur principal. Il sépare plusieurs réseaux en VLANs et son accès WAN est donné directement via une Freebox en mode bridge (l’adresse IP publique est donnée directement à pfSense).
Deux switchs administrables de niveau 2 sont au cœur du réseau :
Switch 10 Gb 8 ports Mikrotik CRS309-1G-8S+IN
Switch multi gigabit 12 ports Zyxel XGS-1210-12
Un point d’accès wifi 6 Zyxel NWA50AX diffuse deux SSID sur 2 VLANs différents.
Tous les serveurs et équipements réseaux sont protégés par un onduleur Line-Interactive à l’exception du point d’accès wifi de par son éloignement.
Un Raspberry Pi raccordé aux onduleurs permet d’éteindre automatiquement via SSH les serveurs en cas de coupure de courant prolongée, et de les rallumer via Wake on LAN lorsque le courant est rétabli.
Site Secondaire
Une machine virtuelle pfSense agit comme routeur et pare-feu pour les serveurs. Il gère le tunnel VPN vers le site principal. Le seul serveur étant le NAS de sauvegarde, il n’y a pas de switch. L’accès WAN se fait en NAT derrière une box SFR.
II - Un réseau sécurisé et efficace
1 - Auto-hébergement : segmentation et sécurisation du réseau
L’infrastructure réseau s’organise selon une logique de défense en profondeur : le réseau est segmenté le plus possible sur plusieurs niveaux et plusieurs services sont déployés dans le but de sécuriser les accès aux serveurs et protéger les utilisateurs.
Le schéma logique ci-dessous présente les différents réseaux (domaines de diffusion) configurés, sans tenir compte de l’infrastructure physique sous-jacente.
Il y a donc 6 sous-réseaux, chacun isolés par défaut avec certaines autorisations spécifiques. L’IPv6 est activée et gérée sur tous les réseaux sauf le réseau d’administration :
C’est le réseau principal de mes machines clientes. Les machines sur ce réseau ont un niveau de confiance élevé et ont accès aux services du réseau global.
Ici sont installés tous les appareils de type IoT ou « smart », considérés avec un niveau de confiance minimal. De part l’impossibilité de contrôler leur comportement, les machines de ce réseau n’ont accès qu’à l’internet.
Tous les serveurs ayant une interaction en local entre eux ou avec les utilisateurs sont regroupés ici. Le pare-feu de chaque machine (ou celui de PVE) n’autorise aucun protocole d’administration au sein de ce réseau (SSH, webadmin etc…).
Toutes les interfaces d’administration des serveurs sont situées dans ce réseau. Le réseau est complètement isolé d’internet et des autres réseaux locaux. Le pare-feu de chaque machine (ou celui de PVE) permet de bloquer tous les services non-liés directement à l’administration, et seule une sélection de machines peuvent administrer les serveurs. Il y a un serveur DNS spécifique pour les administrateurs.
Les serveurs fournissant des services accessibles par le WAN sont dans ce réseau. Les accès HTTPS sont contrôlé par un reverse proxy qui va diriger les requêtes vers le bon serveur selon l’URL demandée et permettre la terminaison TLS avec le client. Le pare-feu pfSense monitore et bloque certaines menaces grâce à Crowdsec et des listes d’IP malveillantes fournies par pfBlockerNG.
C’est la zone de test, isolée des autres réseaux locaux, dans laquelle sont déployées des machines réelles ou physiques en phase de test. Cela permet d’essayer des nouveaux concepts ou services avec des risques minimums et de valider les configurations avant déploiement en « production ».
pfBlockerNG permet également de faire de la protection des utilisateurs en se basant sur des listes mises à jour automatiquement ou personnalisées.
Filtrage des requêtes DNS : les requêtes vers des sites malveillants ou dangereux sont redirigées vers une page interne indiquant la raison du blocage. Sont bloqués par exemple les sites de paris en ligne, les sites malveillants connus ou les sites de sectes.
Blocage au niveau pare-feu des adresses IP correspondantes aux noms DNS filtrés.
Pour améliorer le fonctionnement de pfBlockerNG, on bloque l’accès aux autres serveurs DNS sur internet. Les serveurs DoH (DNS over HTTPS) connus sont aussi bloqués grâce à une liste automatique de pfBlockerNG.
2 - Redondance et hyper-convergence
Au-delà d’être un environnement d’apprentissage, cette infrastructure héberge des services indispensables pour moi et mes proches. Il est donc important d’assurer une forte disponibilité, tout en gardant une flexibilité particulière de maintenance et de modification.
La haute disponibilité est assurée par 4 aspects :
Un cluster de 3 hyperviseurs sous Proxmox permet de palier à la chute d’une machine physique avec une perturbation minimale des machines virtuelles hébergées. Le routeur principal pfSense est lui-même virtualisé et donc profite de ce mécanisme d’hyper-convergence.
La majorité des serveurs sont reliés à deux switchs indépendants. Les cartes réseaux des hôtes en question sont configurées en lien (ou bond), généralement en mode active-backup : l’interface la plus rapide est active et la seconde prend le relais en cas d’incident sur la première ou sur le switch.
Toutes les données et les systèmes d’exploitation sont stockés avec de la redondance, permettant la perte de 1 ou plusieurs disques selon la situation sans interruption de service. (RAID 1, 5 ou Ceph)
Tous les serveurs sont raccordés à un onduleur permettant de prendre le relai en cas de microcoupure d’électricité. Un système de contrôle basé sur NUT (Network UPS Tools) permet aussi d’éteindre gracieusement les systèmes en cas de coupure prolongée, puis de les redémarrer automatiquement par Wake on Lan lorsque le courant est rétabli.
Le schéma ci-dessous représente l’agencement physique réel du réseau. Il met en évidence la redondance des équipements. Pour simplifier, le cluster Proxmox est considéré comme un seul et même hôte avec 2 interfaces WAN et 2 interfaces LAN.
Pour des contraintes matérielles et budgétaires, seuls les nœuds Z1 et Z2 gèrent l’accès WAN et sont donc en capacité d’accueillir la VM pfSense. Cela n’a pas d’impact sur la haute disponibilité, car tout fonctionne tant qu’au moins un de ces deux nœuds est fonctionnel.
La communication inter-cluster se décompose en deux réseaux :
Un réseau dédié à corrosync et heartbeat : Il permet aux nœuds de communiquer sur leur état pour prendre des décisions quant à la disponibilité des hôtes. Il sert aussi à synchroniser les configurations. Faible bande passante mais très sensible à la latence.
Un réseau dédié à Ceph : Il assure la disponibilité et la réplication du stockage sur tous les nœuds. C’est l’emplacement de stockage des VM et autorise la migration de ces dernières sans perte de données. Très gourmand en bande passante, deux cartes réseaux 10 Gb y sont consacrées pour chaque nœud, configurées en mode « routed with fallback » (chaque paquet est envoyé au nœud adressé uniquement. Si la connexion directe est coupée, les paquets seront routés via la machine entre les 2)
Le schéma ci-dessous représente l’organisation du réseau au sein du cluster PVE. Pour simplifier la vue, l’ensemble des VM et conteneurs sont considérés comme étant sur le nœud Z1.
Chaque machine a un accès au LAN et les interfaces réseau nécessaires pour la clusterisation. Seuls les nœuds Z1 et Z2 gèrent l’accès WAN
3 - Accès distant : VPN site-à-site, administration et accès utilisateur
pfSense est compatible avec de nombreux protocoles VPN Open Source. On peut y configurer de nombreux tunnels pour sécuriser les accès distants.
Il y a un VPN site-à-site basé sur Wireguard entre les deux sites. Wireguard est un protocole VPN très efficace, basé sur un chiffrement asymétrique avec clé privée/clé publique sur chaque hôte. Ce tunnel sert actuellement uniquement à la sauvegarde hors site, les règles de routage et de pare-feu sont donc configurées en conséquence.
Il n’y a cependant pas de configuration automatique pour un VPN site-à-site avec Wireguard sur pfSense, il faut donc le configurer manuellement. Les étapes générales pour la mise en place sont expliquées sur cette page.
Ainsi, le tunnel configuré permet d’avoir une communication stable et sécurisée entre les deux sites pour la sauvegarde des données.
Pour l’accès VPN depuis un poste client, je privilégie OpenVPN qui a des fonctionnalités plus approfondies et est très largement compatible avec tous les systèmes d’exploitation. Je peux y intégrer une authentification par identifiant/mot de passe en plus de certificats.
Pour l’accès VPN depuis un poste client, je privilégie OpenVPN qui a des fonctionnalités plus approfondies et est très largement compatible avec tous les systèmes d’exploitation. Je peux y intégrer une authentification par identifiant/mot de passe en plus de certificats.
Le serveur OpenVPN a ici deux objectifs :
Permettre l’administration à distance du Homelab
Permettre à mes proches d’accéder à des services sur mon réseau local
La distinction des privilèges entre Administrateur et Utilisateur se fait grâce au paramètre « client specific override ». On peut notamment autoriser une adresse IP et serveur DNS spécifiques uniquement à l’utilisateur avec des droits d’administration. Il suffit ensuite d’autoriser uniquement cette adresse IP à accéder aux services via le pare-feu.
III - Des services variés en constante évolution
Cette infrastructure sert à fournir un environnement de test, mais aussi et surtout à héberger des services utilisés au quotidien. J’ai choisi de présenter deux d’entre eux particulièrement importants : Nextcloud et Bitwarden
1 - Nextcloud : une alternative aux services cloud personnels
Nextcloud est une plateforme de collaboration open-source localement hébergée proposant une alternative efficace eux services de drive en Cloud tels que Dropbox ou Google Drive. Cette solution est utilisée par de nombreuses entreprises pour sa fonctionnalité principale de gestion des fichiers, mais est aussi très populaire auprès des particuliers désireux de prendre en main leur indépendance numérique.
Mon serveur Nextcloud est hébergé sur Docker, et est accessible derrière un reverse proxy HA Proxy qui s’occupe de la terminaison TLS.
Je m’en sers pour synchroniser sur tous mes appareils (Windows, Linux et Android) :
- Mes documents à accès régulier (cours, administratif, projets…)
- Photos
- Paramètres Linux (« dot » files : .bashrc, .local, .config etc…)
- Contacts
- Agenda
Avec les applications Deck et Notes, j’organise mes projets et ma documentation.
Je partage également l’instance avec les membres de ma famille. Cela permet de partager facilement des fichiers et de gérer des tâches communes comme les listes de courses avec Deck pour les projets communs.
Les possibilités autour de cet outil sont nombreuses, j’en utilise de nouvelles régulièrement pour des projets divers.
2 - Bitwarden : gestionnaire de mot de passe sécurisé
La sécurisation des accès est un élément crucial pour tous. Un gestionnaire de mots de passe est une solution efficace pour sauvegarder et générer des mots de passe uniques pour chaque service.
Bitwarden est un gestionnaire de mots de passe open-source permettant toutes les fonctionnalités d’un gestionnaire moderne avec un hébergement sur site. Toutes les données sont alors entièrement maitrisées.
Pour mon utilisation personnelle, j’utilise Vaultwarden (anciennement Bitwarden_RS), une implémentation communautaire en Rust du serveur Bitwarden. Comparé au serveur officiel, Vaultwarden demande moins de ressources et débloque toutes les fonctionnalités normalement réservées à la version entreprise. L’API de Vaultwarden est néanmoins compatible avec les clients officiels Bitwarden (Smartphones, Ordinateurs et Navigateurs).
Comme Nextcloud, Vaultwarden est hébergé sur Docker et est accessible derrière un reverse proxy HA Proxy qui s’occupe de la terminaison TLS.
Différentes organisations sont configurées sur mon instance, permettant de partager les mots de passe nécessaires entre les utilisateurs avec une fine gestion des droits.
Conclusion
Sur mon temps libre je me suis découvert une véritable passion pour le Homelabbing. J’ai pu expérimenter de nombreux concepts repérés lors de ma veille technologique, et mettre en pratique les apprentissages de la formation.
Je construis et déconstruis des solutions en accord avec mes objectifs et mes contraintes, et maintiens au quotidien une infrastructure cruciale à mon développement professionnel et personnel. Ce projet m’a non seulement permis d’aiguiser mes compétences, mais aussi d’augmenter mon appétit pour le domaine et d’améliorer mon environnement numérique quotidien.
