Aller au contenu

ADR-003 — Réseau as code : SDN + pare-feu PVE, VLAN 10 natif

Statut : accepté (2026-07-14)

Contexte

La P2 introduit le VLAN 30 « PROD » (10.9.30.0/24) pour isoler les VMs d'applications, et le pare-feu PVE pour protéger l'hôte et les services. Le plan initial prévoyait deux vnets SDN (mgmt VLAN 10, prod VLAN 30).

Décisions

  1. Pas de vnet mgmt : le VLAN 10 reste le VLAN natif du trunk. Les machines existantes (Coolify, dev-laravel, jellyfin, Forgejo, CI…) restent branchées sur vmbr0 sans tag. Re-tagger le VLAN 10 aurait obligé à modifier chaque carte réseau existante et à gérer le cas du trafic natif vs tagué côté Omada, pour zéro gain : seul le VLAN 30 a besoin d'un vnet (prod).

  2. vmbr0 (interface hôte) reste hors OpenTofu. La bascule VLAN-aware se fait à la main pendant une fenêtre de maintenance (runbook P2) : une erreur d'apply sur l'interface qui porte l'IP de l'hôte couperait tout accès, y compris celui qui permettrait de corriger. Le ratio risque/bénéfice est mauvais pour une config qui ne changera plus.

  3. Le pare-feu est déclaré inerte, activé par variable. Tous les objets (ipset mgmt, groupes internal/webpublic/jellyfin, règles hôte) sont créés avec le pare-feu datacenter désactivé ; la bascule est un simple firewall_enabled = true dans terraform.tfvars. La fenêtre de maintenance est ainsi courte et le retour arrière trivial.

  4. Hors périmètre pare-feu par machine : VM 100 Gardien (décommission prévue en P5) et VM 103 contrôleur Omada (ports d'adoption nombreux, codification reportée).

Conséquences

  • Les nouvelles VMs de prod naissent avec bridge = "prod" (le vnet SDN) et une IP statique 10.9.30.x posée par cloud-init.
  • L'isolation PROD → MGMT est portée par l'ACL de la passerelle Omada (config manuelle documentée), pas par le pare-feu PVE : les deux couches se complètent.
  • Si un jour l'infra devient multi-nœuds, la zone SDN lan est déjà cluster-ready (liste nodes à étendre).