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.

mon-srv (10.99.99.10)

Sécurité et observabilité, et de loin le conteneur le plus sollicité du laboratoire. Grafana, Loki et Prometheus, Grafana Alloy qui collecte les journaux de chaque machine, une instance CrowdSec, un NVR de caméras, et un serveur ntfy pour les notifications push. C’est ce qui consomme le plus de RAM ici — environ 1,5 Go, plus quelques Go de journaux sur disque.

media-srv (10.99.99.13)

Jellyfin pour les films et les séries, et un client torrent qui l’alimente, avec la bibliothèque sur un montage partagé. Le seul conteneur dont tout le foyer remarque l’absence quand il tombe.

dev-srv (10.99.99.20)

Hôte de développement et de compilation. Applications Node.js sous PM2, chaînes d’outils de compilation mobiles, et les copies de travail git. Ce blog vivait ici autrefois ; il a déménagé vers le serveur public, et la copie laissée derrière est une que rien ne sert — un vestige qu’il vaut mieux connaître avant de l’éditer.

vpn-srv (10.99.99.25)

Le serveur de contrôle du tailnet (Headscale) avec une interface web à côté. Chaque nœud rejoint ici, puis parle directement aux autres — le serveur de contrôle n’est pas dans le chemin des données.

wifi-ap (10.99.99.40)

Le point d’accès sans fil, avec la carte WiFi physique passée en direct dans le conteneur. Il exécute hostapd, son propre DHCP et DNS pour le réseau invité, un blocage de publicités au niveau DNS, et un client VPN qui fait sortir le trafic de ce réseau par le tunnel. Le conteneur le plus exotique ici, et le sujet de son propre article.

ai-srv (10.99.99.30)

L’hôte d’automatisation : une passerelle d’agents IA avec sa propre base de données, utilisée pour faire tourner et documenter le laboratoire lui-même. Inclut l’instance Postgres dont les autres services ont pris l’habitude de se servir.

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 pct sont 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 :

Chaque conteneur reçoit ma clé SSH dè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 create et je suis de retour en quelques secondes

Documentation

Chaque conteneur, son IP, son adresse MAC, son objectif et toutes 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 :

De véritables règles de pare-feu inter-conteneurs — le laboratoire tourne encore sur un seul sous-réseau plat
Automatiser le provisionnement des conteneurs, pour qu’une reconstruction soit un playbook plutôt qu’une suite de commandes dont je me souviens à moitié
Des sauvegardes avec un vrai test de restauration. Il y a une distance de travail entre « les conteneurs sont sauvegardés » et « vous en avez restauré un récemment », et ce laboratoire est du mauvais côté
Documenter chaque service en détail — les articles sur le DHCP, la surveillance, le VPN, le WiFi et le pipeline de journaux sont le début

Restez à l’écoute pour des plongées approfondies dans chaque composant.