Aller au contenu

P2 — VLAN 30 PROD, vmbr0 VLAN-aware et pare-feu

Fenêtre de maintenance pour passer le réseau « as code » : VLAN 30 côté Omada, vmbr0 VLAN-aware, SDN et pare-feu PVE appliqués par OpenTofu.

Durée estimée : 45–60 min. Impact : coupure réseau possible de quelques secondes lors du rechargement de vmbr0 ; aucune VM redémarrée.

État — replanifié, non démarré (2026-07)

Rien n'est encore appliqué. Réseau actuel : deux VLAN seulement, 10 (HomeLab, 10.9.73.0/24) et 20 (perso/IoT, 192.168.20.0/24) — cf. Réseau. Cocher les étapes ci-dessous au fur et à mesure de la fenêtre de maintenance.

Pré-requis (avant la fenêtre)

  • [ ] Backup vzdump de la nuit précédente OK (Datacenter → Backup → journal).
  • [ ] Écran + clavier branchés sur le Proxmox (ou à portée de main) : si la manipulation de vmbr0 se passe mal, c'est le seul moyen de reprendre la main.
  • [ ] Être connecté en local (pas via WireGuard) : l'activation du pare-feu peut couper l'accès distant si le sous-réseau WireGuard n'est pas dans l'ipset mgmt (cf. étape 6).
  • [ ] git pull du dépôt infra à jour sur dev-laravel.
  • [ ] Sauvegarder la config réseau de l'hôte : UI PVE → pve → Shell, coller cp /etc/network/interfaces /etc/network/interfaces.bak puis Entrée.

Étape 1 — Omada : créer le VLAN 30 « PROD »

Dans le contrôleur Omada (VM 103) :

  1. Paramètres (roue dentée) → Réseaux filaires → LAN → Créer un nouveau LAN.
  2. Renseigner :
  3. Nom : PROD
  4. Objet : Interface
  5. VLAN : 30
  6. IP de la passerelle/sous-réseau : 10.9.30.1/24
  7. Serveur DHCP : décoché (les VMs de prod auront des IP statiques posées par cloud-init, comme sur le VLAN 10).
  8. Enregistrer.

Étape 2 — Omada : passer le port du Proxmox en trunk

Le port où est branché le Proxmox doit laisser passer le VLAN 10 non tagué (natif — l'hôte PVE et toutes les machines actuelles) et le VLAN 30 tagué (les futures VMs de prod).

  1. Périphériques → sélectionner l'équipement où le Proxmox est branché (ER605 ou switch) → onglet Ports.
  2. Identifier le port du Proxmox (par la MAC/le nom, ou en débranchant 2 s).
  3. Éditer le port :
  4. Sur un switch Omada : appliquer un profil de port dont le réseau natif est le LAN par défaut (VLAN 10) et où PROD est tagué (créer le profil dans Réseaux filaires → Profils si besoin).
  5. Sur l'ER605 directement : éditer le port LAN et cocher les réseaux : LAN par défaut en Untag, PROD en Tag.
  6. Enregistrer. ✅ Vérifier que l'UI PVE (https://10.9.73.20:8006) répond toujours — le VLAN 10 natif ne doit pas avoir bougé.

Étape 3 — Omada : isoler PROD de MGMT

But : une VM de prod compromise ne doit pas pouvoir attaquer le NAS, le PVE ou le PC.

  1. Paramètres → Sécurité réseau → ACL → onglet ACL de passerelle → Créer.
  2. Règle : Deny, protocole Tous, direction LAN→LAN, source = réseau PROD, destination = réseau LAN (VLAN 10).
  3. Si la version du contrôleur propose une option d'états de connexion (Match State/Stateful), l'activer pour que les réponses aux connexions initiées depuis MGMT vers PROD restent permises. Sinon, la règle bloque aussi ces réponses — on validera le comportement aux tests de l'étape 7 et on ajustera (règle Permit établi au-dessus, ou ACL de switch).

Étape 4 — PVE : passer vmbr0 en VLAN-aware (le moment sensible)

Dans l'UI PVE, connecté depuis le PC (10.9.73.50) :

  1. pve → Système → Réseau → double-clic sur vmbr0.
  2. Cocher VLAN aware.
  3. Recommandé au passage : sortir l'hôte du DHCP — dans la même fenêtre, renseigner IPv4/CIDR = 10.9.73.20/24 et Passerelle = 10.9.73.1 (l'hôte garde la même IP, mais ne dépendra plus du bail DHCP de l'ER605). Si tu fais ça, pense à supprimer la réservation DHCP côté Omada après coup.
  4. OK, puis bouton Apply Configuration (Appliquer la configuration).
  5. L'UI se fige quelques secondes le temps du rechargement réseau, puis revient. Si elle ne revient pas après 2 min : écran + clavier sur l'hôte, et restaurer /etc/network/interfaces depuis /etc/network/interfaces.bak (cp /etc/network/interfaces.bak /etc/network/interfaces && ifreload -a).

✅ Vérifier : UI OK, une app Coolify répond, Jellyfin répond, SSH dev-laravel OK.

Étape 5 — PVE : cocher « Firewall » sur la carte réseau du CT 106

Seule machine où le flag manque (sans lui, les règles par machine sont sans effet) :

  1. CT 106 (jellyfin) → Réseau → double-clic sur net0.
  2. Cocher Pare-feu → OK (appliqué à chaud, pas de redémarrage).

Étape 6 — OpenTofu : appliquer SDN + objets pare-feu (encore inactifs)

Sur dev-laravel, depuis ~/projets/infra :

make plan    # relire : zone SDN lan, vnet prod, ipset, groupes, règles
make apply

Le pare-feu datacenter reste désactivé (firewall_enabled = false) : tout est en place mais inerte. Vérifier dans l'UI : Datacenter → SDN (zone lan, vnet prod), Datacenter → Pare-feu (ipset mgmt, groupes internal, webpublic, jellyfin).

Avant la bascule : vérifier le sous-réseau des clients WireGuard de l'ER605 (Paramètres → VPN → WireGuard). S'il est différent de 10.9.73.0/24, l'ajouter dans l'ipset mgmt (opentofu/firewall.tf, bloc cidr) puis make apply — sinon plus d'UI PVE ni de SSH à distance une fois le pare-feu actif.

Étape 7 — La bascule du pare-feu

Dans opentofu/terraform.tfvars, ajouter :

firewall_enabled = true

Puis make plan (relire : uniquement des changements enabled) et make apply.

✅ Immédiatement après, vérifier dans l'ordre :

  1. UI PVE https://10.9.73.20:8006 depuis le PC → OK
  2. SSH vers dev-laravel, Forgejo (http://10.9.73.81:3000), Woodpecker (http://10.9.73.82:8000) → OK
  3. Une app servie par Coolify (HTTP/HTTPS) → OK
  4. Jellyfin depuis un appareil du VLAN 20 (TV/téléphone en WiFi) → OK

En cas de blocage général : Datacenter → Pare-feu → Options → enable = No (ou depuis la console de l'hôte : pve-firewall stop), puis on corrige à tête reposée et on rebascule.

Étape 8 — Tests d'isolation (critères de fin de P2)

Créer une VM de test sur le VLAN 30 (clone du template 9000, carte réseau sur le vnet prod, IP 10.9.30.10/24, passerelle 10.9.30.1), puis depuis sa console :

Test Attendu
ping 10.9.30.1 (passerelle) ✅ répond
ping 1.1.1.1 puis curl -I https://debian.org ✅ Internet OK
ping 10.9.73.20 / ping 10.9.73.10 ❌ bloqué (ACL Omada)
curl -k https://10.9.73.20:8006 ❌ timeout
ssh 10.9.73.30 ❌ timeout

Et depuis le PC (VLAN 10) : ping 10.9.30.10 → selon l'ACL (si stateless, voir étape 3). Enfin make plan → aucun changement (idempotence).

Supprimer la VM de test une fois validé.