tuxvador@blog:~/blog/fr/homelab-infrastructure-overview$

~/blog/fr/homelab-infrastructure-overview

Mon Homelab Proxmox VE : Aperçu de l'infrastructure

6 min de lectureMis à jour le Read in English →

#proxmox#homelab#networking#linux#self-hosting

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. C’est un ordinateur portable recyclé, ce qui fait un meilleur serveur de homelab qu’on ne le croit : faible consommation, silencieux, et une carte WiFi que j’ai pu confier à un conteneur.

CPU:     x86-64
RAM:     16 Go (8 Go jusqu'en octobre 2026)
Disque:  NVMe 256 Go, LVM-thin pour les volumes des conteneurs
         + un disque USB de 4 To pour les médias et les sauvegardes
Réseau:  Gigabit Ethernet, bridgé

Deux de ces lignes ont une histoire. 8 Go n’ont pas suffi : les limites des conteneurs totalisaient le double de la RAM physique, l’hôte swappait en permanence, et une grosse compilation l’a figé dix-sept minutes. Doubler la RAM a réglé cela et fait de la place pour un scanner de vulnérabilités. Le NVMe est en train de lâcher, et c’est ainsi que les sauvegardes des conteneurs ont enfin eu un calendrier.

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 le conteneur le plus sollicité du laboratoire. Grafana, Loki et Prometheus, Grafana Alloy qui collecte les journaux de chaque machine, l’API centrale de CrowdSec, un serveur ntfy pour les notifications push, et le contrôleur Ansible qui met à jour le parc. Environ 1,5 Go de RAM, plus quelques Go de journaux sur disque.

soc-srv (10.99.99.15)

Wazuh : un agent sur chaque machine remonte les paquets, les modifications de fichiers et les constats CIS, et le serveur les confronte aux flux de vulnérabilités. C’est le conteneur le plus lourd (6 Go de RAM autorisés, environ 2 Go utilisés), et il n’a tenu qu’après l’ajout de RAM.

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-box (hors de l’hyperviseur)

Le développement, les compilations et l’agent d’automatisation IA étaient deux conteneurs ici. En octobre 2026, ils ont déménagé sur un portable de réserve du réseau domestique : une compilation mobile qui demande 2,5 Go de RAM n’a pas sa place sur la même machine que le DHCP et le reverse proxy. Il rejoint toujours le tailnet, envoie ses journaux et ses métriques à mon-srv et fait tourner un agent Wazuh ; pour la supervision, c’est juste un hôte de plus.

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.

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é. Les mises à jour sont automatisées désormais ; le provisionnement pas encore
  • Un test de restauration. Les conteneurs sont sauvegardés chaque semaine sur le disque USB depuis octobre ; le SSD de remplacement servira de test, avec chaque conteneur restauré dessus
  • Des notifications pour la tâche de sauvegarde, qui ne rapporte aujourd’hui qu’au journal des tâches de Proxmox

Les composants ont leurs propres articles : DHCP, le reverse proxy, le VPN, le point d’accès WiFi, le pipeline de journaux, Wazuh et les mises à jour.

Mis à jour en octobre 2026 : 16 Go de RAM, un conteneur Wazuh, les conteneurs dev et IA déplacés sur une autre machine, et la caméra retirée.

cd ~/blog