Le réseau Proxmox VE expliqué : bridges, bonds et VLAN

D'abord la réponse : le modèle mental unique

Le réseau Proxmox VE, c'est du réseau Linux, organisé autour d'une seule idée : les machines virtuelles et les conteneurs branchent leurs cartes réseau virtuelles sur des switches logiciels appelés bridges Linux. Le bridge par défaut, vmbr0, est créé à l'installation avec votre carte réseau physique rattachée ; c'est la seule raison pour laquelle votre première VM a pu atteindre internet.

Chaque configuration réelle n'est qu'une variation sur ce à quoi ces bridges se connectent :

• Bridged : la VM se trouve directement sur le réseau physique avec sa propre IP publique et sa propre MAC. Le plus simple, mais chez un hébergeur, cela nécessite des IP/MAC supplémentaires validées par l'hébergeur.
• Routed : l'hôte possède les adresses publiques et route le trafic vers les VM. Fonctionne partout, aucune contrainte MAC, un peu plus de configuration.
• NAT / privé : les VM vivent sur un bridge privé et partagent l'IP sortante de l'hôte. Adapté aux VM qui n'ont pas besoin d'être joignables publiquement.

La configuration tient dans un seul fichier lisible, /etc/network/interfaces, et comme Proxmox utilise ifupdown2, les changements s'appliquent à chaud avec ifreload -a (ou le bouton "Apply Configuration" de l'interface), sans redémarrage. Cet article suppose une installation fonctionnelle ; si vous n'en êtes pas encore là, commencez par notre guide d'installation de Proxmox VE, qui introduit brièvement vmbr0 ; voici l'approfondissement promis. Les adresses ci-dessous sont des plages de documentation (203.0.113.0/24, 10.0.0.0/24) ; remplacez-les par les vôtres.

Anatomie de vmbr0

Sur une installation neuve, /etc/network/interfaces se résume à ceci :

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Lisez-le de bas en haut et le modèle devient clair : la carte réseau physique (enp1s0) ne porte elle-même aucune IP ; c'est un simple port du bridge. Le bridge possède l'adresse IP de l'hôte et l'uplink. Les VM rattachent leurs cartes réseau virtuelles (périphériques tap) à ce même bridge, ce qui en fait un switch non managé avec la carte réseau physique comme port d'uplink. Tout le reste de cet article consiste à ajouter des bridges, à y tagger du trafic, ou à changer ce qui les alimente.

Les trois schémas sur un serveur hébergé

Sur votre propre switch à la maison, le réseau bridged fonctionne sans problème. Sur un serveur dédié chez un hébergeur, il y a une contrainte à respecter : les switches d'accès du datacenter appliquent généralement un filtrage MAC ; le trafic provenant d'adresses MAC que l'hébergeur n'attend pas sur votre port est rejeté. Ce seul fait détermine quel schéma convient :

Bridged : des VM avec leur propre IP publique

Chaque VM reçoit une IP publique et sa MAC virtuelle apparaît sur le switch de l'hébergeur. Cela nécessite des IP supplémentaires assignées à votre serveur par l'hébergeur, avec la MAC de la VM enregistrée là où l'hébergeur l'exige (certains allouent une MAC par IP, d'autres acceptent n'importe quelle MAC sur votre port pour les sous-réseaux routed). Quand c'est pris en charge (comme sur notre réseau, où l'espace IP supplémentaire est inclus avec le serveur), c'est la configuration la plus propre : la config de la VM se résume à "rattacher à vmbr0, définir l'IP assignée et la même passerelle que l'hôte".

Routed : fonctionne sous n'importe quelle politique MAC

Seule la MAC de l'hôte apparaît jamais sur le fil ; l'hôte route pour ses VM. Schéma : sous-réseau public 203.0.113.64/26 routé vers votre serveur :

auto vmbr1
iface vmbr1 inet static
    address 203.0.113.65/26
    bridge-ports none
    bridge-stp off
    bridge-fd 0

bridge-ports none est l'astuce à retenir : un bridge sans port physique est un switch purement interne. Les VM sur vmbr1 utilisent 203.0.113.65 comme passerelle ; l'hôte fait le forwarding entre vmbr1 et l'uplink (activez net.ipv4.ip_forward dans /etc/sysctl.d/). Le switch de l'hébergeur ne voit jamais que l'hôte.

NAT : des VM privées qui peuvent sortir

Le même bridge sans port avec une plage privée (10.0.0.1/24 sur le bridge), plus une règle de masquerade pour que les VM partagent l'IP publique de l'hôte pour le trafic sortant. Adapté aux VM de build, aux bases de données qui ne servent que d'autres VM, et aux invités de labo. L'accès entrant, si nécessaire, passe par du port-forwarding (DNAT) sur l'hôte ; si vous forwardez beaucoup, demandez-vous si la VM ne voudrait pas simplement une IP publique routed.

Combinez librement : un hôte typique fait tourner vmbr0 (public, bridged), plus un bridge privé pour le trafic backend entre les invités.

VLAN : un bridge, plusieurs réseaux

Le schéma moderne, c'est le bridge VLAN-aware, un simple flag sur vmbr0 :

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

Le bridge laisse maintenant passer le trafic taggé, et vous définissez le VLAN Tag par carte réseau virtuelle dans les options matérielles de la VM ; le bridge gère le tag/untag, les invités n'en savent rien. Comparé à l'ancien style un-bridge-par-VLAN (vmbr0v40 et consorts), c'est un seul bridge au lieu d'une dizaine, et aucun changement de configuration de l'hôte quand vous introduisez un nouveau VLAN : assignez un nouveau tag et c'est parti. Les invités qui ont besoin de trunks (une VM firewall, par exemple) peuvent eux aussi recevoir du trafic taggé directement.

Là où les VLAN rencontrent un hébergeur : ils ne segmentent le trafic que là où l'infrastructure transporte les tags. À l'intérieur de votre hôte, toujours ; entre vos serveurs, seulement quand le réseau privé de l'hébergeur les préserve (le nôtre le fait ; les VLAN sur le LAN privé sont le moyen pour les clients de construire des réseaux segmentés multi-hôtes ; c'est aussi le mécanisme derrière les DMZ clients).

Bonding : deux cartes réseau, un seul uplink logique

Les bonds agrègent des cartes réseau physiques pour la redondance (et parfois la bande passante). Le bond devient le port du bridge :

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

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports bond0
    ...

Le choix du mode est plus simple que ne le suggèrent les sept options, et la documentation officielle est directe : utilisez 802.3ad (LACP) si votre switch le prend en charge, sinon utilisez active-backup. LACP nécessite une configuration correspondante sur le switch de l'hébergeur (sur un serveur dédié, cela veut dire que c'est à négocier avec votre hébergeur, pas juste à activer localement) ; active-backup fonctionne avec n'importe quel switch et offre un pur failover. Notez qu'un seul flux TCP ne dépasse jamais la vitesse d'un lien physique sous LACP ; le bonding multiplie la bande passante agrégée, pas celle par flux. Et si vous clusterisez plus tard : corosync n'aime pas certains modes de bond ; donnez au trafic de cluster sa propre carte réseau non bondée, ou de l'active-backup.

La place de la couche SDN

Tout ce qui précède configure un seul hôte. La fonctionnalité SDN de Proxmox (fonctionnalité cœur pleinement prise en charge depuis la 8.1, configurée sous Datacenter → SDN) applique des définitions réseau à l'échelle du cluster : définissez une zone et ses VNets une seule fois, et chaque nœud les propose de façon cohérente. Les types de zones correspondent à différents niveaux d'ambition :

• Simple : des bridges isolés par nœud avec IPAM/DHCP géré par le cluster en option ; la version gérée de bridge-ports none.
• VLAN : la configuration VLAN vue plus haut, définie une seule fois pour tout le cluster.
• QinQ : des tags VLAN empilés, pour quand vous distribuez des VLAN à des locataires.
• VXLAN : des réseaux de couche 2 tunnelisés sur n'importe quelle connectivité de couche 3 entre les nœuds ; la réponse standard à "un réseau privé unique qui s'étend sur des serveurs qui ne partagent pas de switch". Attention au MTU : VXLAN coûte 50 octets d'overhead, donc augmentez le MTU de l'underlay ou réduisez celui du VNet.
• EVPN : VXLAN plus un plan de contrôle basé sur BGP et du routage distribué ; le territoire des fabrics de datacenter.

Règle empirique : hôte unique ou une poignée de bridges statiques → simplement /etc/network/interfaces, cet article. Cluster avec plus de deux ou trois réseaux partagés, ou toute forme de multi-tenant → définissez-les une seule fois dans SDN. (PVE 9 a ajouté les "fabrics", des underlays routed auto-configurés, un signe de la direction que prend cette couche.)

Ne pas se couper soi-même l'accès

Chaque histoire d'horreur réseau sous Proxmox est la même histoire : un changement de bridge appliqué à l'interface qui porte la session SSH. Les disciplines à suivre :

• Appliquer à chaud, de façon atomique. Éditez /etc/network/interfaces, puis ifreload -a (ifupdown2 applique le delta à chaud). Le flux pending-changes + "Apply Configuration" de l'interface fait la même chose, avec une étape de relecture.
• Avoir la console avant d'en avoir besoin. L'accès IPMI/KVM-over-IP (inclus avec nos serveurs) transforme "j'ai coupé mon uplink en bridgeant" d'une panne en une réparation de deux minutes à la console. Vérifiez votre accès avant de modifier quoi que ce soit.
• Changer une couche à la fois. D'abord le bond, vérifiez ; puis le bridge sur le bond ; puis les VLAN. Des changements cumulés produisent des modes de défaillance cumulés.
• Ne pas firewaller l'hôte par accident. Proxmox a son propre firewall (niveaux datacenter → nœud → VM). Quand vous l'activez, confirmez les règles de management (SSH, 8006) avant d'appliquer au niveau du nœud. La même logique de verrouillage que dans notre guide des règles de firewall de base, un niveau au-dessus.

Questions fréquentes

Faut-il utiliser des bridges Linux ou Open vSwitch ?

Des bridges Linux, sauf si vous avez une exigence OVS spécifique. C'est la voie par défaut de Proxmox, la mieux documentée ; le flag VLAN-aware couvre les cas de segmentation pour lesquels on allait autrefois chercher OVS, et toute la couche SDN est construite sur des bridges Linux avec ifupdown2. OVS reste pris en charge pour qui a besoin de ses extras, mais pour un déploiement type sur serveur dédié, cela ajoute de la complexité sans ajouter de capacité que vous utiliserez.

Comment donner à une VM sa propre IP publique ?

Deux méthodes. Bridged : rattachez la VM à vmbr0 et configurez une IP supplémentaire que votre hébergeur a assignée à votre serveur (en respectant sa politique MAC ; sur notre réseau, les IP supplémentaires sont incluses avec le serveur et c'est la configuration standard). Routed : l'adresse MAC visible de l'hébergeur reste celle de l'hôte, les VM sont placées derrière un bridge interne, et le sous-réseau est routé vers elles. Fonctionne quelle que soit la politique du switch, au prix du forwarding assuré par l'hôte.

Pourquoi le réseau de ma VM est-il tombé quand j'ai activé le tagging VLAN ?

Presque toujours l'une de ces trois causes : le bridge n'est pas VLAN-aware (bridge-vlan-aware yes manquant), le chemin physique ne transporte pas le tag (le switch de l'hébergeur ou le réseau privé doit laisser passer ce VLAN), ou un MTU incompatible lors du tunneling (les 50 octets d'overhead de VXLAN). Déboguez dans cet ordre : les flags du bridge, puis le transport du tag de bout en bout avec tcpdump -e vlan, puis le MTU avec un ping do-not-fragment à la taille de la limite.

Est-ce que tout cela nécessite un cluster ?

Non. Tout, jusqu'à la section SDN, fonctionne en single-host. Le SDN lui-même fonctionne aussi sur un seul nœud (les zones Simple avec DHCP géré sont réellement utiles en solo), mais sa valeur augmente avec le nombre de nœuds. Si le clustering est à votre programme, la décision réseau à prendre tôt est de réserver une carte réseau (ou au moins un VLAN) pour le trafic de cluster : corosync veut une latence faible et supporte mal la concurrence avec le trafic de masse des VM ; détails dans notre guide cluster et HA.

Déploiement chez Serverside

Les schémas de ce guide correspondent directement à ce qu'un serveur dédié Proxmox chez nous vous apporte : de l'espace IP publique supplémentaire pour les VM bridged, un réseau privé entre vos serveurs qui transporte vos VLAN (les schémas de segmentation multi-hôtes et de DMZ vus plus haut), du KVM-over-IP pour des modifications réseau sans crainte, et une mitigation DDoS permanente en amont de tout, provisionné avec Proxmox VE préinstallé en moins d'une minute sur l'ASN 55285.

Poursuivez la série avec comment configurer vos premières VM et vos premiers conteneurs, LXC vs KVM : quand utiliser lequel, et les stratégies de sauvegarde avec vzdump et PBS.