Le réseau est le truc que tout le monde configure une fois, ça marche, et on n’y retouche plus pendant deux ans – jusqu’au jour où un nouveau service doit être isolé des autres et on réalise qu’on a tout mis dans le même VLAN depuis le début. J’ai fait exactement ça, et la migration a été pénible.
Ce guide couvre la configuration réseau que j’aurais voulu avoir dès le départ.
Comment Proxmox voit le réseau
Proxmox pose un Linux bridge (vmbr0) sur l’interface physique principale. C’est l’équivalent d’un switch virtuel interne. Chaque VM et LXC obtient une interface virtuelle connectée à ce bridge. Le bridge lui-même reçoit l’IP du nœud Proxmox.
Câble réseau LAN (2.5GbE → enp2s0)
│
[vmbr0] 192.168.1.10/24 ← IP du nœud Proxmox
├── LXC 150 (eth0) → 192.168.1.150
├── LXC 200 (eth0) → 192.168.30.200
└── VM 300 (virtio0) → 192.168.30.300
C’est simple, ça marche. Le problème : tout est dans le même segment réseau. Un container compromis peut contacter directement le nœud Proxmox ou d’autres VMs.
La topologie que j’utilise
Avec le MS-01 qui a quatre ports physiques (2× 2.5GbE RJ45, 2× 10GbE SFP+), je répartis les trafics :
| Interface physique | Bridge | Rôle | Réseau |
|---|---|---|---|
enp2s0 (2.5GbE) |
vmbr0 |
LAN management | 192.168.1.0/24 (VLAN 1) |
enp4s0f0np0 (10GbE SFP+) |
vmbr1 |
Stockage (NFS, PBS) | 10.10.0.0/24 |
Pour les VLANs LAN (IoT, services, management), je passe par vmbr0 en mode VLAN-aware avec un switch manageable entre le MS-01 et le routeur.
Si tu n’as pas de switch manageable, tu peux faire du réseau plat dans vmbr0 sans VLANs. La segmentation est une couche de sécurité en plus, pas un prérequis pour démarrer.
Configurer le bridge stockage (vmbr1)
Le port SFP+ enp4s0f0np0 est dédié au stockage – PBS, NFS, futur cluster. Pas d’IP routable vers Internet, pas de gateway.
# /etc/network/interfaces - ajouter après vmbr0 :
auto vmbr1
iface vmbr1 inet static
address 10.10.0.1/24
bridge-ports enp4s0f0np0
bridge-stp off
bridge-fd 0
ifreload -a
ping -c3 10.10.0.1 # doit répondre
Activer les VLANs sur vmbr0
Prérequis : un switch manageable entre le MS-01 et le routeur, configuré pour laisser passer les trames taguées (port trunk vers le MS-01, ports access pour les équipements).
# /etc/network/interfaces - modifier vmbr0 :
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
dns-nameservers 192.168.1.150 # Pi-hole - sera installé article 5
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
ifreload -a
Après ifreload -a avec VLAN-aware, les VMs et LXC sans tag VLAN explicite restent accessibles via le VLAN natif (untagged). Ne pas activer VLAN-aware si le switch en face n’est pas configuré pour les trames taguées – on risque de perdre la connectivité réseau du nœud.
Assigner un VLAN à un container ou une VM
Depuis le CLI :
# LXC Pi-hole en VLAN 1 (management - IP de management, DNS pour tout le réseau)
pct set 150 --net0 name=eth0,bridge=vmbr0,tag=1,ip=192.168.1.150/24,gw=192.168.1.1
# LXC Nextcloud en VLAN 30 (réseau serveurs)
pct set 200 --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.200/24,gw=192.168.30.1
Depuis l’interface web : CT/VM > Network > Modifier → champ « VLAN Tag ».
Architecture VLAN cible
| VLAN | Nom | Réseau | Hébergé dans ce VLAN |
|---|---|---|---|
| 1 | Management | 192.168.1.0/24 | Proxmox (192.168.1.10), Pi-hole (192.168.1.150), switch, routeur |
| 10 | LAN | 192.168.10.0/24 | PCs, téléphones, tablettes |
| 20 | IoT | 192.168.20.0/24 | Ampoules, thermostats, TV – isolés du reste |
| 30 | Serveurs | 192.168.30.0/24 | Nextcloud, Gitea, Jellyfin, Grafana, PBS |
| 40 | Stockage | 10.10.0.0/24 | NFS (Synology DS414), Proxmox Backup Server |
Pi-hole est en VLAN 1 (management) et non en VLAN 30 (serveurs) : il doit être joignable par tous les VLANs sans traverser de règles de routage inter-VLAN. Le placer en VLAN serveurs et permettre l’accès DNS depuis IoT demanderait des règles pare-feu supplémentaires sans bénéfice réel.
SDN Proxmox : un mot rapide
Proxmox 7.x a introduit un module SDN (Software Defined Networking) accessible depuis Datacenter > SDN. Il permet de créer des zones réseau virtuelles indépendantes de la configuration /etc/network/interfaces, avec DHCP intégré.
Je ne l’utilise pas pour ce homelab. Le SDN est pertinent pour des clusters multi-nœuds avec migration live de VMs. Sur un seul nœud, la configuration statique dans /etc/network/interfaces est plus simple à déboguer et à comprendre.
Ce qui a coincé
La configuration VLAN-aware m’a coûté 40 minutes de connectivité perdue. Symptôme : après ifreload -a, le nœud Proxmox (192.168.1.10) n’était plus joignable depuis le LAN.
Cause : mon switch TP-Link n’était pas configuré en trunk sur le port connecté au MS-01. Il dropait les trames taguées VLAN au lieu de les laisser passer. Résultat : la trame de management du nœud (IP 192.168.1.10) sortait taguée VLAN 1, le switch la dropait, personne ne répondait.
Solution : sur le switch, configurer le port connecté au MS-01 en « Trunk » (accepte toutes les trames taguées) plutôt qu’en « Access » (ne transporte qu’un seul VLAN, strips le tag).
Pour déboguer ce type de problème sans écran branché sur le MS-01 : accéder via console QEMU depuis l’interface web Proxmox, ou brancher directement un câble réseau sur le deuxième port 2.5GbE (enp3s0) avec une IP de rescue configurée.
Série « Homelab Proxmox MS-01 » – Article 4/10