Introduction

À l'ère du télétravail et des services cloud, disposer d'une infrastructure réseau domestique performante n'est plus un luxe, mais une nécessité. Cet article retrace mon parcours pour transformer un réseau domestique basique en une architecture robuste, inspirée des meilleures pratiques des startups technologiques.

1. Pourquoi structurer le réseau de son Home Lab ?

Objectifs

  • Efficacité : Assurer une connectivité stable pour le télétravail et les services en ligne.
  • Sécurité : Protéger les données personnelles et professionnelles contre les menaces externes.
  • Scalabilité : Permettre l'ajout de nouveaux services sans perturber l'existant.

Constat initial

Le réseau initial était rudimentaire : une simple box Internet avec Wi-Fi activé, connectée à un PC fixe que j'utilisais comme poste de développement principal. C'était l'époque où je travaillais en local sur la version monolithique de mon application Avuru Vision. Rapidement, le besoin de rendre l'application accessible à tous les membres de la famille, depuis n'importe quel appareil et dans toutes les pièces de la maison, s'est imposé. Il devenait évident qu'il fallait construire un réseau digne de ce nom, stable, performant et centralisé.

Décision stratégique

Plutôt que de multiplier les compromis, j'ai opté pour une refonte complète du réseau, en m'inspirant des architectures des systèmes d'information d'entreprise, adaptées à un usage domestique.

2. Câblage structuré, simulation réseau et infrastructure physique

Équipement central

Lorsque j’ai acquis ma maison de 1940 à rénover intégralement, j’ai vu l’opportunité d’intégrer dès le départ un réseau structuré, à la fois moderne et sécurisé. Lors de la remise à neuf de l’installation électrique, j’ai commandé l’ajout de prises RJ45 dans chaque pièce, avec du câble catégorie 7, pour répondre aux futurs besoins numériques : télétravail, domotique, streaming, CI/CD, etc.

La maison a été raccordée à la fibre optique via la box Internet du fournisseur, configurée en mode bridge pour déléguer la gestion réseau à une UniFi Dream Machine Pro (UDM Pro). Celle-ci centralise le pare-feu, le routage, les VLANs et le VPN WireGuard.

Trois switches assurent la distribution du réseau :

  • Un switch pour les équipements domestiques en VLAN non taggé (Main/Guest).
  • Un switch pour les VLANs taggés du LAB (DevOps, Management, CCTV...).
  • Un switch PoE pour alimenter les caméras IP et les bornes Wi-Fi UniFi.

Simulation préalable

graph TD
    Internet[Fibre]
    Box["Box opérateur (mode bridge)"]
    UDM["UniFi Dream Machine Pro"]
    SW1["Switch Main/Guest"]
    SW2["Switch LAB (VLAN taggés)"]
    SW3["Switch PoE (Wi-Fi / CCTV)"]
    AP["Bornes UniFi"]
    NAS["NAS Perso"]
    Cam["Caméras IP"]

    Internet --> Box
    Box --> UDM
    UDM --> SW1
    UDM --> SW2
    UDM --> SW3
    SW1 --> NAS
    SW3 --> AP
    SW3 --> Cam

J'ai simulé l'architecture complète avec Cisco Packet Tracer, validant les flux, les tags VLAN, les politiques de sécurité et les routages inter-VLAN. Objectif : une architecture documentée, cohérente et sans surprises.

3. UDM Pro, Wi-Fi UniFi et segmentation VLAN

Une fois l’infrastructure physique en place, il fallait un cœur réseau capable de centraliser les fonctions critiques tout en restant simple à administrer.

UDM Pro : le cerveau du réseau

udmpro-dashboard.JPG

Tableau de bord de l’UDM Pro – trafic, menaces et performances réseau

L’UniFi Dream Machine Pro (UDM Pro) joue ce rôle central avec brio. Elle remplit plusieurs fonctions réseau essentielles, normalement assurées par des équipements professionnels séparés :

  • Routeur principal avec capacité de routage inter-VLAN
  • Pare-feu configurable avec règles fines
  • Contrôleur UniFi intégré (gestion Wi-Fi, switches, policies)
  • Serveur DHCP multi-VLAN
  • Serveur VPN WireGuard pour les accès distants sécurisés

Grâce à cette centralisation, la gestion réseau est unifiée, simple à auditer et facile à faire évoluer. La console UniFi permet une visualisation en temps réel de tous les équipements et des flux.

Wi-Fi segmenté : chaque usage son VLAN

flowchart LR
    AP["UniFi Access Point"]

    SSID_Pro["SSID Pro"]
    SSID_Guest["SSID Guest"]
    SSID_IoT["SSID IoT"]

    Pro["Pro (192.168.135.0/24)"]
    Guest["Guest (192.168.79.0/24)"]
    IoT["IoT (192.168.110.0/24)"]

    %% Connexions AP → SSID
    AP --> SSID_Pro
    AP --> SSID_Guest
    AP --> SSID_IoT

    %% Mappage SSID → VLAN / Sous-réseau
    SSID_Pro -- "VLAN 135" --> Pro
    SSID_Guest -- "VLAN 79" --> Guest
    SSID_IoT -- "VLAN 10"  --> IoT

Les bornes UniFi, reliées au switch PoE, diffusent plusieurs SSID Wi-Fi, chacun mappé dynamiquement vers un VLAN spécifique :

  • SSID Pro → VLAN 135 (accès sécurisé pour le télétravail)
  • SSID Guest → VLAN 79 (accès Internet uniquement)
  • SSID IoT → VLAN 10 (périphériques connectés)

Cette association automatique permet aux appareils de rejoindre leur bon segment réseau sans configuration manuelle. On renforce ainsi la sécurité tout en assurant une connectivité fluide et cohérente avec la politique de segmentation définie.

4. Segmentation logique via VLANs

Évolution logicielle d’Avuru Vision

Initialement, Avuru Vision était développé comme une application monolithique hébergée en local sur le PC principal. Mais avec la mise en place du LAB, le projet a évolué vers une architecture microservices déployée sur un cluster Kubernetes interne. Ce découpage a permis d’isoler les composants critiques (authentification, gestion des tâches, traitement de documents, etc.) dans des services dédiés, chacun pouvant être maintenu, testé et mis à jour indépendamment.

La transition a aussi facilité l’implémentation de pipelines CI/CD automatisés, la mise en cache des builds, la surveillance applicative via Prometheus/Grafana, et une exposition sécurisée via ingress NGINX.

Ce changement architectural a naturellement renforcé le besoin d’une segmentation réseau adaptée, afin d’isoler les flux métiers des flux systèmes et des accès invités ou publics.

Pourquoi segmenter ?

  • Sécurité : Cloisonner les flux évite les compromissions croisées.
  • Performance : Moins de congestion entre flux critiques.
  • Simplicité : Politiques lisibles.
  • Scalabilité : Évolution modulable.

Tableau des VLANs

graph TD
    Main["VLAN 78 – Main"]
    Guest["VLAN 79 – Guest"]
    Pro["VLAN 135 – Pro"]
    LAB["VLAN 140 – LAB"]
    IoT["VLAN 10 – IoT"]
    CCTV["VLAN 120 – CCTV"]
    Mgmt["VLAN 5 – Management"]
    VPN["VLAN 20 – VPN WireGuard"]

    classDef public fill:#f9f,stroke:#333,stroke-width:1px;
    class Guest,IoT,CCTV public;
VLAN Nom Sous-réseau Usage
5 Management 192.168.5.0/24 iDRAC, switches, ESXi
10 IoT 192.168.110.0/24 Domotique, assistants connectés
120 CCTV 192.168.120.0/24 Caméras IP, flux vidéo
135 Pro 192.168.135.0/24 VPN, télétravail, outils de bureau
78 Main 192.168.78.0/24 NAS, PC perso
79 Guest 192.168.79.0/24 Wi-Fi visiteurs, Internet only
140 LAB 192.168.140.0/24 GitLab, Jenkins, K8s, Nexus
20 VPN 192.168.20.0/24 Accès distant WireGuard

udmpro-capture.JPG

Carte des périphériques UniFi – topologie réseau et affectation VLAN

5. Règles de pare-feu inter-VLAN

Une politique de sécurité proactive

Dans une architecture segmentée, le pare-feu devient la pièce maîtresse du contrôle des flux. Pour garantir l’isolation et la sécurité des différents VLANs, j’ai appliqué une politique stricte fondée sur le principe du "zero trust".

  • Par défaut : tout est interdit (deny all by default).
  • Puis, autorisation explicite uniquement pour les flux nécessaires, documentés et maîtrisés.

Cette approche minimise la surface d’attaque, limite les comportements non prévus, et rend les règles plus lisibles.

Exemples de règles concrètes

flowchart LR
    LAB -->|HTTPS only via reverse proxy| Main
    Pro -->|NAS backup| Main
    IoT -.->|Internet only| Internet[🌍 Internet]
    Mgmt -->|Local only, restricted IPs| Admin[Admin Devices]
  • Le VLAN Pro (télétravail) peut accéder au VLAN Main pour réaliser les sauvegardes régulières vers le NAS familial.
  • Le VLAN LAB, qui héberge les outils CI/CD et K8s, accède au VLAN Main uniquement via le reverse proxy NGINX (HTTPS). Cela permet une exposition maîtrisée des services, sans accès direct aux machines.
  • Le VLAN IoT est totalement isolé du reste du réseau : il ne peut accéder qu'à Internet, et uniquement selon des règles de sortie filtrées.
  • Le VLAN Management (ESXi, switches, iDRAC...) est accessible uniquement depuis le réseau local via des équipements authentifiés, avec des règles très restrictives sur les plages IP autorisées. Aucune exposition directe à Internet n’est possible, même sans VPN.

6. DNS & DHCP locaux

DNS local : de dnsmasq à PowerDNS

Au départ, j’utilisais dnsmasq comme solution DNS/DHCP minimaliste. Simple à déployer et légère, elle s’intègre bien pour les réseaux familiaux basiques. Cependant, dnsmasq montre rapidement ses limites dans un contexte Home Lab avancé où l’on souhaite :

  • Gérer plusieurs zones DNS internes
  • Intégrer des mises à jour dynamiques
  • Travailler dans un environnement déclaratif, versionné, piloté par des pipelines CI/CD

C’est pourquoi j’ai migré vers PowerDNS, une solution bien plus évolutive.

Comparatif rapide :

Fonctionnalité dnsmasq PowerDNS
Zones DNS autoritaires ❌ Non (forward only) ✅ Oui
Backend en base ❌ Non ✅ Oui (MySQL, SQLite…)
API REST intégrée ❌ Non ✅ Oui
Mise à jour via CI/CD ❌ Non ✅ Compatible
Gestion multi-zones ❌ Limitée ✅ Native

Pourquoi PowerDNS ?

  • Pour héberger mes propres zones : *.devops.lab *.k8s.lab.
  • Pour automatiser l'ajout/suppression d’enregistrements via CI/CD (scripts + API REST)
  • Pour garder une visibilité et un contrôle total sur la résolution interne des services

Mise en place technique

Le lab utilise PowerDNS avec une base de données PostgreSQL comme backend. Deux services distincts sont en place :

  • PowerDNS Authoritative Server : pour la résolution des domaines internes au LAN (enregistrement des services, machines, etc.)

  • PowerDNS Recursor : pour résoudre les domaines externes (internet), en amont du cache local.

Cette architecture permet d'assurer une séparation nette entre le DNS interne (maîtrisé, surveillé) et le DNS externe (résolu dynamiquement), tout en profitant d'une gestion centralisée des zones via PostgreSQL. Provisionné via Ansible sur la VM vminfra.

Exemples de noms utilisés :

  • jenkins.devops.lab gitlab.devops.lab nexus.devops.lab
  • ghost.k8s.lab nginx.k8s.lab

Cette approche permet une gouvernance DNS cohérente, contrôlée, déclarative, et alignée avec les meilleures pratiques DevOps.

DHCP centralisé

Le service DHCP est assuré par l’UDM Pro :

  • Un pool d’adresses IP par VLAN, avec des plages bien délimitées
  • Des baux statiques attribués aux services critiques (NAS, caméras, cluster K8s)

Cela garantit une affectation IP prévisible, cohérente avec les règles de pare-feu et la supervision du réseau.

7. Exposition sécurisée via Reverse Proxy

Pourquoi exposer des services depuis chez soi ?

Dans un Home Lab moderne, certains services doivent être accessibles depuis l'extérieur : dashboard d’observabilité, blog personnel, ou outils de développement. Mais cette ouverture doit rester strictement encadrée.

J’ai choisi une approche DMZ avec reverse proxy NGINX, pour contrôler finement ce qui est exposé, comment et à qui.

Architecture de publication externe

Le reverse proxy est placé dans un VLAN dédié, avec accès restreint aux seuls services explicitement exposés.

Il prend en charge :

  • La terminaison TLS via Let's Encrypt (certificats automatiques)

  • Le routage HTTP/S vers les bons services internes

  • Le filtrage fin basé sur :

    • noms de domaine (SNI)
    • chemins (URI)
    • méthodes HTTP

Cette configuration permet de limiter les vecteurs d’attaque tout en gardant un contrôle précis sur les points d’entrée du réseau.

Gestion de l’IP dynamique et accès externe

Mon fournisseur d'accès n'attribue pas d'adresse IP fixe. Pour rendre certains services accessibles depuis l'extérieur, j'utilise No-IP comme service de DNS dynamique. Un agent installé sur une machine du réseau met à jour automatiquement l'IP publique liée à mon nom de domaine (ex. blog.egilberny.com).

Pour que les requêtes extérieures atteignent l’UDM Pro, j’ai mis en place une redirection de ports (port forwarding) sur la box Internet. Elle transmet le trafic entrant (HTTP/HTTPS) directement vers le reverse proxy dans la DMZ.

Ce mécanisme me permet de garder un accès stable à mes services auto-hébergés, même si l’IP publique change régulièrement.

Exemples de redirection

graph TD
    Visitor["Visiteur externe"]
    NoIP["blog.egilberny.com (No-IP)"]
    Box["Box Internet (port fwd)"]
    RP["NGINX Reverse Proxy (DMZ)"]
    Ghost["ghost.lab.internal"]
    Grafana["grafana.lab.internal"]

    Visitor --> NoIP
    NoIP   --> Box
    Box    --> RP
    RP     --> Ghost
    RP     --> Grafana
  • blog.egilberny.com → ghost.lab.internal
  • grafana.egilberny.com → grafana.lab.internal

Conclusion

Mettre en place un réseau domestique digne d’une startup, c’est bien plus qu’un simple défi technique : c’est une manière d’aligner son environnement personnel avec les standards professionnels.

Grâce à une architecture pensée dès la rénovation de la maison, une segmentation réseau rigoureuse, des services internes automatisés, et une exposition externe contrôlée, j’ai pu créer un Home Lab :

  • Sécurisé, grâce à une politique Zero Trust, un DNS interne et des VLANs bien isolés.
  • Automatisé, avec des pipelines CI/CD qui gèrent DNS, déploiements et supervision.
  • Accessible, même avec une IP dynamique, tout en restant sous contrôle.
  • Évolutif, pour tester en conditions réelles des approches DevSecOps modernes.
  • Familial, car le réseau reste fluide et utilisable pour tous les membres du foyer.

Chaque choix d’équipement ou de configuration répond à une problématique concrète, en gardant l’équilibre entre performance, simplicité et ambition.

Et vous ?

Vous rêvez de bâtir un Home Lab qui combine UDM Pro, switch PoE, VLAN et routage « zero-trust » ?
Vous hésitez encore sur le meilleur matériel ou la bonne façon de segmenter votre réseau ?

Partagez vos questions, vos échecs, vos succès – tout retour est bienvenu dans les commentaires !

Références clés pour aller plus loin