Segmenter un homelab comme une vraie prod

Mon homelab a longtemps été un grand /24 bien plat. Tout se voyait, tout se parlait, et le jour où une caméra chinoise a commencé à scanner le réseau à 3 h du matin, j’ai compris : j’avais reconstruit, en miniature, exactement l’angle mort que je passe mes journées à corriger ailleurs.

Un réseau plat, c’est confortable. On branche, ça marche, on passe à la suite. Le problème, c’est que la commodité du jour devient la surface d’attaque du lendemain. Une enceinte connectée, un NAS oublié, un conteneur mal configuré : sur un réseau plat, le premier pied compromis voit toute la maison.

La bascule mentale, c’est d’arrêter de penser « appareils » et de penser « zones ». J’ai découpé en quelques VLAN aux rôles clairs : management (hyperviseurs, switch, IPMI), services de confiance (DNS, reverse proxy, supervision), IoT (tout ce que je ne maîtrise pas), lab (tout ce qui doit pouvoir casser), et une DMZ pour ce qui est exposé. Chaque zone est un sous-réseau, et entre les zones, rien ne passe par défaut.

La vraie discipline n’est pas dans les VLAN, elle est dans la politique de pare-feu. Default-deny partout, puis on ouvre au compte-gouttes, flux par flux, avec une justification pour chacun. Le management ne doit être joignable que depuis le management. L’IoT n’a accès qu’à Internet et à rien d’interne. Le lab peut être détruit sans que ça touche le reste. Écrit comme ça, ça ressemble à une politique de prod, et c’est exactement le but.

table inet zones {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # IoT -> Internet seulement (jamais d'interne)
    iifname "vlan.iot" ip daddr != 10.0.0.0/8 accept
    # Confiance -> services exposés en DMZ
    iifname "vlan.trust" ip daddr 10.0.30.0/24 tcp dport { 443 } accept
    # Management joignable depuis lui-même uniquement (implicite par le drop)
    log prefix "zone-drop " drop
  }
}