1. Le réseau Linux : du câble au bridge

1.1 De l'interface physique au bridge virtuel

Proxmox n'invente pas son propre système réseau — il s'appuie entièrement sur la pile réseau de Linux, avec ses bridges, ses interfaces et ses VLANs.

Quand vous installez Proxmox sur un serveur physique, votre carte réseau physique (ens18 sur les nœuds du lab) devient le point d'entrée du trafic. Mais cette interface physique ne connecte pas directement vos VMs et vos conteneurs — c'est le rôle du bridge Linux, appelé vmbr0 par convention.

Un bridge Linux est une interface virtuelle qui fonctionne comme un pont logiciel. Il permet de relier plusieurs domaines de broadcast : une interface physique de l'hôte, et les interfaces des machines virtuelles.

Un bridge configuré sur un hôte permet aux machines virtuelles qui y sont connectées de communiquer entre elles. Si une interface physique est liée au bridge, elles communiquent aussi avec le réseau physique.

Un bridge est une interface réseau à part entière. À ce titre, on peut le configurer exactement comme une interface physique : adresse IP, VLAN-aware, MTU, interface physique reliée.

Comment s'appelle votre carte réseau, au juste

La question paraît triviale ; elle est la première source de blocage dès qu'on crée un second bridge.

Les deux générations de noms.

eth0, eth1 — la convention historique. Simple, mais instable : l'ordre dépendait de celui où le noyau détectait les cartes, si bien qu'ajouter une carte pouvait renommer les autres et casser la configuration réseau au redémarrage.

ens18, enp6s18 — le nommage prévisible de systemd, celui de vos nœuds. Le nom encode l'emplacement matériel de la carte : ens18 est la carte du slot 18 ; enp6s18, son autre nom, se lit « ethernet, bus PCI 6, slot 18 ».

Il reste le même d'un démarrage à l'autre, tant que la carte ne change pas d'emplacement. Proxmox VE 9 sait aussi remplacer ces noms par des noms courts (nic0, nic1…) : c'est l'épinglage, rare, et vos nœuds ne l'utilisent pas.

L'onglet Network de pxe211, votre écran. Cinq cartes, ens18 à ens22. La colonne Alternative Names donne les autres noms de chacune (enp6s18, enxbc241101a111 pour ens18) : ils désignent la même carte.

En dessous, vmbr0, le pont qui porte l'adresse du nœud : 10.59.1.11/24, passerelle 10.59.1.1, sur le nœud du lab (le vôtre : 10.<site>.<N>.11).

La méthode, en trois questions. Quelle carte est réellement utilisée ? Celle dont la colonne Active vaut Yes : ici ens18.

Laquelle est déjà prise ? Celle qui apparaît dans la colonne Ports/Slaves d'un pont : ens18, sous vmbr0.

Laquelle reste disponible ? Toutes les autres, ens19 à ens22 — c'est l'une d'elles que vous attacherez à un nouveau pont.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Vue synthetique : nom, etat, adresse MAC
ip -br link

# Une carte, avec ses noms alternatifs
ip link show ens18

# La correspondance carte <-> pont, telle que Proxmox l'a ecrite
grep -E "iface|bridge-ports" /etc/network/interfaces

Résultat attendu sur pxe211 (Proxmox VE 9.2.21) :

root@pxe211:~# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens18            UP             bc:24:11:01:a1:11 <BROADCAST,MULTICAST,UP,LOWER_UP>
ens19            DOWN           bc:24:11:01:b1:11 <BROADCAST,MULTICAST>
ens20            DOWN           bc:24:11:01:c1:11 <BROADCAST,MULTICAST>
ens21            DOWN           bc:24:11:01:d1:11 <BROADCAST,MULTICAST>
ens22            DOWN           bc:24:11:01:e1:11 <BROADCAST,MULTICAST>
vmbr0            UP             bc:24:11:01:a1:11 <BROADCAST,MULTICAST,UP,LOWER_UP>

root@pxe211:~# ip link show ens18
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether bc:24:11:01:a1:11 brd ff:ff:ff:ff:ff:ff
    altname enp6s18
    altname enxbc241101a111

root@pxe211:~# grep -E "iface|bridge-ports" /etc/network/interfaces
iface lo inet loopback
iface ens18 inet manual
iface vmbr0 inet static
    bridge-ports ens18
iface ens19 inet manual

Trois choses se lisent d'un coup. vmbr0 porte la même adresse MAC que ens18 : un pont Linux adopte celle de son premier port. master vmbr0 dans ip link show ens18, et bridge-ports ens18 dans le fichier, disent la même chose : ens18 alimente vmbr0.

ens19 à ens22 sont DOWN, sans UP dans leurs drapeaux : les cartes existent, mais rien ne les utilise encore. Les noms altname sont ceux de la colonne Alternative Names de l'interface.

Créer ou modifier un bridge — via l'interface graphique :

Nœud → Network → Create → Linux Bridge

Ce que vous lisez sur cet écran. Un seul champ décide du comportement du pont : Bridge ports. S'il contient une carte physique, le pont communique avec le réseau ; s'il reste vide, le pont isole totalement les machines qui y sont branchées.

IPv4/CIDR n'est renseigné que si l'hôte lui-même doit être joignable sur ce pont. Autostart le fait remonter à chaque démarrage, et Comment — champ libre — vous évitera six mois plus tard de chercher à quoi sert ce pont.

C'est le même écran dans les trois cas que vous allez rencontrer : vmbr0 pour l'administration, vmbr1 pour le cluster, vmbr9 pour un réseau isolé. Seul le contenu de Bridge ports change vraiment d'un cas à l'autre.

Cliquez Create puis le bouton Apply Configuration en haut de la liste d'interfaces — sans ce second clic, les changements sont enregistrés mais pas encore actifs.

Les cinq cartes de votre nœud de lab

Votre serveur n'a pas deux cartes réseau, mais cinq. Ce n'est pas une générosité gratuite : chacune correspond à un flux qu'une infrastructure Proxmox sérieuse sépare physiquement, et vous les utiliserez toutes avant la fin de la formation.

Pourquoi séparer. Les trois derniers flux ont un point commun : ils sont volumineux et par rafales. Une réplication Ceph ou une migration à chaud sature un lien pendant quelques minutes.

Si Corosync partage ce lien, ses messages arrivent en retard et les nœuds se croient morts les uns les autres. Le cluster se fracture : un fencing en pleine journée, déclenché par une simple sauvegarde. Séparer les flux n'est donc pas une élégance d'architecte : c'est ce qui empêche une opération de routine de faire tomber le cluster.

Le pont dédié au cluster (vmbr1)

Un serveur destiné à rejoindre un cluster reçoit presque toujours un second pont, monté sur une carte distincte et réservé aux échanges entre nœuds. C'est le cas sur votre lab : la première carte porte déjà vmbr0, la deuxième attend d'être utilisée — c'est celle du réseau cluster du tableau ci-dessus. Relevez son nom exact avant de continuer : selon la version, elle s'appelle nic1, ens19 ou autrement.

Le pont vmbr1 en cours de création : ens19 dans Bridge ports, l'adresse Corosync du nœud dans IPv4/CIDR, COROSYNC dans Comment. Et Gateway laissé vide : ce réseau ne route rien vers l'extérieur, il ne fait que relier les serveurs entre eux.

Les trois nœuds partagent le même réseau, une adresse chacun — même préfixe, dernier octet différent :

Pourquoi ce réseau séparé. Corosync échange en permanence de petits messages entre les nœuds et supporte très mal la latence : quelques dizaines de millisecondes suffisent à lui faire croire qu'un nœud est mort.

Une sauvegarde ou une migration à chaud qui sature le réseau d'administration provoquerait alors une fausse détection de panne. C'est l'adresse de ce pont que la création du cluster désigne comme Link 0.

La même configuration est écrite automatiquement dans /etc/network/interfaces, le fichier de configuration réseau standard sous Debian :

# Configuration typique après installation de Proxmox
auto vmbr0
iface vmbr0 inet static
    address <ip-de-votre-noeud>/24   # IP de l'hyperviseur lui-même
    gateway <ip-de-la-passerelle>    # Passerelle par défaut
    bridge-ports ens18           # Interface physique attachée au bridge
    bridge-stp off               # STP désactivé (inutile sur un seul nœud)
    bridge-fd 0                  # Forward delay à 0 pour éviter les délais de bascule

bridge-stp off désactive le Spanning Tree Protocol (STP : le protocole qui évite les boucles entre switchs), inutile ici puisqu'il n'y a qu'un seul switch virtuel et aucun risque de boucle. bridge-fd 0 supprime le délai de 15 secondes que STP impose normalement avant de faire transiter du trafic. Avec STP actif, ce délai s'applique deux fois (écoute, puis apprentissage) : environ 30 secondes pendant lesquelles les invités du pont sont injoignables au démarrage.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Appliquer un changement réseau sans redémarrer la machine
ifreload -a

Qui écrit ce fichier : l'interface, pvesh, ou vous ?

C'est Proxmox qui gère /etc/network/interfaces. Dès qu'il le réécrit, il y place cet en-tête (sur pxe212) :

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.

La règle : on modifie le réseau par l'interface web, ou par pvesh, qui appelle la même API. L'édition à la main reste réservée à ce que l'interface ne sait pas faire, comme les règles de NAT du §2.4.

Les modifications ne s'appliquent pas tout de suite. Proxmox les écrit d'abord dans /etc/network/interfaces.new. Le bouton Apply Configuration, ou pvesh set /nodes/<nœud>/network, les applique.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Créer un pont sans carte physique (équivalent de Create → Linux Bridge)
pvesh create /nodes/pxe212/network --iface vmbr8 --type bridge --autostart 1 --comments "essai pvesh"
ip -br link show vmbr8                      # pas encore actif
pvesh set /nodes/pxe212/network             # = Apply Configuration
ip -br link show vmbr8                      # actif
pvesh delete /nodes/pxe212/network/vmbr8    # supprimer le pont
pvesh set /nodes/pxe212/network             # appliquer la suppression

Résultat attendu (nœud pxe212, Proxmox VE 9.2.21) :

Device "vmbr8" does not exist.
UPID:pxe212:0000EB83:001E055B:6AC517D7:srvreload:networking:root@pam:
vmbr8            UNKNOWN        a2:f5:7a:1c:cb:b5 <BROADCAST,MULTICAST,UP,LOWER_UP>

Avant l'application, le pont n'existe que dans interfaces.new : Device "vmbr8" does not exist. Après pvesh set, il est actif. La ligne UPID…srvreload:networking est la tâche de rechargement, la même que celle qu'affiche l'interface.

Revenons à la définition de base : un commutateur (switch) relie des machines sur un même réseau et leur fait passer les trames. Un pont Linux est un commutateur en logiciel, dans le noyau du nœud.

Un pont sans carte physique n'est pas en panne : c'est un réseau privé. Pour le faire sortir, on lui donne une adresse et une règle de NAT (§2.4).

Où voir le pont sur votre nœud :

Et à l'intérieur des invités ?

Proxmox fournit le câble virtuel et le pont. L'adresse IP, elle, dépend de l'invité :

Dans une VM Debian en q35, la carte VirtIO s'appelle en général ens18, comme sur le nœud. On le vérifie avec ip -br link dans la console de la VM, avant d'écrire sa configuration.

Bonnes pratiques

• Un segment, un pont, un rôle. vmbr0 pour l'administration et la sortie, un pont par réseau interne (applicatif, base de données). Des composants sans lien ne se voient pas, et les règles de pare-feu restent simples.
• L'adresse IP sur le pont, jamais sur la carte physique. La carte reste en inet manual.
• Tester aussi ce qui doit être bloqué. Un réseau isolé se vérifie par un ping qui doit échouer, pas seulement par ceux qui réussissent.

Dans le Shell du nœud :

# Exemple : le conteneur 100 ne doit PAS joindre 10.0.1.30
pct exec 100 -- ping -c 2 -W 2 10.0.1.30              # deux essais, deux secondes d'attente chacun
echo "code : $?"                                     # 0 : joint ; 1 : isolé

Résultat attendu (les lignes qui comptent) : 2 packets transmitted, 0 received, 100% packet loss, puis code : 1. Le ping échoue : l'isolation tient. Un code 0 signalerait au contraire une isolation défaillante.

À retenir : Proxmox s'appuie sur la pile réseau de Linux. La carte physique est rattachée à un pont (vmbr0), qui joue le rôle de commutateur virtuel pour les VM et les conteneurs. Un pont sans carte physique fait un réseau isolé.

vmbr1 est réservé au cluster. Le réseau se modifie par l'interface ou pvesh, et s'applique par Apply Configuration (pvesh set /nodes/<nœud>/network, ou ifreload -a après une édition à la main).