Segmenter son réseau : zones et VLANs de mon homelab (partie 1)

Pourquoi je te montre mon réseau

Depuis le début de ce blog, on a installé Proxmox, monté un Pi-hole, durci l’hyperviseur. À chaque fois, je t’ai dit quoi faire et pourquoi le faire. Mais il y a un sujet que j’ai gardé en arrière-plan jusqu’ici : le terrain sur lequel tout ça repose. Le réseau lui-même.

Cet article ouvre une nouvelle série consacrée à la sécurité et à l’observabilité du homelab. Et elle commence par une visite guidée de mon propre réseau : son architecture, ses zones, et surtout la logique derrière chaque cloisonnement.

Pourquoi commencer par là ? Parce qu’on ne peut pas sécuriser ce qu’on ne comprend pas, et on ne peut pas surveiller ce qu’on n’a pas structuré. Si tout ton réseau est un grand open space où ta TV connectée, ton NAS, ton PC de travail et l’ampoule connectée du salon se voient tous les uns les autres, aucun outil de sécurité ne rattrapera ça.

La segmentation n’est pas une option avancée pour paranos : c’est la fondation sur laquelle tout le reste de la série va s’appuyer.

Soyons clairs sur ce que cet article est ; et n’est pas. Ce n’est pas un tutoriel. Tu n’y trouveras pas de pas-à-pas pour configurer des VLANs sur OPNsense : ça, c’est le sujet de Créer tes VLAN dans OPNsense.

C’est un article d’architecture : je te montre comment mon réseau est découpé et pourquoi chaque zone existe, pour que tu puisses réfléchir au tien avec les bonnes questions en tête. Ton matériel sera différent du mien, ton découpage aussi. Les questions, elles, sont les mêmes pour tout le monde.

Un mot sur ce que je montre et ce que je ne montre pas. Tu verras le schéma logique complet de mon réseau : les zones, les rôles, les flux.

Tu ne verras aucune capture de ma vraie interface de production — les captures d’interface viendront de mon environnement de démo, avec des adresses d’exemple. Ce n’est pas de la coquetterie : documenter publiquement les détails exacts de son infrastructure réelle, c’est offrir une carte à quiconque voudrait s’y intéresser d’un peu trop près.

Je te montre les principes, pas mon plan de bataille. Et c’est exactement la posture que je te recommande si un jour tu documentes ton propre réseau.

Au programme de la série : après cette visite guidée, on s’attaquera à ce que ce réseau voit — les logs, la détection d’anomalies, les alertes. Parce qu’un réseau bien cloisonné où personne ne regarde ce qui se passe, c’est une maison blindée dont personne ne surveille les caméras.

Le réseau plat : ce que tout le monde a par défaut

Prends une box internet standard, branche tout ce que tu possèdes dessus, et regarde ce que tu obtiens : un réseau plat. Un seul segment, une seule plage d’adresses ip, et tous tes appareils dedans :

• Ton PC de travail,

• ton NAS avec dix ans de photos de famille,

• la TV connectée,

• l’aspirateur robot,

• la prise connectée à 12 € commandée un soir de promo.

Et tous se voient, pas au sens figuré, au sens réseau : chacun peut contacter chacun, scanner les ports des autres, tenter des connexions. C’est le comportement par défaut : à l’intérieur, tout le monde fait confiance à tout le monde.

Cette confiance repose sur une hypothèse jamais vérifiée : celle que chaque appareil est sain et le restera. Or tu ne contrôles ni le firmware de ta TV, ni les serveurs auxquels ta prise connectée parle, ni la politique de mise à jour du fabricant de ton aspirateur. Un seul de ces objets compromis devient un poste avancé à l’intérieur de ton réseau, là où le pare-feu de ta box ne protège plus rien : il garde la frontière avec internet, pas l’intérieur. L’attaquant est dans la maison, et toutes les portes intérieures sont ouvertes.

Tu remarqueras que je n’ai même pas encore parlé de homelab. Ce problème existe chez tout le monde. Mais si tu as suivi les articles précédents, ton cas s’est aggravé :

• ton Proxmox,

• ton Pi-hole,

• tes futurs services auto-hébergés sont autant de cibles de valeur qui, sur un réseau plat, cohabitent avec l’ampoule connectée du salon.

La réponse tient en un mot : segmenter. Découper le réseau en zones étanches, décider explicitement qui a le droit de parler à qui, et refuser tout le reste. C’est ce qu’on va regarder maintenant, zone par zone, sur mon propre réseau.

Le schéma logique : vue d’ensemble

Avant de plonger dans chaque zone, posons la carte. Voici comment mon réseau est construit, de la prise murale jusqu’à l’ampoule connectée.

L’ossature tient en une ligne : la box du FAI ne fait plus que passer-plat. Derrière elle, un pare-feu OPNsense avec deux cartes réseau :

• une côté WAN, branchée sur la box, réservée uniquement à l’accès au web,

• et une côté LAN, branchée sur un switch manageable, dédiée uniquement au réseau local.

C’est OPNsense qui gère tout ce que la box faisait avant : DHCP, DNS, adresses fixes, et surtout les règles de pare-feu entre les zones. La box, elle, ne voit qu’un seul appareil connecté.

Le switch manageable fait le reste : c’est lui qui distribue les VLANs, port par port. Chaque machine branchée atterrit dans sa zone en fonction du port qu’elle occupe. Chaque port du switch a été configuré au préalable pour ne correspondre qu’à un VLAN bien précis.

Pour le sans-fil, un routeur Asus reconverti en simple point d’accès diffuse les réseaux Wi-Fi, chacun rattaché à son VLAN. Un téléphone sur le Wi-Fi perso et une prise connectée sur le Wi-Fi IoT ne se croisent jamais, même s’ils passent par la même antenne. Avant d’installer OPNsense, ce même routeur Asus me servait de pare-feu pour tout mon réseau — j’y reviens un peu plus bas.

Le réseau est découpé en cinq zones :

• Admin — l’accès aux interfaces d’administration : OPNsense, Proxmox, le switch, le point d’accés wifi. La zone la plus sensible du réseau.

• Serveurs — les services qui tournent en continu : les invités de Proxmox (Pi-hole, Jellyfin, Affine, Homarr), et le NAS.

• Perso — les machines du quotidien : PC, téléphones, tablettes. La zone où vivent les humains.

• IoT — les objets connectés : capteurs, prises, ampoules, tout ce qui est bavard et incontrôlable. La zone de quarantaine permanente.

• Démo — mon environnement jetable pour les articles et vidéos de ce blog. Ce que tu vois dans mes captures vit ici, jamais ailleurs.

Deux éléments traversent ce découpage, et on y reviendra en détail : Home Assistant, qui a un pied dans la zone IoT et un pied dans la zone Serveurs. Une exception volontaire au cloisonnement, avec ses raisons et ses risques. Et un tunnel WireGuard, seule porte d’entrée depuis l’extérieur, qui se termine directement sur OPNsense. Les clients qui s’y connectent atterrissent dans leur propre réseau dédié, une zone de plus, soumise aux mêmes règles que les autres : rien n’est accessible par défaut, seules certaines machines le sont, explicitement.** Parce que rien, absolument rien d’autre, n’est exposé sur internet.**

La règle qui gouverne l’ensemble : par défaut, aucune zone ne parle à aucune autre. Chaque flux inter-zones qui existe a été autorisé explicitement, un par un. On regardera ces exceptions en détail plus loin — mais d’abord, faisons le tour des zones, une par une, pour comprendre pourquoi chacune existe.

Zone par zone : le pourquoi de chaque cloisonnement

Une zone n’existe pas parce que c’est joli sur un schéma. Elle existe parce qu’elle répond à une question de confiance : qu’est-ce que je risque si un appareil de cette zone est compromis, et qu’est-ce que je veux qu’il puisse atteindre — ou pas. Voici la carte d’identité des cinq zones, avant qu’on les prenne une par une.

Admin : la salle des machines

Ce qu’on y trouve : les interfaces d’administration d’OPNsense, de Proxmox, du switch et du point d’accès. Autrement dit, les commandes du réseau lui-même. C’est mon infrastructure, avec OPNsense en pare-feu. Mais tu peux tout à fait débuter avec un routeur assez évolué — comme mon Asus — capable de gérer des VLANs et un pare-feu. C’est déjà une très bonne option pour commencer : plus simple à paramétrer, et probablement moins coûteuse. Et ce n’est pas un investissement perdu : si tu évolues plus tard vers un OPNsense, ce routeur se reconvertira en point d’accès Wi-Fi capable de gérer les VLANs — exactement le rôle que joue mon Asus aujourd’hui.

C’est la zone la plus sensible de tout le réseau, et le raisonnement est simple : qui contrôle ces interfaces contrôle tout le reste. Un attaquant qui atteint l’interface d’OPNsense peut réécrire les règles de pare-feu — et tout le cloisonnement dont on parle depuis le début de cet article s’évapore d’un clic. Ces interfaces ne doivent donc être joignables que depuis un endroit précis, jamais depuis le réseau où vivent la TV et les prises connectées, et encore moins depuis internet.

Si tu as suivi les articles sur la sécurisation de Proxmox, tu as déjà durci l’accès à l’hyperviseur : compte dédié, 2FA, pare-feu. La zone Admin, c’est la même logique poussée un cran plus loin — non seulement l’accès est durci, mais le chemin pour y arriver est lui-même restreint.

Serveurs : ce qui tourne en continu

Ce qu’on y trouve : les invités de Proxmox :

• Pi-hole,

• Jellyfin,

• Affine,

• Homarr

• le NAS.

• Home Assistant.

• L’hyperviseur Proxmox lui-même, son interface de gestion, ne vit pas ici mais dans la zone Admin : administrer l’hôte, c’est de l’administration ; ce qu’il héberge, c’est du service.

La question de confiance ici est double. D’abord, ces machines hébergent ce qui a de la valeur : les données. Les photos sur le NAS, les documents dans Affine, les sauvegardes. Ensuite, ce sont des services exposés en interne : le PC de la zone Perso doit pouvoir regarder un film sur Jellyfin ou consulter Homarr. La zone Serveurs est donc celle qui reçoit des connexions entrantes depuis d’autres zones — mais uniquement sur les services prévus, et uniquement depuis les zones prévues.

L’isoler protège dans les deux sens. Si un appareil d’une autre zone est compromis, il ne peut pas se balader librement sur les serveurs : il ne voit que les services explicitement ouverts pour lui. Et inversement, si un service de cette zone était compromis, il ne pourrait pas rebondir vers les machines personnelles ou les interfaces d’administration.

Perso : là où vivent les humains

Ce qu’on y trouve : le PC, les téléphones, les tablettes. Les machines du quotidien.

C’est la zone la plus imprévisible du réseau, parce que c’est celle où l’on fait des choses : on navigue, on clique sur des liens, on installe des applications, on branche des clés USB. Statistiquement, c’est ici qu’une compromission a le plus de chances de commencer — pas par une faille exotique, par un simple clic malheureux.

D’où le cloisonnement : la zone Perso peut consommer les services de la zone Serveurs (Jellyfin, Homarr, le DNS du Pi-hole), mais elle n’a rien à faire dans la zone Admin, et rien à faire dans l’IoT. Si mon PC est compromis demain, l’attaquant se retrouve dans une pièce fermée : il voit les services que je consomme, pas les commandes du réseau.

IoT : la quarantaine permanente

Ce qu’on y trouve : les capteurs Matter et Zigbee, les prises et ampoules connectées, la TV, l’imprimante 3D, et même mes capteurs maison à base d’Arduino.

C’est la zone qui justifie à elle seule toute la démarche de segmentation. Chaque objet connecté du commerce est une boîte noire :

• firmware opaque,

• serveurs inconnus à l’autre bout du monde,

• mises à jour aléatoires quand elles existent. On revient au scénario de la section précédente : l’objet compromis qui devient un poste avancé dans ton réseau. Ici, on ne fait pas confiance, par principe et par défaut.

Alors on enferme. La zone IoT ne peut initier de connexion vers aucune autre zone. La TV ne voit pas le NAS. La prise connectée ne voit pas le PC. L’imprimante 3D ne voit rien du tout. Et tu remarqueras que mes capteurs Arduino faits main subissent exactement le même régime que les objets du commerce : ce n’est pas une question de méfiance envers mon propre code, c’est une question de cohérence. Une règle qui souffre des exceptions « parce que celui-là, je le connais » finit toujours par se déliter.

Démo : le bac à sable de ce blog

Ce qu’on y trouve : un node Proxmox dédié, baptisé HMT, qui n’héberge que des machines jetables.

Cette zone n’a rien à voir avec la sécurité du foyer : elle existe pour ce blog. Tout ce que tu vois dans mes captures d’écran — les interfaces, les adresses, les configurations — vit ici et nulle part ailleurs. Les machines y naissent pour un article et meurent après. Ça me permet de te montrer de vraies manipulations sur de vraies interfaces sans jamais exposer un octet de mon infrastructure réelle. Si tu documentes un jour ton propre homelab publiquement, je te recommande le même réflexe : un environnement dédié aux captures, cloisonné du reste.

Home Assistant : l’exception qui confirme les règles

Reste le cas le plus intéressant du réseau : Home Assistant, le cerveau de ma domotique, qui a un pied dans deux zones à la fois — IoT et Serveurs.

Pourquoi cette entorse ? Parce que Home Assistant a deux vies incompatibles avec un cloisonnement simple. D’un côté, il doit parler aux capteurs, aux prises, aux ampoules : sa place naturelle est dans l’IoT. De l’autre, je dois pouvoir consulter son interface depuis mon PC ou mon téléphone — qui vivent dans la zone Perso et n’ont, on vient de le voir, aucun droit d’entrer dans l’IoT.

La solution paresseuse aurait été d’ouvrir un flux de la zone Perso vers la zone IoT, « juste pour Home Assistant ». C’est exactement le genre de trou qui affaiblit tout le dispositif : un flux ouvert vers la quarantaine. À la place, Home Assistant a deux interfaces réseau : une patte dans l’IoT pour dialoguer avec les objets, une patte dans la zone Serveurs pour être joignable comme n’importe quel autre service. La zone IoT reste hermétique, et Home Assistant se consulte par le même chemin que Jellyfin ou Homarr.

Soyons honnête sur le prix de cette élégance : une machine à cheval sur deux zones est, par construction, un pont potentiel entre elles. Si Home Assistant était compromis, l’attaquant aurait un pied de chaque côté. C’est un risque accepté, nommé, et compensé : c’est précisément le genre de machine qu’il faudra surveiller de près quand on parlera d’observabilité dans la suite de cette série.

Les flux autorisés : qui parle à qui

La segmentation ne vaut que par les règles qui la gouvernent. Chez moi, le principe est le refus par défaut : sur OPNsense, mon firewall, toute communication entre zones est bloquée, sans exception de principe. Chaque flux qui existe a été ouvert explicitement, un par un, avec une raison. Voici les exceptions — la liste complète tient en quelques lignes, et c’est exactement le but.

Perso vers Serveurs : la consommation de services. Les machines du quotidien peuvent atteindre les services prévus pour elles — Jellyfin pour les films, Homarr comme portail, Affine pour les documents. Uniquement ces services, uniquement sur leurs ports. Le reste de la zone Serveurs est invisible depuis le canapé.

Perso, IoT et Démo vers le Pi-hole : le DNS. Les zones du quotidien passent par le Pi-hole pour la résolution DNS — c’est le seul service que même la zone IoT a le droit de joindre, parce qu’un appareil sans DNS ne fonctionne tout simplement pas. Avantage collatéral précieux : le Pi-hole voit les requêtes de ces zones, y compris ce que la TV essaie de contacter. On tient là, sans le savoir encore, le premier outil d’observabilité de cette série. Deux zones font exception et résolvent en direct : Admin et Serveurs. La raison est la même pour les deux — l’infrastructure ne doit pas dépendre d’un service qu’elle est censée faire tourner ou réparer. Le Pi-hole vit dans la zone Serveurs : si l’hyperviseur redémarre ou si le Pi-hole tombe, la zone qui héberge et la zone qui répare doivent continuer à résoudre des noms. Un filtre DNS qui filtre sa propre perfusion, c’est une panne qui s’auto-entretient.

Un PC dédié vers Admin : l’administration. Les interfaces d’OPNsense, de Proxmox et du switch ne sont joignables que depuis une seule machine, identifiée par son adresse IP fixe. Pas depuis toute une zone : depuis un poste précis. Mon PC de tous les jours, celui qui navigue et clique sur des liens, n’a physiquement aucun chemin vers la salle des machines. Celui qui administre ne fait que ça.

WireGuard vers quatre destinations : l’accès distant. Depuis l’extérieur, le tunnel WireGuard donne accès à quatre choses, pas une de plus : l’administration, Affine, Jellyfin et Home Assistant. De quoi réparer un problème à distance, consulter mes documents, regarder un film en déplacement et piloter la domotique loin de chez moi. Les clients VPN ne voient ni la zone Perso, ni l’IoT, ni le reste de la zone Serveurs. Et je le répète, parce que c’est le point le plus important de tout l’article côté exposition : le port WireGuard est la seule porte ouverte sur internet. Pas de Jellyfin exposé, pas d’interface Proxmox accessible en ligne, rien.

IoT vers internet : deux tolérances nominatives. La zone IoT ne peut initier aucune connexion vers les autres zones — ça, c’est acquis. Mais vers internet ? Là aussi, refus par défaut. Seuls deux appareils ont une dérogation : la TV, parce que le streaming ne se fait pas en vase clos, et l’imprimante 3D, ponctuellement, quand elle en a besoin. Tout le reste — capteurs, prises, ampoules, mes montages Arduino — vit intégralement hors ligne. Une prise connectée n’a aucune raison légitime de parler à un serveur à l’autre bout du monde : elle parle à Home Assistant, point. Si un de ces objets était compromis, il ne pourrait même pas téléphoner à la maison.

Une nuance honnête, quand même : ces objets ont parfois besoin de sortir pour se mettre à jour. Mon parti pris est simple — tant que tout fonctionne, je n’y touche pas : tout reste en vase clos. Si un problème apparaît, j’ouvre exceptionnellement l’accès au web le temps de faire la mise à jour depuis Home Assistant, je règle le souci, et je referme dans la foulée. La porte n’est jamais ouverte « au cas où » : elle s’ouvre pour une raison précise et se referme aussitôt.

C’est tout. Cinq familles d’exceptions, chacune justifiable en une phrase. Si tu retiens une seule méthode de cette section, que ce soit celle-là : chaque règle de ton pare-feu doit pouvoir s’expliquer en une phrase qui commence par « parce que ». Une règle que tu ne sais plus justifier est une règle à supprimer.

Ce que ce réseau ne voit pas encore

Arrivé ici, tu pourrais croire que ce réseau est tranquille. Tout est cloisonné, tout est refusé par défaut, chaque exception tient en une phrase. C’est vrai — et c’est très insuffisant.

Parce que segmenter et observer sont deux choses différentes. La segmentation limite ce qu’un attaquant peut faire ; elle ne me dit rien de ce qui se passe. Si une machine se mettait à marteler la zone Serveurs de connexions refusées, OPNsense les bloquerait consciencieusement — et moi, je n’en saurais rien. Les caméras existent pourtant : OPNsense journalise chaque décision, le Pi-hole voit les requêtes DNS de trois zones, Proxmox trace tout. Tout est enregistré, rien n’est regardé. C’est la maison blindée dont personne ne surveille les caméras.

Et certains endroits méritent d’être regardés en priorité. Home Assistant, avec ses deux pattes, pont potentiel entre l’IoT et les Serveurs. La TV et l’imprimante 3D, seules autorisées à sortir vers internet : que contactent-elles, au juste ? Le port WireGuard, unique surface exposée : qui frappe à cette porte ? J’ai des hypothèses pour chacune de ces questions. Je n’ai pas de réponses. C’est exactement la différence entre un réseau structuré et un réseau maîtrisé.

Voilà le programme de la suite : brancher des yeux sur cette architecture. Collecter les logs, apprendre à les lire, distinguer le bruit du signal, se faire alerter quand quelque chose cloche — en auto-hébergé, évidemment. D’ici là, pose-toi la question la plus simple : chez toi, aujourd’hui, qu’est-ce qui peut parler à quoi ? Si la réponse est « tout à tout », tu sais par où commencer.

J’espère que tu y auras appris des choses, et je te dis à très bientôt.

Ta tech, tes règles, ta liberté.