Mon projet réseau personnel : Proxmox, pfSense, VPN site-à-site et homelab

Depuis quelque temps, je travaille sur un projet réseau personnel assez avancé. L’objectif n’est pas simplement d’avoir une box Internet et quelques appareils connectés, mais de construire une vraie petite infrastructure réseau, proche de ce que l’on peut retrouver dans un environnement professionnel.

Dans cet article, je vais vous présenter mon projet dans les grandes lignes : virtualisation avec Proxmox, pare-feu avec pfSense, VPN site-à-site, séparation des réseaux, services auto-hébergés, téléphonie IP et sauvegardes.

Par sécurité, je ne vais pas partager les adresses IP exactes, les règles de pare-feu détaillées, les ports ouverts, ni les noms précis de mes machines. L’idée est de vous expliquer le principe et le cheminement, pas de publier une carte complète de mon infrastructure.

Pourquoi faire un projet réseau personnel ?

À la base, ce projet vient d’une envie simple : apprendre en pratiquant.

Quand on s’intéresse au réseau, à la cybersécurité et à l’administration système, la théorie ne suffit pas toujours. On peut lire des cours sur le routage, les VLAN, les VPN, les pare-feu ou la virtualisation, mais tant qu’on ne les met pas en place soi-même, certains concepts restent assez abstraits.

Avec ce projet, je voulais mieux comprendre :

• comment séparer plusieurs réseaux ;
• comment mettre en place un pare-feu ;
• comment relier deux sites distants ;
• comment héberger des services chez soi ;
• comment sécuriser les accès ;
• comment sauvegarder et restaurer des machines virtuelles ;
• comment construire une infrastructure évolutive.

C’est aussi une manière de progresser dans des domaines que j’aime beaucoup : l’infrastructure, le réseau, la cybersécurité et l’auto-hébergement.

L’idée générale du projet

Le principe de mon projet est de relier plusieurs lieux entre eux grâce à un VPN site-à-site.

Chaque site possède son propre réseau interne, protégé par un pare-feu virtuel. Les machines d’un site peuvent communiquer avec les machines de l’autre site, comme si les deux réseaux étaient reliés directement, tout en gardant une séparation propre entre les différents environnements.

De manière simplifiée, l’architecture ressemble à ceci :

Site principal
Box Internet
   ↓
Pare-feu virtuel
   ↓
Réseau interne + serveurs

        VPN site-à-site

Site secondaire
Box Internet
   ↓
Pare-feu virtuel
   ↓
Réseau interne + machines de test

Cette architecture permet de créer un environnement plus propre qu’un simple réseau domestique classique. Chaque partie a un rôle précis, et les accès peuvent être contrôlés plus finement.

Proxmox pour la virtualisation

Le cœur du projet repose en grande partie sur Proxmox.

Proxmox est une solution de virtualisation qui permet de créer et gérer des machines virtuelles et des conteneurs. C’est très pratique pour un homelab, car cela permet de faire tourner plusieurs services sur une seule machine physique.

Dans mon cas, Proxmox me sert à héberger différentes machines virtuelles, par exemple :

• un pare-feu virtuel ;
• des serveurs Linux ;
• des services auto-hébergés ;
• des environnements de test ;
• des outils liés au réseau ou à la supervision.

L’avantage de Proxmox, c’est que je peux créer, supprimer, sauvegarder ou restaurer des machines très facilement. Pour apprendre, c’est idéal, car je peux tester des choses sans forcément casser mon installation principale.

pfSense comme pare-feu virtuel

Pour la partie pare-feu et routage, j’utilise pfSense.

pfSense est une solution de pare-feu basée sur FreeBSD. Elle permet de gérer les règles de filtrage, les interfaces réseau, le NAT, les VPN, le DHCP, le DNS et beaucoup d’autres fonctions.

Dans mon projet, pfSense joue un rôle central. Il permet notamment de :

• séparer le réseau de la box Internet du réseau interne ;
• contrôler les flux entre les différentes zones ;
• gérer les règles de pare-feu ;
• mettre en place le VPN site-à-site ;
• donner plus de contrôle sur l’infrastructure.

Le fait de virtualiser pfSense dans Proxmox est très pratique, car cela évite d’avoir forcément une machine physique dédiée uniquement au pare-feu. Mais cela demande aussi de bien comprendre les interfaces réseau, les ponts virtuels et les cartes réseau utilisées par les machines virtuelles.

Séparer les réseaux pour mieux organiser l’infrastructure

Un point important de mon projet est la séparation des réseaux.

Dans un réseau domestique classique, tous les appareils sont souvent dans le même réseau : ordinateurs, téléphones, imprimantes, objets connectés, serveurs, etc.

Pour un projet plus propre, ce n’est pas idéal. Il est préférable de séparer les usages.

Par exemple, on peut imaginer plusieurs zones :

Réseau principal
Réseau serveurs
Réseau de test
Réseau invités
Réseau administration

Dans mon cas, l’idée est de séparer progressivement les services et les machines selon leur rôle. Cela permet d’éviter qu’un problème sur une machine donne accès trop facilement à tout le reste du réseau.

C’est aussi une bonne manière de se rapprocher de pratiques utilisées en entreprise.

Le VPN site-à-site

L’une des parties les plus intéressantes du projet est la mise en place d’un VPN site-à-site.

Un VPN site-à-site permet de relier deux réseaux distants de manière sécurisée. Contrairement à un VPN classique utilisé depuis un ordinateur ou un téléphone, ici ce sont deux réseaux entiers qui communiquent entre eux.

Concrètement, cela permet par exemple :

• d’accéder à des services hébergés sur un autre site ;
• de joindre des machines distantes comme si elles étaient sur un réseau proche ;
• de centraliser certains services ;
• de faire communiquer plusieurs infrastructures entre elles ;
• de préparer des scénarios de sauvegarde ou de redondance.

Pour mon projet, c’est probablement l’une des parties les plus satisfaisantes. Pouvoir accéder à des machines situées sur un autre site, via une liaison sécurisée, donne vraiment l’impression d’avoir une infrastructure plus professionnelle.

L’accès VPN nomade

En plus du VPN site-à-site, il est aussi possible d’avoir un accès VPN nomade.

Le principe est différent : au lieu de relier deux réseaux entre eux, on permet à un appareil comme un ordinateur portable ou un smartphone de se connecter au réseau à distance.

C’est très pratique pour administrer son infrastructure sans exposer directement les interfaces d’administration sur Internet.

L’idée est simple : au lieu d’ouvrir des accès sensibles publiquement, on se connecte d’abord au VPN, puis on accède aux services internes.

C’est une approche beaucoup plus propre pour accéder à des interfaces comme :

• l’administration des serveurs ;
• les tableaux de bord ;
• les outils de supervision ;
• les machines virtuelles ;
• les interfaces de gestion réseau.

Les services auto-hébergés

Un autre aspect intéressant de ce projet est l’auto-hébergement.

L’auto-hébergement consiste à héberger soi-même certains services, au lieu de dépendre uniquement de services externes.

Dans un homelab, on peut héberger différents types de services :

• un serveur web ;
• un reverse proxy ;
• un serveur de fichiers ;
• un service de sauvegarde ;
• un outil de supervision ;
• un serveur de test ;
• un service de téléphonie IP ;
• un serveur de base de données ;
• des outils pour apprendre et expérimenter.

Dans mon cas, l’objectif n’est pas forcément de tout héberger chez moi, mais plutôt de comprendre comment fonctionnent ces services, comment les sécuriser et comment les intégrer proprement dans une architecture réseau.

Le rôle du reverse proxy

Dans une infrastructure auto-hébergée, le reverse proxy est très utile.

Son rôle est de recevoir les requêtes entrantes et de les rediriger vers le bon service interne.

Par exemple, au lieu d’ouvrir un port différent pour chaque service, on peut utiliser un reverse proxy pour centraliser les accès web et les gérer plus proprement.

Cela permet aussi de gérer plus facilement :

• les certificats HTTPS ;
• les noms de domaine ;
• les redirections ;
• l’accès à plusieurs services web ;
• la séparation entre l’extérieur et les serveurs internes.

C’est un élément important, mais aussi sensible. Il faut éviter d’exposer inutilement des interfaces d’administration ou des services qui n’ont pas besoin d’être accessibles depuis Internet.

La téléphonie IP dans le homelab

J’ai aussi commencé à expérimenter la téléphonie IP avec un serveur Asterisk.

L’idée est de pouvoir créer des extensions téléphoniques internes et de faire communiquer plusieurs appareils entre eux, même sur des sites différents.

C’est un projet intéressant, car il mélange plusieurs notions :

• réseau ;
• routage ;
• téléphonie IP ;
• ports et protocoles ;
• qualité de service ;
• sécurité ;
• VPN.

Même si ce n’est pas forcément indispensable dans un réseau personnel, c’est très formateur. Cela permet de comprendre comment fonctionnent les communications VoIP et comment les intégrer dans une infrastructure plus large.

Les sauvegardes : un point essentiel

Quand on commence à avoir plusieurs machines virtuelles et plusieurs services, les sauvegardes deviennent indispensables.

Un homelab peut être un environnement de test, mais cela ne veut pas dire qu’il faut négliger les sauvegardes. Au contraire, c’est l’occasion parfaite d’apprendre à sauvegarder proprement.

L’objectif est de pouvoir restaurer rapidement une machine en cas de problème.

Les sauvegardes permettent de se protéger contre :

• une mauvaise manipulation ;
• une mise à jour qui se passe mal ;
• une panne disque ;
• une erreur de configuration ;
• une machine virtuelle corrompue ;
• une suppression accidentelle.

Dans mon projet, je souhaite aller vers une organisation où les machines importantes peuvent être sauvegardées et restaurées facilement, notamment entre plusieurs sites.

Ce que ce projet m’a appris

Ce projet m’a permis de progresser sur beaucoup de sujets.

J’ai notamment mieux compris :

• la différence entre un réseau WAN et un réseau LAN ;
• le rôle d’un pare-feu ;
• l’importance des routes statiques ;
• le fonctionnement d’un VPN site-à-site ;
• la différence entre NAT, routage et filtrage ;
• la gestion des interfaces réseau dans Proxmox ;
• l’intérêt de séparer les réseaux ;
• l’importance des sauvegardes ;
• les risques liés à l’exposition de services sur Internet.

Ce genre de projet est très formateur, parce qu’on se retrouve rapidement confronté à de vrais problèmes : une route manquante, une règle de pare-feu trop restrictive, un mauvais plan d’adressage, un service inaccessible, ou encore un comportement réseau que l’on ne comprend pas tout de suite.

Et c’est justement en cherchant à résoudre ces problèmes que l’on apprend le plus.

Les difficultés rencontrées

Tout n’a pas fonctionné du premier coup.

Dans ce type de projet, il y a forcément des moments où quelque chose ne répond pas, où un paquet ne passe pas, où une règle bloque le trafic, ou où une machine n’est pas joignable alors qu’elle devrait l’être.

Les difficultés les plus fréquentes concernent souvent :

• les routes ;
• les règles de pare-feu ;
• les interfaces réseau ;
• les redirections de ports ;
• le VPN ;
• le DNS ;
• la différence entre ce qui est accessible en local et ce qui est accessible à distance.

Ce sont parfois des problèmes frustrants, mais ils sont aussi très utiles pour progresser. On apprend à diagnostiquer, à vérifier les flux, à tester étape par étape et à ne pas modifier trop de choses en même temps.

Pourquoi je ne partage pas toute ma configuration

Même si ce projet est intéressant à présenter, je ne souhaite pas publier toute ma configuration exacte.

Un réseau personnel reste une infrastructure privée. Donner trop de détails pourrait représenter un risque de sécurité.

C’est pour cette raison que je ne partage pas :

• les adresses IP exactes ;
• les ports exposés ;
• les règles de pare-feu complètes ;
• les noms internes des machines ;
• les captures d’écran détaillées de mes interfaces d’administration ;
• les clés ou paramètres VPN ;
• les chemins d’accès précis aux services sensibles.

L’objectif de cet article est de partager un retour d’expérience, pas de fournir une carte détaillée de mon réseau.

C’est une règle importante à garder en tête lorsqu’on parle de cybersécurité ou d’infrastructure en ligne : on peut expliquer le fonctionnement global sans dévoiler les informations qui pourraient aider quelqu’un à cibler l’environnement.

Les prochaines évolutions possibles

Ce projet est encore amené à évoluer.

Parmi les pistes possibles, il y a :

• améliorer la segmentation réseau ;
• ajouter de la supervision ;
• mettre en place des sauvegardes plus propres ;
• documenter l’infrastructure ;
• renforcer la sécurité des accès distants ;
• tester de nouveaux services ;
• améliorer la redondance ;
• continuer à expérimenter la téléphonie IP ;
• mieux organiser les services auto-hébergés.

Le but n’est pas d’avoir une infrastructure parfaite du premier coup, mais de construire progressivement quelque chose de propre, utile et formateur.

Conclusion

Ce projet réseau personnel me permet d’apprendre énormément de choses en conditions réelles.

Avec Proxmox, pfSense, un VPN site-à-site, plusieurs réseaux internes et des services auto-hébergés, j’ai pu mettre en place une infrastructure beaucoup plus avancée qu’un réseau domestique classique.

Ce n’est pas un projet terminé, mais c’est justement ce qui le rend intéressant. Il évolue au fur et à mesure de mes besoins, de mes tests et de mes apprentissages.

Pour moi, c’est une excellente manière de progresser en réseau, en virtualisation, en administration système et en cybersécurité.

Le plus important reste de garder une approche sécurisée : documenter, sauvegarder, séparer les réseaux, limiter les accès exposés et ne jamais publier d’informations sensibles sur son infrastructure.