Homelab Proxmox

J’avais l’envie d’avoir un environnement pour pouvoir simuler un suivi de projet en entreprise. Depuis avril 2025, cet objectif m’a permis d’apprendre énormément : la gestion d’environnement, la logique de déploiement, les réflexes à avoir pour anticiper certaines situations.

Je me suis concentré sur la méthode de déploiement, comprendre comment la machine fonctionne, les gestes à éviter ou à privilégier, les moyens d’économiser des ressources, et la réflexion autour d’une infrastructure entière.

J’ai imaginé plusieurs problématiques pour apprendre à déployer différentes solutions avec différentes contraintes. Y répondre m’a appris à moduler mon serveur dédié en fonction de mes besoins. Mais avant de s’attaquer aux déploiements, deux bases sont absolument indispensables : le réseau et le stockage. Si ces deux éléments ne sont pas finement réfléchis, les conséquences peuvent être immédiates ou futures, mais toujours encombrantes.

Une fois ces deux points définis, on peut s’attaquer aux solutions répondant aux besoins : gestion des utilisateurs, déploiement des applications, sécurisation de l’environnement, surveillance des serveurs, et bien d’autres sujets.

Ce temps de travail m’a permis de réaliser qu’une seule personne peut techniquement accomplir toutes ces tâches, mais qu’une équipe de quatre profils serait bien plus efficace : un Responsable Réseau, un Responsable Serveurs (stockage, mémoire, métriques, disponibilité), un Responsable Solutions (voix stratégique, meneur), et un Responsable Documentation. Avec ces quatre personnes, les projets sont mieux menés, l’évolution future économise du temps, de l’argent et des ressources, et les imprévus sont mieux absorbés.

Ce travail m’a également confirmé que la documentation est le cœur même du métier. Si elle est négligée, le projet peut déjà être considéré comme compromis. Elle doit être rédigée avant même de commencer, entretenue au fil de l’avancement, et facilement retrouvable. Son intuitivité doit primer : une documentation ne doit jamais ressembler à une énigme.

1 — Proxmox

Proxmox est l’hyperviseur qui sert de socle à l’ensemble de l’infrastructure. Tout découle de lui : les machines virtuelles, le réseau, le stockage, les services. Avant de déployer quoi que ce soit, deux questions structurantes doivent être résolues.

A — Stockage

Le fait de travailler sur un serveur dédié (hébergé) simplifie la partie physique : l’entretien du matériel est délégué à l’hébergeur. La question du stockage se ramène donc à comment répartir intelligemment l’espace disponible.

Option écartée : NAS virtuel

Une première approche consiste à ouvrir un NAS en machine virtuelle dans Proxmox. Cette solution centralise la gestion du stockage et offre une interface dédiée.

Cependant, elle présente un coût en performance non négligeable : faire transiter le stockage par une VM supplémentaire ajoute une couche d’abstraction coûteuse. De plus, louer un NAS sous forme d’abonnement externe n’a que peu d’avantages sur le long terme : si l’on veut vraiment un NAS, autant en posséder un physiquement.

Solution retenue : allocation progressive

J’ai opté pour une approche plus économe : allouer un minimum de stockage à chaque machine à sa création, puis réallouer au fil du temps selon les besoins réels. Cela permet de toujours disposer d’une marge globale sur l’ensemble du stockage disponible, sans immobiliser des ressources inutilement.

B — Réseau

La gestion réseau sous Proxmox peut prendre plusieurs formes. Deux grandes approches ont été étudiées.

Option écartée : VM Firewall (PfSense)

La première approche consiste à créer une interface réseau dédiée (souvent nommée NAT) pour réaliser du NAT-to-NAT entre l’interface principale vmbr0 (qui fait la liaison avec l’extérieur) et cette interface secondaire.

Cette interface secondaire sert alors de WAN pour un firewall virtualisé, typiquement PfSense. On crée ensuite autant d’interfaces LAN que nécessaire, toutes gérées par PfSense, et on les attribue aux VMs selon les besoins.

Cette solution est intuitive et offre une interface de gestion riche. Elle a cependant un coût : une VM supplémentaire est nécessaire en permanence, ce qui consomme des ressources.

Solution retenue : SDN (Software Defined Network)

Proxmox intègre nativement une fonctionnalité appelée SDN — Software Defined Network, qui permet de gérer le réseau directement au niveau de l’hyperviseur, sans VM intermédiaire.

Le principe repose sur la création de zones et de VNets (équivalents aux interfaces réseau), auxquels on attribue des sous-réseaux. Le résultat : une couche réseau en moins, une VM en moins, et une gestion des redirections de ports simplifiée car tout est centralisé au même niveau.

La prise en main est moins intuitive que PfSense. Elle demande de bien connaître les définitions propres à Proxmox SDN avant d’agir. Mais une fois maîtrisée, elle est plus légère, plus directe, et plus cohérente avec une gestion d’infrastructure moderne.

Redirections de ports

Les redirections de ports sont un point commun aux deux approches, mais leur gestion diffère.

Avec SDN, les règles de redirection (DNAT) sont configurées directement sur le host Proxmox via iptables. Proxmox connaît nativement les VNets et sous-réseaux créés, ce qui rend les redirections cohérentes et centralisées.

Avec PfSense, les redirections doivent être configurées à deux niveaux : sur PfSense d’abord, puis potentiellement sur Proxmox pour les flux qui ne transitent pas par la VM firewall. Cela peut introduire de la confusion si les deux couches ne sont pas parfaitement synchronisées.

Accès distant : WireGuard VPN

Le serveur étant hébergé chez un prestataire externe (et non à domicile), l’accès aux réseaux internes n’est pas possible directement. Sans solution d’accès distant, la seule option serait d’ouvrir des redirections de ports pour chaque service à atteindre — ce qui n’est ni maintenable ni sécurisé.

La solution retenue est WireGuard, un VPN moderne, léger et performant. Il repose sur un système de clés publique/privée : seules les machines dont la clé est reconnue peuvent établir une connexion. Une seule redirection de port suffit pour exposer WireGuard, et même en connaissant ce port, un accès non autorisé est impossible sans la clé correspondante.

WireGuard donne ainsi une présence réseau à l’intérieur de l’infrastructure, depuis n’importe où, avec un niveau de sécurité bien supérieur à une série de ports ouverts en clair.

DNS

Le DNS est le dernier point structurant du réseau. Il remplit deux rôles distincts :

• Vers l’extérieur : permettre aux machines internes de résoudre les noms de domaine publics et d’accéder à Internet.
• En interne : permettre aux machines et aux utilisateurs de résoudre les noms des services internes, plutôt que de mémoriser et manipuler des adresses IP brutes.

Un DNS interne bien configuré est ce qui rend une infrastructure lisible et maintenable à mesure qu’elle grandit.

C — Infrastructure

Une fois le réseau et le stockage configurés, nous pouvons nous attaquer à l’architecture globale. J’ai décidé de gérer les services critiques (DNS et VPN) via des conteneurs LXC Proxmox : ces services ne nécessitent pas la puissance d’une machine virtuelle complète.

Le reste de l’environnement repose pour le moment sur des machines virtuelles Ubuntu Server 2022. J’ai privilégié cette version LTS pour sa stabilité éprouvée par rapport à la version 2024, encore un peu récente pour mon usage.

Les projets sont segmentés par zones. Chaque zone a son propre objectif : présentation personnelle, apprentissage pur, ou bac à sable pour tester de nouvelles technologies et apprendre de mes erreurs.

Zone : Melonlord (Personnel & Outils)

Cette zone est dédiée à mes projets personnels et à mes expérimentations. C’est ici que je monte des environnements de test, que ce soit pour essayer des interfaces graphiques ou pour déployer des conteneurs Docker utiles ou amusants (comme BookStack pour la documentation, Dockge ou Portainer pour la gestion, ou encore Sync-In, une alternative française aux clouds propriétaires).

L’infrastructure repose sur Docker Swarm :

• Une VM “Proxy” agit en tant que Manager (Leader).
• Les autres VMs agissent en tant que Workers pour exécuter les conteneurs.

Bien que je débute en orchestration Swarm, l’outil s’avère puissant et se prête bien à l’automatisation.

Services déployés dans cette zone :

1. Portfolio : Une VM dédiée héberge ce site statique (Hugo), servi par Nginx.

2. Workflow & Automatisation : Une seconde VM hébergera n8n, un outil d’automatisation de flux de travail (workflow). Son premier cas d’usage sera la gestion d’un système d’envoi d’e-mails automatique. J’avais tenté de développer ce projet “from scratch” en code pur, mais mes compétences en développement backend m’ont limité. Je compte reprendre ce projet en me concentrant sur l’interface utilisateur, tout en déléguant la logique complexe d’envoi et de routage au workflow n8n.

3. Automatisation (Ansible) : Je prévois de déployer un conteneur LXC dédié à Ansible. Son rôle sera d’automatiser la création des VMs, leur configuration initiale et leur intégration automatique au cluster Swarm existant. Séparer cet outil de gestion du reste de l’infra est essentiel pour garder une structure propre.

Zone : DMZ (Exposition Publique)

La DMZ a pour unique but d’exposer mes services publiquement via mes noms de domaine.

Pour l’instant, je fonctionne sur le principe d’une machine par nom de domaine. C’est une configuration simple et suffisante pour démarrer, qui évite d’alourdir inutilement cette partie critique du réseau.

Pour la gestion des versions (Prod vs Pré-prod), j’ai opté pour une approche Git simple plutôt qu’une duplication complète de l’infrastructure :

• Une branche secondaire (preprod) pour les tests et la validation sur mon environnement privé.
• La branche principale (main) pour le déploiement public en production.