Réseau Proxmox VE : comprendre et configurer bridges, VLAN et NAT

Vos VM n'ont pas de réseau ? Vous avez peur de vous couper l'accès en modifiant la config ? Ce guide vous donne les bases pour comprendre ce qui se passe, puis configurer en toute sécurité.

Trois situations, trois solutions :

• Homelab / plusieurs IP disponibles → Bridge simple (le défaut)
• Isoler prod/dev/DMZ → Bridge VLAN-aware
• VPS avec une seule IP publique → NAT

Concepts réseau indispensables

Avant de toucher à quoi que ce soit, vous devez comprendre comment les paquets circulent. Sans ça, vous allez copier-coller des configs sans savoir ce que vous faites, et vous couper l'accès au premier problème.

L2 vs L3 : la distinction fondamentale

Le réseau fonctionne en couches. Deux nous concernent ici :

Couche	Ce qu'elle gère	Identifiant	Équipement typique
L2 (liaison)	Transmission de trames entre machines du même réseau	Adresse MAC	Switch
L3 (réseau)	Routage de paquets entre réseaux différents	Adresse IP	Routeur

Glissez pour voir

Pourquoi c'est important ?

• Un bridge = switch logiciel = travaille en L2 (il regarde les MAC)
• Le NAT/routage = travaille en L3 (il regarde les IP)
• Un VLAN = étiquetage L2 (tag 802.1Q sur les trames)

Quand vous comprenez ça, le reste devient logique.

Les objets réseau dans Proxmox

Proxmox crée et manipule plusieurs types d'objets. Voici ce que vous verrez :

Objet	Ce que c'est	Exemple
Interface physique	Votre carte réseau réelle	eno1, enp3s0, eth0
Bridge	Switch virtuel (créé par Proxmox)	vmbr0, vmbr1
vNIC	Carte réseau virtuelle d'une VM	net0 dans les paramètres VM
tap	Interface côté hôte connectée à une vNIC	tap100i0 (VM 100, interface 0)
bridge-ports	L'uplink du bridge vers le physique	bridge-ports eno1

Glissez pour voir

Dans l'interface web : Nœud → System → Network pour voir tout ça.

Le chemin d'un paquet (bridge simple)

Quand une VM envoie un paquet vers Internet :

VM (eth0) → tap100i0 → vmbr0 → eno1 → switch physique → Internet

Le bridge vmbr0 fonctionne comme un switch : il reçoit le paquet de la VM via tap100i0, regarde l'adresse MAC de destination, et le transmet vers eno1 (qui est connecté au réseau physique).

Le chemin d'un paquet (NAT)

En NAT, c'est différent, le paquet passe par le routage de l'hôte :

VM (eth0) → tap100i0 → vmbr0 → ip_forward → NAT (iptables) → eno1 → Internet

L'hôte Proxmox remplace l'IP source de la VM par son IP publique avant d'envoyer. Quand la réponse arrive, il fait l'inverse.

Pourquoi l'IP est sur le bridge, pas sur l'interface physique

C'est le point de confusion chez les débutants.

Dans Proxmox, l'adresse IP du serveur est configurée sur le bridge (vmbr0), pas sur l'interface physique (eno1). Pourquoi ?

Parce que tout le trafic, celui de l'hôte comme celui des VM, transite par le bridge. Lui donner l'adresse place l'hôte sur le même segment L2 que ses machines virtuelles, qui deviennent joignables sans routage supplémentaire. L'interface physique eno1 reste déclarée en mode manual : elle transporte les trames entre le bridge et le switch, sans jamais posséder d'adresse IP.

Configuration typique

# L'interface physique : pas d'IP, juste un câble
iface eno1 inet manual

# Le bridge : c'est lui qui a l'IP
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1

Comment Proxmox applique les changements

Proxmox utilise ifupdown2 pour gérer le réseau. C'est une version améliorée d'ifupdown qui permet d'appliquer les changements à chaud, sans reboot.

Le mécanisme de staging :

1. Vous modifiez le réseau via l'interface web
2. Proxmox écrit vos changements dans /etc/network/interfaces.new (fichier temporaire)
3. Rien n'est appliqué tant que vous ne cliquez pas sur Apply Configuration
4. Proxmox sauvegarde l'ancien fichier, puis exécute ifreload -a

Pourquoi ifreload -a est important : c'est la commande clé d'ifupdown2. Elle applique les changements sans couper les connexions existantes (dans la plupart des cas). C'est ce qui permet de modifier le réseau sans reboot.

# Ce que fait "Apply Configuration" en coulisses
ifreload -a

Choisir votre topologie

Avant de configurer, choisissez la bonne approche selon votre situation. Le critère décisif n'est pas technique mais contractuel : combien d'adresses IP votre réseau vous accorde-t-il, et devez-vous cloisonner des machines entre elles. Une seule IP publique impose le NAT ; un besoin d'isolation impose le VLAN ; dans tous les autres cas, le bridge simple reste la réponse.

Situation	Configuration	Pourquoi
Homelab, plusieurs IP dispo	Bridge simple	C'est le défaut, ça marche tout seul
Entreprise, 1 IP par VM	Bridge simple	Chaque VM est directement joignable
Isoler prod/dev/DMZ	VLAN-aware	Un bridge, plusieurs réseaux isolés
VPS, 1 seule IP publique	NAT	Les VM sortent via l'IP de l'hôte
Lab sans switch managé	Bridge simple ou NAT	VLAN-aware inutile sans trunk

Glissez pour voir

Pattern A, Bridge simple (le défaut)

C'est la configuration par défaut après installation. Vos VM sont sur le même réseau que l'hôte Proxmox : elles reçoivent une adresse de la même plage, souvent par le DHCP de votre box ou de votre routeur, et sont joignables directement depuis le reste du réseau. Aucun routage ni traduction d'adresse n'intervient, ce qui rend le diagnostic simple.

Configuration

Si vous avez installé Proxmox normalement, c'est déjà en place. Vérifiez :

/etc/network/interfaces

auto lo
iface lo inet loopback

iface eno1 inet manual

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

Points clés :

• L'IP est sur vmbr0, pas sur eno1
• eno1 est en manual (pas d'IP)
• bridge-ports eno1 connecte le bridge au physique

Créer un second bridge

Si vous avez une seconde carte réseau et voulez un bridge dédié :

1. Allez dans Nœud → System → Network

2. Cliquez Create → Linux Bridge

3. Renseignez :

   • Name : vmbr1
   • Bridge ports : eno2
   • IPv4/CIDR : laissez vide si pas besoin d'IP

4. Cliquez Apply Configuration

Vérification

Ces trois contrôles s'enchaînent du plus proche au plus lointain : l'hôte, le bridge, puis la VM. Si le ping vers la passerelle échoue depuis la VM alors que l'hôte répond, le problème est presque toujours dans le rattachement de la carte virtuelle au bon bridge.

# L'hôte a une IP sur vmbr0
ip -br addr | grep vmbr0

# Le bridge est connecté à eno1
bridge link show

# Une VM obtient une IP (DHCP ou statique)
# Depuis la VM :
ping 192.168.1.1   # passerelle
ping 8.8.8.8       # internet

Pièges courants

Les deux erreurs ci-dessous représentent l'essentiel des incidents sur un bridge simple. La seconde est la plus délicate, car elle vous prive du moyen de la corriger : sans accès console, un mauvais réglage de passerelle rend le serveur injoignable.

Problème	Cause	Solution
VM pas d'IP DHCP	bridge-ports manquant	Vérifier la config du bridge
Perte d'accès après Apply	Mauvaise gateway ou IP	Console + restaurer backup

Glissez pour voir

Pattern B, Bridge VLAN-aware

Un seul bridge gère plusieurs réseaux isolés via des tags VLAN (802.1Q). Chaque trame sortant d'une VM se voit ajouter une étiquette numérique que le switch physique utilise pour la ranger dans le bon réseau. Deux VM portant des tags différents ne peuvent pas se parler directement, même si elles partagent le même bridge et la même carte réseau physique. Cette configuration suppose un switch capable de gérer le VLAN, sans quoi les étiquettes sont perdues.

Prérequis

Votre switch physique doit être configuré en trunk (tagged) sur le port connecté à Proxmox :

Exemple Cisco

interface GigabitEthernet0/1
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30

Sans cette config côté switch, les tags seront ignorés.

Configuration

Pour activer le support VLAN sur un bridge existant :

1. Allez dans Nœud → System → Network

2. Sélectionnez vmbr0 et cliquez Edit

3. Cochez VLAN aware

4. Dans Bridge VLAN IDs, listez les VLAN autorisés : 10 20 30

5. Cliquez OK puis Apply Configuration

Ou manuellement :

/etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30

Tagger une VM

Le tag se pose côté Proxmox, pas dans le système invité : la VM voit une carte réseau ordinaire et ignore tout du VLAN. Le numéro saisi doit figurer dans les Bridge VLAN IDs du bridge, sinon la trame est rejetée.

1. Éditez la VM → Hardware → Network Device
2. Dans VLAN Tag, entrez le numéro (ex: 10)
3. La VM est maintenant sur le VLAN 10

Vérification

Le test qui compte est le second : une isolation VLAN ne se prouve pas par ce qui fonctionne, mais par ce qui doit échouer. Un ping qui passe entre deux VLAN différents signale une configuration de switch trop permissive.

# Voir les VLAN configurés sur le bridge
bridge vlan show

# Depuis une VM sur VLAN 10
ping <autre-machine-vlan-10>   # doit marcher
ping <machine-vlan-20>         # ne doit PAS marcher (isolation)

Pièges courants

Un symptôme domine sur le VLAN : « tout marchait avant que je coche la case ». Dans presque tous les cas, la configuration Proxmox est correcte et c'est le port du switch qui n'a pas été passé en trunk.

Problème	Cause	Solution
VLAN tag ignoré	Switch pas en trunk	Configurer le port switch
VM isolée du réseau	Mauvais VLAN ID	Vérifier le tag dans la VM

Glissez pour voir

Pattern C, NAT (une seule IP publique)

Les VM ont des IP privées et sortent sur Internet via l'IP publique de l'hôte. C'est la seule option quand votre hébergeur ne vous fournit qu'une adresse publique, ce qui est le cas courant sur un VPS ou un serveur dédié d'entrée de gamme. Contrepartie à accepter dès le départ : les VM ne sont plus joignables depuis l'extérieur sans redirection de port explicite.

Configuration

Deux différences avec le bridge simple sautent aux yeux : c'est eno1 qui porte l'IP publique, et le bridge est déclaré bridge-ports none, donc totalement déconnecté du réseau physique. Les lignes post-up et post-down créent et retirent la règle de traduction d'adresse au moment où l'interface monte et descend.

/etc/network/interfaces

auto lo
iface lo inet loopback

# Interface publique
auto eno1
iface eno1 inet static
    address 198.51.100.5/24
    gateway 198.51.100.1

# Bridge privé pour les VM
auto vmbr0
iface vmbr0 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    post-up   iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

Points clés :

• bridge-ports none : le bridge n'est pas connecté au physique
• MASQUERADE : remplace l'IP source des paquets sortants

Activer le routage (persistant)

Le routage IP doit être activé pour que le NAT fonctionne. Ne pas utiliser echo 1 > /proc/... (perdu au reboot).

# Créer le fichier de config sysctl
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-ip-forward.conf

# Appliquer immédiatement
sysctl -p /etc/sysctl.d/99-ip-forward.conf

# Vérifier
cat /proc/sys/net/ipv4/ip_forward   # doit afficher 1

Configurer une VM

En NAT, il n'y a aucun serveur DHCP sur le bridge privé : l'adresse doit être saisie à la main dans la VM, et la passerelle est l'IP que porte le bridge sur l'hôte. Un résolveur DNS externe est également obligatoire, sinon seuls les pings vers des IP fonctionneront.

1. Associez la VM à vmbr0
2. Dans la VM, configurez :
   • IP : 10.10.10.10/24
   • Passerelle : 10.10.10.1
   • DNS : 8.8.8.8

Port forwarding

Pour rendre un service accessible depuis l'extérieur :

# Rediriger le port 80 public vers la VM 10.10.10.10
iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 80 -j DNAT --to 10.10.10.10:80
iptables -A FORWARD -p tcp -d 10.10.10.10 --dport 80 -j ACCEPT

Pour persister les règles iptables, utilisez iptables-persistent ou ajoutez-les dans /etc/network/interfaces avec post-up.

Vérification

Le dernier test est le plus parlant : depuis la VM, l'adresse renvoyée par un service d'écho doit être l'IP publique de l'hôte, preuve que la traduction d'adresse s'applique bien.

# Sur l'hôte : vérifier le routage
cat /proc/sys/net/ipv4/ip_forward   # 1

# Sur l'hôte : vérifier les règles NAT
iptables -t nat -L -n -v | grep MASQUERADE

# Depuis la VM
ping 8.8.8.8           # internet
curl -s ifconfig.me    # doit afficher l'IP publique de l'hôte

Pièges courants

Le NAT accumule les points de défaillance parce qu'il fait intervenir trois mécanismes distincts : le routage du noyau, les règles iptables et la résolution DNS dans la VM. Une panne au redémarrage vient presque toujours d'un réglage appliqué à chaud sans avoir été rendu persistant.

Problème	Cause	Solution
NAT cassé après reboot	ip_forward non persistant	Utiliser sysctl.d
VM ping OK, HTTP KO	Firewall bloque	Vérifier iptables -L
DNS ne marche pas	Pas de résolveur	Configurer DNS dans la VM

Glissez pour voir

NAT et firewall Proxmox

Si vous utilisez le firewall intégré de Proxmox, testez NAT et règles ensemble. Les deux interagissent (conntrack, zones). Évitez d'empiler des règles sans comprendre l'ordre d'évaluation.

Safe change checklist

Modifier le réseau peut vous couper l'accès. Suivez cette procédure systématiquement.

Avant de modifier

Ces trois points se préparent quand tout va bien : une fois l'accès perdu, il est trop tard pour sauvegarder quoi que ce soit.

1. Vérifiez que vous avez un accès console

   • IPMI/iLO/iDRAC (serveur physique)
   • Console VNC (hébergeur)
   • Accès physique clavier/écran

2. Sauvegardez la config actuelle

   cp /etc/network/interfaces /etc/network/interfaces.backup-$(date +%Y%m%d-%H%M)

3. Notez l'IP et la gateway actuelles

   ip -br addr
   ip route | grep default

Appliquer les changements

Rien n'est actif tant que Apply Configuration n'a pas été cliqué : jusque-là, vos modifications dorment dans /etc/network/interfaces.new. La vérification doit suivre immédiatement, pendant que vous disposez encore d'une session ouverte.

1. Faites vos modifications via l'interface web

2. Cliquez Apply Configuration

3. Regardez le Task log (en bas), il doit se terminer par TASK OK

4. Immédiatement après, vérifiez :

   # L'hôte répond
   ping -c 2 <IP_PROXMOX>
   
   # L'interface web est accessible
   curl -k https://<IP_PROXMOX>:8006

Si vous perdez l'accès

La procédure de retour arrière consiste à remettre en place le fichier sauvegardé, puis à le recharger. Elle se déroule entièrement depuis la console, l'interface web étant par définition inaccessible.

1. Accédez via la console (IPMI, VNC, physique)

2. Listez les backups disponibles :

   ls -la /etc/network/interfaces*

   Proxmox crée des backups avec timestamp lors de l'apply.

3. Restaurez le dernier backup fonctionnel :

   cp /etc/network/interfaces.backup-YYYYMMDD-HHMM /etc/network/interfaces

4. Réappliquez :

   ifreload -a

5. Vérifiez que l'accès est rétabli

Dépannage

Un problème réseau sur Proxmox se localise en remontant le chemin du paquet : la VM, le bridge, l'interface physique, puis le switch. Le tableau ci-dessous associe chaque symptôme courant à l'étage responsable, et les commandes qui suivent permettent d'observer l'état réel du système plutôt que de le supposer.

Les 6 problèmes les plus fréquents

Comparez la ligne « Ping OK mais HTTP KO » et la ligne « VM pas d'IP » : la première prouve que le réseau fonctionne et oriente vers le filtrage, la seconde met en cause le rattachement au bridge.

Symptôme	Cause probable	Solution
VM pas d'IP DHCP	bridge-ports manquant ou mauvais	Vérifier la config du bridge
Perte d'accès après Apply	Erreur gateway/IP	Console → restaurer backup
VLAN tag ignoré	Switch pas en trunk	Configurer le port switch
NAT ne marche pas	ip_forward désactivé	sysctl -p ou vérifier /proc/sys/net/ipv4/ip_forward
Ping OK mais HTTP KO	Firewall actif	iptables -L ou désactiver temporairement
Performance faible	MTU mismatch	Vérifier MTU de bout en bout

Glissez pour voir

Commandes de diagnostic

Lancez-les dans cet ordre : elles vont du plus général au plus spécifique. L'option -br de ip produit une sortie condensée sur une ligne par interface, bien plus lisible que la sortie complète quand le serveur héberge une dizaine de tap.

# État des interfaces
ip -br link
ip -br addr

# Bridges et leurs ports
bridge link show

# Table de routage
ip route

# Règles NAT
iptables -t nat -L -n -v

# Logs réseau récents
journalctl -u networking --no-pager -n 30

Bonnes pratiques

La configuration réseau d'un hyperviseur se consulte rarement, sauf le jour où plus rien ne fonctionne. Les trois habitudes qui suivent visent ce moment précis : retrouver l'intention derrière un réglage, et éviter de découvrir un effet de bord en production.

Documentez votre configuration

Gardez un schéma réseau à jour :

• Quels bridges existent
• Quelles interfaces physiques ils utilisent
• Quels VLAN sont configurés
• Quelles plages IP sont utilisées

Commentez vos fichiers

Un commentaire dans /etc/network/interfaces survit aux changements d'équipe et se lit depuis la console, même quand l'interface web est inaccessible. Indiquez l'usage du bridge et les réglages non évidents, comme un MTU différent de la valeur par défaut.

/etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.100/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    # LAN principal - VMs de production

auto vmbr1
iface vmbr1 inet static
    address 10.0.0.1/24
    bridge-ports eno2
    # Réseau stockage - Ceph/NFS - MTU 9000
    mtu 9000

Testez en lab avant la prod

Certains défauts réseau ne se révèlent pas immédiatement : une fragmentation liée au MTU ou une agrégation de liens mal négociée peuvent tenir plusieurs heures avant de dégrader le service. D'où le délai d'observation ci-dessous.

1. Faites vos modifications sur un environnement de test
2. Testez pendant quelques jours
3. Puis déployez en production

Annexes, Configurations avancées

Ces sections couvrent des cas avancés, pas nécessaires pour débuter. Elles répondent à trois besoins distincts : gagner du débit sur un réseau de stockage, tolérer la panne d'un câble, et reproduire une organisation VLAN héritée d'anciennes installations.

MTU / Jumbo Frames

Pour du stockage réseau (Ceph, NFS, iSCSI), augmenter le MTU à 9000 améliore le débit.

Prérequis : tous les équipements du chemin doivent supporter le même MTU.

/etc/network/interfaces

auto vmbr1
iface vmbr1 inet static
    address 10.0.0.1/24
    bridge-ports eno2
    mtu 9000

Test :

ping -M do -s 8972 10.0.0.2   # 8972 + 28 headers = 9000

Bonding (agrégation de liens)

Combiner plusieurs cartes réseau pour le débit et la redondance. Le bond devient alors le port du bridge, à la place de l'interface physique. Le choix du mode dépend surtout de ce que votre switch accepte : le mode 802.3ad exige une configuration correspondante côté switch, les deux autres non.

Mode	Usage
active-backup	Haute dispo, 1 lien actif
802.3ad (LACP)	Débit + HA, config switch requise
balance-alb	Équilibrage sans config switch

Glissez pour voir

Exemple 802.3ad

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.100/24
    gateway 192.168.1.1
    bridge-ports bond0

Sous-interfaces VLAN (méthode legacy)

Avant le bridge VLAN-aware, on créait une sous-interface par VLAN, puis un bridge dédié au-dessus. Le résultat est fonctionnellement équivalent, mais multiplie les objets à maintenir : un bridge et une sous-interface pour chaque réseau.

/etc/network/interfaces

auto eno1.10
iface eno1.10 inet manual

auto vmbr10
iface vmbr10 inet static
    address 10.10.10.1/24
    bridge-ports eno1.10

Préférez VLAN-aware pour les nouvelles installations.

À retenir

1. Bridge = switch virtuel L2, il regarde les MAC, pas les IP

2. L'IP est sur le bridge (vmbr0), pas sur l'interface physique

3. Trois patterns :

   • Bridge simple : VM sur le même LAN que l'hôte
   • VLAN-aware : un bridge, plusieurs réseaux isolés
   • NAT : une IP publique, masquerading

4. Proxmox utilise ifupdown2, ifreload -a applique à chaud

5. Toujours avoir un accès console avant de modifier le réseau

6. NAT : utilisez sysctl.d pour persister ip_forward

FAQ : questions fréquentes sur le réseau Proxmox

Voici les questions qui reviennent le plus souvent une fois la configuration en place, notamment sur le choix du pattern et sur le comportement des bridges.

Quelle différence entre un bridge et du NAT dans Proxmox ?

Un bridge (vmbr0) connecte les VMs directement au réseau physique : elles obtiennent une IP du même réseau que l'hôte, comme des machines à part entière. Le NAT place les VMs sur un réseau privé interne et masque leur trafic derrière l'IP de l'hôte.

Qu'est-ce que vmbr0 dans Proxmox ?

vmbr0 est le pont réseau (bridge) virtuel créé par défaut à l'installation de Proxmox. Il relie la carte réseau physique du serveur aux machines virtuelles, qui s'y connectent comme à un switch. C'est l'équivalent logiciel d'un commutateur réseau auquel l'hôte et ses VMs sont branchés.

Comment donner une adresse IP fixe à une VM Proxmox ?

Deux méthodes : configurer une réservation DHCP sur votre routeur en associant l'adresse MAC de la VM à une IP, ou définir une IP statique dans la VM elle-même (cloud-init ou configuration réseau du système invité).

Comment éviter de se couper l'accès réseau en modifiant la config Proxmox ?

Avant toute modification réseau risquée, gardez un accès de secours (console physique ou IPMI). Proxmox applique les changements réseau seulement après un redémarrage du service ou via l'outil ifupdown2, ce qui laisse une marge.

Pour aller plus loin

• Installer Proxmox VE depuis l'ISO : Poser l'hyperviseur avec la bonne adresse IP et la bonne passerelle dès le premier démarrage.
• Prendre en main l'interface web : Créer et modifier bridges et VLAN depuis l'UI plutôt qu'en éditant /etc/network/interfaces.
• Créer une VM KVM : Rattacher une carte VirtIO au bridge configuré et vérifier que le trafic passe vraiment.
• Créer un conteneur LXC : Le réseau côté conteneur, dont l'adressage se déclare autrement que pour une VM.

×

📖 Voir la documentation →