Mon Homelab Proxmox VE : Aperçu de l'infrastructure
Je construis et sécurise ma propre infrastructure depuis des années â en commençant avec un simple Raspberry Pi et en évoluant vers un cluster Proxmox VE complet. Ce qui a commencé comme un projet de bricolage est devenu un laboratoire domestique de qualité production qui héberge ce blog, des environnements de développement, des services multimédia, une surveillance de sécurité et un point d’accès VPN.
Cet article est la vue d’ensemble de haut niveau. Les articles suivants plongeront dans les composants individuels.
Le Matériel
Un nÅud Proxmox VE unique tournant sur Debian 13 (Trixie) avec le noyau Proxmox VE. L’hôte se trouve sur mon réseau domestique avec une IP statique sur une interface bridge dédiée.
CPU: x86-64
RAM: Suffisante pour une douzaine de conteneurs LXC
Disque: Stockage LVM local pour les volumes des conteneurs
Réseau: Gigabit Ethernet, bridgé
J’ai opté pour les conteneurs LXC plutôt que les VM pour mes charges de travail d’infrastructure. LXC est plus léger, partage le noyau hôte et démarre en quelques secondes. Chaque conteneur a son propre système de fichiers, espace réseau et espace de processus â un isolement suffisant pour un homelab où vous faites confiance aux conteneurs que vous construisez.
La Topologie Réseau
Tous les conteneurs vivent sur un sous-réseau /24 privé derrière un bridge Proxmox. La passerelle est l’hôte Proxmox lui-même, qui gère le routage inter-conteneurs et fournit l’accès Internet en amont via le routeur domestique.
ââââââââââââââââ
â Routeur FAI â
â 10.x.x.1 â
âââââââââ¬ââââââââ
â
ââââââââ´ââââââââ
â Hôte Proxmox â
â Bridge/NAT â
ââââââââ¬ââââââââ
â
ââââââââââââ¼âââââââââââ
â â â
âå¤ââââ´ââââ âââââ´âââââ âââââ´âââââ
â dhcp â â web â â dev â
â serveurâ â proxy â â serveurâ
ââââââââââ ââââââââââ ââââââââââ
Un serveur ISC DHCP dédié (couvert dans un article séparé) gère l’allocation des IP. Les conteneurs d’infrastructure obtiennent des réservations statiques, tandis qu’un pool dynamique couvre les conteneurs de test éphémères.
Rôles des Conteneurs
dhcp-srv (10.99.99.2)
Le serveur DHCP pour tout le réseau du laboratoire. Exécute ISC DHCP Server sur Debian 13. Tous les autres conteneurs obtiennent leurs IP depuis ici via des réservations statiques. ~3 Mo de RAM.
web-proxy (10.99.99.11)
Proxy inverse et terminaison TLS. Achemine le trafic externe vers les services internes en fonction des noms de domaine, gère la provision des certificats Let’s Encrypt via certbot. C’est le seul conteneur exposé (via du port forwarding) au monde extérieur.
dev-srv (10.99.99.20)
Environnement de développement exécutant des applications Node.js via PM2. Héberge ce blog, des applications web et divers projets annexes. Utilise nvm pour la gestion des versions de Node.
mon-srv (10.99.99.10)
Surveillance de sécurité et observabilité. Exécute une pile d’agrégation de journaux avec Loki et Promtail, une instance CrowdSec pour la détection d’intrusion, et Grafana pour les tableaux de bord. Gère également les emails via Postfix.
media-srv (10.99.99.13)
Services multimédia et streaming de fichiers.
file-srv (10.99.99.14)
Stockage de fichiers réseau.
vpn-srv (10.99.99.25)
Point d’accès VPN pour un accès distant sécurisé au réseau du laboratoire.
Pourquoi LXC plutôt que des VM ?
On me demande souvent pourquoi j’ai choisi les conteneurs LXC plutôt que des VM complètes pour cette configuration. Voici mon raisonnement :
- Temps de démarrage : Les conteneurs démarrent en moins d’une seconde. Les VM complètes prennent 30 à 60 secondes.
- Surcharge mémoire : Chaque conteneur ajoute ~50 Mo de surcharge RAM. Les VM ont besoin d’un OS complet â facilement 512 Mo minimum.
- Gestion : Les commandes
pctsont plus simples que la gestion des VM pour des charges de travail mono-service. - Sauvegarde : Les sauvegardes de conteneurs sont petites, rapides et peu coûteuses en disque.
La contrepartie est un isolement plus faible par rapport à une VM KVM. Dans un environnement homelab où je suis l’unique opérateur et où tout est sur un réseau de confiance, c’est un risque acceptable. Pour des scénarios multi-locataires ou de production, les VM (ou Kubernetes) seraient le bon choix.
Mode d’Accès SSH
Je n’utilise l’authentification par mot de passe nulle part. Les clés SSH sont injectées à la création du conteneur via le paramètre --ssh-public-keys de Proxmox, qui écrit la clé lors de l’extraction du modèle. Cela signifie :
- Chque conteneur recçot ma clé SSH dC¨s le premier jour
- Pas d’invite de mot de passe, pas de credentials temporaires à faire tourner
- Si un conteneur doit «tre reconstruit, c’est
pct destroy && pct createet je suis de retour en quelques secondes
Documentation
Chaque conteneur, son IP, son adresse MAC, son objectif et uotes les particularités sont documentés dans le dépôt d’infrastructure du laboratoire sur GitHub. C’est crucial à mesure que le laboratoire grandit â j’ai perdu le compte du nombre de fois où J’ai dó m’y référer après ne pas avoir touché à un conteneur pendant six mois.
Les IDs de conteneurs dans Proxmox n’ont aucun rapport avec les adresses IP. J’utilise un document de correspondance qui ressemble à :
ID â Hostname â IP â Rôle
âââââ¼ââââââââââââââ¼âââââââââââââââââ¼ââââââââââââââ
200 â dhcp-srv â 10.99.99.2 â Serveur DHCP
201 â mon-srv â 10.99.99.10 â Surveillance
202 â web-proxy â 10.99.99.11 â Proxy inverse
...
Prochaines Ãtapes
Ce laboratoire est un travail en constant progrès. Les projets à venir incluent :
- Mettre en place des règles de pare-feu appropriées pour le trafic inter-conteneurs
- Automatiser le provisionnement des conteneurs avec Ansible
- Ajouter un deuxième nÅud Proxmox pour la haute disponibilité
- Documenter chaque service en détail (en commençant par l’article sur le DHCP)
Restez à l’ã©coute pour des plongées approfondies dans chaque composant.