Homelab Phases 1 à 3 : Segmentation VLAN d'un réseau domestique

⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Cet article est le premier d’une série documentant la refonte complète de mon homelab. L’objectif : transformer un réseau domestique à plat en une infrastructure segmentée, proche de ce qu’on trouve dans une PME correctement sécurisée. Les détails techniques (configs, règles firewall, structure des alias) sont disponibles sur GitHub, ici je me concentre sur la démarche, les décisions d’architecture et les pièges rencontrés.

Point de départ : Un réseau à plat, c’est quoi le problème ?

Avant ce projet, tout mon réseau tenait sur un seul segment. Mon NAS Synology, mes trois hyperviseurs Proxmox, la borne WiFi, les caméras de surveillance, les thermomètres connectés, les modules domotique, mon Mac de travail, tout au même niveau, sans aucune isolation.

Concrètement, ça signifiait : si un objet IoT est compromis (un firmware vérolé sur une caméra par exemple), l’attaquant se retrouve directement sur le même réseau que mes serveurs et mon poste d’administration. Aucune barrière.

Phase 1 : Audit et conception de l’architecture

La première règle : cartographier avant de toucher quoi que ce soit

Avant de configurer la moindre règle, j’ai passé du temps à documenter précisément l’existant :

• Inventaire de tous les équipements et leurs adresses MAC/IP
• Services exposés sur le réseau
• Flux existants, qui parle à qui, sur quels ports

C’est l’étape qu’on est tenté de sauter, et c’est celle qui coûte le plus cher si on la néglige. Dans mon cas, j’ai découvert des services oubliés, des IPs dynamiques sur des équipements qui auraient dû être en statique, et des ports applicatifs non documentés (client mail, synchronisation NAS, stack monitoring) qui se sont révélés manquants au moment de la migration.

La leçon : lister tous les flux applicatifs avant de toucher une règle firewall. Chaque oubli se traduit par un service cassé après la bascule.

L’architecture cible : 5 zones de confiance

J’ai défini cinq VLANs correspondant à des niveaux de confiance distincts :

La logique : le poste de travail peut accéder aux interfaces d’admin et au NAS, mais pas aux IoT. Un appareil IoT compromis ne peut accéder à rien d’autre, ni administration, ni NAS, ni serveurs.

Parallèle entreprise : c’est exactement l’architecture d’une PME correctement sécurisée, réseau utilisateurs, réseau serveurs, réseau management, réseau IoT, DMZ pour les services exposés.

Phase 2 : Configuration pfSense

La logique des alias : travailler proprement

Plutôt que d’écrire des règles firewall avec des valeurs en dur, j’ai structuré la configuration en trois couches d’alias :

1. Alias réseau : les plages IP par zone
2. Alias ports simples : chaque service sur son port
3. Alias ports groupés : regroupements logiques (tous les ports admin, tous les ports internet sortants…)

Quand un port change, on modifie l’alias une seule fois, toutes les règles qui l’utilisent sont automatiquement mises à jour. C’est le même principe qu’une table de référence dans une base de données.

Les règles firewall : principe du moindre privilège

Pour chaque VLAN, j’ai défini des règles en partant du plus restrictif : tout bloqué par défaut, puis ouverture explicite de ce qui est nécessaire.

Un point souvent sous-estimé : le DNS doit être explicitement autorisé dans chaque VLAN, y compris les VLANs “serveurs”. pfSense évalue ses règles firewall même pour le trafic qui lui est destiné, sans règle DNS, les machines obtiennent une IP DHCP mais ne peuvent résoudre aucun nom. Symptôme classique : ping 8.8.8.8 fonctionne, ping google.com échoue. Pour VLAN_SERVICES en particulier, cette règle conditionne le fonctionnement de tous les services cloud Synology (QuickConnect, DDNS, Drive), elle doit être placée en première position.

L’ordre des règles est critique. Sur VLAN_LAB par exemple, la règle qui autorise Promtail à pousser ses logs vers Loki doit être placée avant les règles de blocage, sinon les logs ne passent jamais.

DNS interne avec Unbound

J’ai créé des entrées DNS internes pour tous les équipements (pfsense.homelab.local, proxmox1.homelab.local, nas.homelab.local, grafana.homelab.local…). Deux avantages : accès par nom au lieu d’IP, et si une IP change lors de la migration VLAN, une seule modification dans Unbound suffit.

Règle Floating pour les mises à jour système

pfSense est à la fois le routeur qui applique les règles et une machine qui doit se mettre à jour. Son trafic sortant passe directement par WAN, pas par ses propres interfaces VLAN. Une règle Floating spécifique est nécessaire pour lui permettre d’atteindre internet.

Phase 3 : Configuration MikroTik CRS310

Le mécanisme central : Bridge VLAN Filtering

Sur MikroTik RouterOS, la gestion des VLANs passe par le Bridge avec le VLAN Filtering activé. Le bridge est l’interface logicielle qui pilote la puce switch matérielle, activer le VLAN Filtering, c’est dire au bridge d’appliquer les règles VLAN sur chaque port.

Point de vigilance critique : une fois le VLAN Filtering activé, il s’applique immédiatement sur tous les ports. Si la configuration n’est pas correcte au moment de l’activation, on perd l’accès au switch.

La préparation avant la bascule

Tout doit être configuré avant d’activer le VLAN Filtering :

1. VLANs créés avec les bons ports Tagged/Untagged
2. PVID configurés sur les ports access
3. IP de management dans le VLAN d’administration, sans ça, le switch devient injoignable après la bascule
4. Borne WiFi configurée avec les bons SSIDs et VLAN IDs : si on oublie ça, tous les appareils WiFi perdent internet au moment de l’activation

Sur ce dernier point, la stratégie adoptée : conserver le SSID existant avec son mot de passe pour le réseau IoT. Les dizaines d’objets connectés se reconnectent automatiquement sans aucune manipulation. Seuls les PC et smartphones ont besoin d’être reconnectés sur le nouveau SSID. Un gain de temps considérable.

Les pièges rencontrés

Le bridge absent du VLAN de management : pour que l’IP de management du switch soit joignable, il faut ajouter bridge lui-même dans la liste Tagged du VLAN 20. Ce n’est pas documenté clairement dans la doc officielle MikroTik.

L’accès à SRM de la borne Synology en mode Bridge : en mode AP, Synology restreint l’accès à son interface web aux connexions directes sur les ports LAN de la borne, pas depuis le réseau upstream. Solution retenue : accès via câble direct avec un PC portable si nécessaire, ce qui est rare en pratique.

Résultat : Ce qui fonctionne maintenant

• Segmentation active : 5 VLANs opérationnels, chaque équipement dans sa zone
• Règles firewall structurées : principe du moindre privilège appliqué sur chaque interface
• DNS interne : tous les équipements accessibles par nom
• WiFi segmenté : deux SSIDs sur deux VLANs distincts, migration IoT transparente
• Monitoring actif : Prometheus, Grafana, Loki opérationnels post-migration

Post-migration : Les problèmes qu’on ne voit pas venir

Même avec une bonne préparation, deux points se sont révélés en pratique lors de la migration des équipements.

1. Les ports dynamiques IoT et NAS : changer d’approche

J’avais d’abord tenté d’énumérer les ports nécessaires pour les caméras IoT et les services Synology (MQTT, streaming, QuickConnect…). C’est une bataille perdue, les fabricants utilisent des dizaines de ports différents, parfois aléatoires, parfois variables selon la région ou la version du firmware.

La bonne approche : autoriser la sortie internet sur tous ports vers !RFC1918. La sécurité ne repose pas sur le filtrage des ports sortants, elle repose sur l’isolation des réseaux internes. Un appareil IoT compromis peut contacter internet librement, mais il ne peut pas atteindre le NAS, les serveurs ou les interfaces d’administration. C’est ce qu’on cherche.

2. Le port 6690 : Synology Drive silencieux

Synology Drive (synchronisation de fichiers) utilise le port 6690 distinct du port DSM. DSM fonctionnait parfaitement, mais la synchronisation Drive échouait sans message d’erreur clair depuis le Mac. Une lecture des logs firewall a immédiatement identifié le port bloqué.

Réflexe à avoir : quand un service Synology ne fonctionne pas après migration, ouvrir les logs firewall en filtrant sur l’IP du NAS. La réponse est toujours là.

• Migration Proxmox, adaptation des bridges réseau pour les VLANs
• Mise à jour configs Docker, variables d’environnement, secrets externalisés
• Authentification renforcée, 2FA sur toutes les interfaces d’administration
• DHCP statique pour tous les équipements fixes

Ce que j’en retiens

La cartographie des flux avant tout. Avant de toucher la moindre config, lister tous les services qui ont besoin de communiquer. Chaque oubli se traduit par un service cassé après la migration, client mail, synchronisation de fichiers, monitoring, tout doit être anticipé.

Le DNS dans chaque VLAN, sans exception. C’est la règle la plus impactante, elle conditionne le fonctionnement de tous les services applicatifs, y compris les services cloud comme QuickConnect ou DDNS.

La segmentation IoT et SERVICES : sécurité = isolation, pas filtrage de ports. Autoriser tous les ports sortants vers internet est la bonne décision architecturale. La protection vient de l’isolation des réseaux internes.

La segmentation ne rend pas un réseau parfait, elle le rend raisonnable. Un appareil IoT compromis reste confiné dans son VLAN. C’est exactement ce qu’on cherche.

Le homelab comme maquette d’entreprise. Ce que j’ai mis en place ici reproduit fidèlement ce qu’on trouve dans une PME correctement sécurisée, segmentation par zone de confiance, principe du moindre privilège, DNS interne, monitoring centralisé. C’est ce qui donne du sens à chaque choix technique au-delà du simple “ça marche”.

Code source et documentation technique : Repo GitHub, Projet Segmentation Homelab, structure des alias, règles firewall par VLAN, config MikroTik, troubleshooting