Proxmox VE — Réseau avancé

Pourquoi le réseau est le nerf de la guerre en virtualisation

Une infrastructure Proxmox peut héberger des dizaines de VMs et conteneurs. Si le réseau est mal conçu, tout en souffre : latence entre services, failles de sécurité par manque de segmentation, debugging impossible quand un paquet se perd entre trois bridges.

À l’installation, Proxmox crée un unique bridge vmbr0 relié à l’interface physique. Toutes les VMs et tous les conteneurs partagent le même segment L2 — c’est simple, mais c’est un réseau plat sans isolation. En production, tu as besoin de segmenter : management séparé du trafic applicatif, bases de données isolées, stockage sur un réseau dédié.

🔥 Cas réel : Une entreprise héberge 40 VMs sur un Proxmox avec un seul bridge. Un développeur lance un scan nmap depuis sa VM de dev — il voit toutes les VMs de production, y compris les bases de données. Aucune segmentation réseau. Après un incident de sécurité, l’équipe met en place des VLANs : 3 jours de travail qu’un bon design initial aurait évité.

Ce cours couvre les briques essentielles : bridges Linux, VLANs, SDN pour les clusters, et le firewall intégré Proxmox.

Linux Bridges et VLANs — les fondations

Le bridge : ton switch virtuel

Un bridge Linux fonctionne exactement comme un switch physique. Il connecte des interfaces (physiques et virtuelles) sur le même segment L2. Les VMs et conteneurs s’y branchent via des interfaces tap et veth.

La configuration réseau de Proxmox vit dans /etc/network/interfaces :

# Configuration par défaut après installation
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

Pour un réseau interne isolé (communication entre VMs sans accès direct depuis l’extérieur), crée un bridge sans interface physique et ajoute du NAT :

auto vmbr1
iface vmbr1 inet static
    address 10.0.0.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE

⚠️ Attention : Une erreur dans /etc/network/interfaces peut couper ton accès SSH. Utilise ifreload -a (qui revert après 30 secondes sans confirmation) plutôt qu’un systemctl restart networking brutal. Et garde toujours un accès IPMI ou physique en secours.

VLANs — segmenter sans multiplier les câbles

Les VLANs créent des réseaux logiques isolés sur la même infrastructure physique. Un tag VLAN (1-4094) est ajouté à chaque trame Ethernet pour identifier son réseau.

La méthode recommandée dans Proxmox est le VLAN-aware bridge — un seul bridge gère tous les VLANs :

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Ensuite, tu assignes un VLAN directement sur l’interface de chaque VM ou conteneur :

# VM sur le VLAN production (20)
qm set 100 --net0 virtio,bridge=vmbr0,tag=20

# Conteneur sur le VLAN database (30)
pct set 200 --net0 name=eth0,bridge=vmbr0,tag=30,ip=10.30.0.10/24

💡 Tip DevOps : Adopte une convention VLAN dès le départ. Par exemple : VLAN 10 = management, VLAN 20 = production, VLAN 30 = bases de données, VLAN 40 = DMZ. Documente-la — ton futur toi te remerciera à 3h du matin pendant un incident.

Le switch physique connecté à Proxmox doit être configuré en mode trunk pour laisser passer les trames tagguées. Sans ça, les VLANs ne traversent pas.

Bonding — haute disponibilité réseau

Pour la redondance et la bande passante, le bonding agrège plusieurs interfaces physiques :

auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-miimon 100
    bond-mode 802.3ad
    bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

Le mode 802.3ad (LACP) offre HA + performance, mais nécessite une configuration côté switch. Le mode active-backup fonctionne sans configuration switch — parfait pour un homelab.

SDN — le réseau centralisé pour les clusters

Le SDN (Software-Defined Networking) de Proxmox permet de définir le réseau une seule fois au niveau du cluster, et c’est appliqué automatiquement sur tous les nœuds. Fini les fichiers /etc/network/interfaces à synchroniser à la main.

Les concepts clés :

• Zone : un domaine réseau (type Simple, VLAN, VXLAN, EVPN)
• VNet : un réseau virtuel dans une zone
• Subnet : un sous-réseau IP dans un VNet

Pour un cluster simple, une zone de type VLAN suffit :

# Créer une zone, un VNet et un subnet
pvesh create /cluster/sdn/zones --zone prod --type simple --bridge vmbr0
pvesh create /cluster/sdn/vnets --vnet vnet-web --zone prod --tag 20
pvesh create /cluster/sdn/vnets/vnet-web/subnets \
  --subnet 10.20.0.0/24 --gateway 10.20.0.1 --type subnet

# Appliquer la configuration sur tous les nœuds
pvesh set /cluster/sdn

Pour les architectures multi-sites, VXLAN encapsule du L2 dans de l’UDP — ça étend un réseau local à travers un réseau L3 (entre datacenters). EVPN ajoute BGP par-dessus pour distribuer les routes automatiquement. C’est le standard datacenter moderne, mais c’est overkill pour un seul nœud.

🧠 À retenir : SDN vaut le coup à partir de 3 nœuds ou dans un contexte multi-tenant. Sur un nœud unique, les bridges classiques + VLANs sont plus simples et suffisants.

Le firewall Proxmox — sécurité en couches

Architecture à trois niveaux

Le firewall Proxmox s’applique en cascade sur trois niveaux : Datacenter (règles globales) → Node (règles par serveur) → VM/CT (règles par machine). Les règles se cumulent du plus large au plus spécifique.

L’activation se fait de haut en bas, mais les règles d’accès doivent être ajoutées AVANT d’activer le firewall :

# 1. D'abord, ajouter les règles essentielles
pvesh create /cluster/firewall/rules \
  --action ACCEPT --type in --proto tcp --dport 22 --comment "SSH"
pvesh create /cluster/firewall/rules \
  --action ACCEPT --type in --proto tcp --dport 8006 --comment "Proxmox Web UI"

# 2. Ensuite seulement, activer le firewall
pvesh set /cluster/firewall/options --enable 1 --policy_in DROP --policy_out ACCEPT

⚠️ Attention : Activer le firewall avec policy_in DROP SANS règle SSH = tu te coupes l’accès. C’est l’erreur classique numéro 1. Toujours ajouter les règles d’accès en premier.

Security Groups et IP Sets

Les Security Groups sont des ensembles de règles réutilisables — comme les Security Groups AWS :

# Créer un groupe "webserver" et l'appliquer à plusieurs VMs
pvesh create /cluster/firewall/groups --group webserver
pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 80 --comment "HTTP"
pvesh create /cluster/firewall/groups/webserver \
  --action ACCEPT --type in --proto tcp --dport 443 --comment "HTTPS"

Les IP Sets regroupent des adresses pour simplifier les règles :

# Créer un set d'IPs de confiance
pvesh create /cluster/firewall/ipset --name trusted
pvesh create /cluster/firewall/ipset/trusted --cidr 192.168.1.0/24
pvesh create /cluster/firewall/ipset/trusted --cidr 10.10.0.5

# Utiliser dans une règle : seules les IPs trusted peuvent SSH
pvesh create /cluster/firewall/rules \
  --action ACCEPT --type in --source +trusted --proto tcp --dport 22

💡 Tip DevOps : Les fichiers de config firewall sont dans /etc/pve/firewall/. Le fichier cluster.fw pour les règles globales, 100.fw pour la VM 100. Tu peux les éditer directement — c’est parfois plus rapide que les commandes pvesh.

Design réseau et troubleshooting

Architectures recommandées

Homelab / nœud unique : Un bridge vmbr0 VLAN-aware suffit. Ajoute des tags VLAN sur les VMs pour segmenter. Simple et efficace.

Production multi-nœuds : Sépare physiquement les flux — un réseau pour le management (Proxmox UI, SSH), un pour le trafic VM (VLAN-aware), un pour le stockage (Ceph, 10G minimum). Le bonding en LACP sur chaque réseau pour la redondance.

Diagnostic rapide

Quand le réseau ne marche pas, voici la checklist :

# Vérifier les bridges
brctl show

# Capturer le trafic d'une VM spécifique
tcpdump -i tap100i0 -n

# Vérifier les règles firewall actives
iptables -L -n -v
pve-firewall status

# Vérifier la connectivité
ping -c 3 192.168.1.1
ip neigh show   # table ARP

🔥 Cas réel : Une VM n’a pas de réseau après un changement de VLAN. Le debug montre que le bridge est correct, l’IP est configurée, mais aucun paquet ne traverse. Cause : le switch physique n’a pas le VLAN autorisé sur le port trunk. 15 minutes de debug côté Proxmox pour un problème côté switch — toujours vérifier les deux côtés.

Résumé

Le réseau Proxmox repose sur des Linux bridges — des switches virtuels configurés dans /etc/network/interfaces. Le VLAN-aware bridge est la méthode recommandée pour segmenter sans multiplier les bridges.

Le SDN centralise la gestion réseau au niveau cluster — indispensable à partir de 3 nœuds, overkill sur un nœud unique.

Le firewall intégré fonctionne en cascade (Datacenter → Node → VM). Règle absolue : ajouter les règles d’accès SSH/Web AVANT d’activer le firewall.

En production, sépare toujours management, trafic VM et stockage sur des réseaux distincts. Le bonding assure la redondance, les VLANs assurent l’isolation.

🧠 À retenir : Un bon design réseau se pense au jour 1. Le refactorer ensuite avec 50 VMs en production, c’est un cauchemar. Prends le temps de définir tes VLANs, tes conventions, et ta segmentation avant de déployer la première VM.