Exercice 1 — Créer un bridge interne et y raccorder deux conteneurs¶

Objectif¶

Créer un switch virtuel qui n'est branché à aucune carte réseau, y connecter deux conteneurs, et vérifier qu'ils se parlent entre eux alors qu'aucune trame ne sort du serveur.

Prérequis¶

Proxmox VE 9 installé et accessible à https://10.70.44.#:8006 (exercice 1, semaine 2).
Le gabarit Debian 13 standard déjà téléchargé dans le stockage local (exercice 3, semaine 2).
Au moins 8 Go libres sur local-lvm.

Étape 1 — Inspecter le réseau actuel du nœud¶

Ouvrez la console du nœud (Shell dans l'arborescence de gauche) et affichez les interfaces.

Bash

ip -brief addr show

Deux choses à remarquer. L'adresse IP du serveur est sur vmbr0, pas sur la carte réseau nic0. Et nic0 est bien allumée, mais elle n'a aucune adresse.

C'est normal, et c'est le principe du bridge. Un bridge, c'est un switch logiciel (donc virtuel). Quand on en crée un, la carte réseau devient un simple port de ce switch : elle transporte des trames entre les hôtes connectés au bridge, qu'ils soient virtuels ou physiques. L'adresse IP, elle, est affectée au bridge.

Note

Depuis Proxmox VE 9, les cartes réseau s'appellent nic0, nic1. Sur une installation plus ancienne, la même carte porterait un nom construit à partir de son emplacement dans la machine, du genre enp1s0 ou eno1.

Étape 2 — Lire le fichier de configuration¶

L'interface web ne fait que remplir un fichier texte. On se rappelle que Proxmox est dérivé de Debian et que la configuation réseau sous Debian réside dans /etc/network/interfaces. C'est ce fichier que Proxmox modifie quand on crée un bridge. Vérifiez son contenu.

Bash

cat /etc/network/interfaces

Regardez la ligne bridge-ports nic0. C'est elle qui branche le switch virtuel sur le câble physique. Et iface nic0 inet manual veut dire : active cette carte au démarrage de Proxmox, mais ne lui donne pas d'adresse IP.

Étape 3 — Créer le bridge vmbr1¶

Créez maintenant un deuxième switch virtuel, sans aucune carte réseau physique branchée dessus. Ce type de bridge est appelé un bridge interne. Il ne transporte que le trafic entre les machines virtuelles et les conteneurs qui y sont connectés et il n'existe qu'à l'intérieur de ce serveur Proxmox. Il n'a aucun lien avec le réseau physique.

Sélectionnez le nœud dans l'arborescence, puis System > Network. Cliquez sur Create > Linux Bridge.

Remplissez seulement le champ Name avec vmbr1. Laissez IPv4/CIDR, Gateway et Bridge ports vides, et cochez Autostart.

Un switch sans câble branché dessus, ça existe aussi en vrai. Les machines connectées dessus se parlent entre elles, et rien ne peut sortir. C'est exactement ce que vous venez de créer.

Étape 4 — Appliquer la configuration¶

Pour l'instant, Proxmox a seulement écrit la modification dans un fichier. Le noyau Linux, lui, n'est pas encore au courant. Cliquez sur Apply Configuration, puis confirmez.

Étape 5 — Vérifier que le bridge existe¶

Retournez dans le Shell du nœud.

Bash

ip -brief link show vmbr1

Le bridge est allumé et il a sa propre adresse MAC. Il n'a pas d'adresse IP, et c'est voulu : le nœud n'a rien à faire sur ce réseau, il se contente de l'héberger.

Étape 6 — Créer le premier conteneur¶

Cliquez sur Create CT en haut à droite et remplissez l'assistant avec ces valeurs.

Onglet	Champ	Valeur
General	CT ID	`201`
General	Hostname	`ct-labo-a`
General	Password	`ton-mot-de-passe-faible-préféré!:)`
Template	Template	`debian-13-standard_13.6-1_amd64`
Disks	Disk size	`4` Go
CPU	Cores	`1`
Memory	Memory	`512` Mo

À l'onglet Network, ce sont ces valeurs-là qui font tout l'exercice :

Champ	Valeur
Bridge	`vmbr1`
IPv4	`Static`
IPv4/CIDR	`192.168.100.11/24`
Gateway (IPv4)	laisser vide

Ne mettez pas de passerelle. Une passerelle, c'est l'adresse du routeur à qui envoyer les paquets destinés à l'extérieur. Ici il n'y a pas de routeur, donc pas de passerelle à indiquer.

Étape 7 — Créer le deuxième conteneur¶

Refaites exactement le même assistant, en changeant trois valeurs.

Champ	Valeur
CT ID	`202`
Hostname	`ct-labo-b`
IPv4/CIDR	`192.168.100.12/24`

Étape 8 — Démarrer les deux conteneurs¶

Sélectionnez chaque conteneur dans l'arborescence et cliquez sur Start. Vérifiez ensuite depuis le shell du nœud.

Bash

pct list

Étape 9 — Vérifier l'adresse du conteneur A¶

Ouvrez la Console du conteneur 201 et connectez-vous en root avec le mot de passe de l'étape 6.

Bash

ip -brief addr show eth0

Le @if7 mérite une explication. Le câble entre un conteneur et son bridge s'appelle une paire veth : deux interfaces virtuelles reliées bout à bout, comme les deux extrémités d'un vrai câble. eth0 est le bout côté conteneur, et if7 est le numéro du bout côté nœud.

Étape 10 — Tester la liaison entre les deux conteneurs¶

Toujours dans la console du conteneur 201 :

Bash

ping -c 3 192.168.100.12

Regardez les temps : quelques centièmes de milliseconde. Sur un vrai réseau, le simple passage dans un switch coûte déjà plus cher que ça. Ici rien n'est sorti du serveur, la trame a juste été recopiée d'une interface à l'autre en mémoire.

Étape 11 — Vérifier l'isolation du bridge¶

Depuis le même conteneur, essayez de joindre la passerelle du réseau de gestion.

Bash

ping -c 2 -W 2 10.70.0.1

L'échec est immédiat, il n'y a même pas d'attente. Le conteneur ne connaît qu'un seul réseau, 192.168.100.0/24, et il n'a pas de passerelle pour le reste. Il n'a donc aucune idée d'où envoyer ce paquet, et il abandonne avant même de l'envoyer.

Retenez ce message d'erreur

Network is unreachable veut dire que la machine ne sait pas par où passer. À l'exercice 2, vous couperez encore la communication entre deux conteneurs, mais le message sera complètement différent. La comparaison entre les deux vous dira où se situe le problème.

Étape 12 — Voir qui est branché sur le switch virtuel¶

Depuis le shell du nœud, listez les interfaces branchées sur les bridges.

Bash

bridge link show

Chaque conteneur apparaît sous la forme veth<VMID>i<n>, où <n> est le numéro de sa carte réseau. master vmbr1 indique sur quel bridge il est branché, et state forwarding que le port laisse bien passer les trames.

Ces interfaces n'existent que pendant que le conteneur tourne. Elles sont créées au démarrage et supprimées à l'arrêt. Si un conteneur éteint n'apparaît pas dans cette liste, c'est normal.

Vérification finale¶

Le bridge vmbr1 apparaît dans System > Network avec la colonne Ports/Slaves vide.
Le bridge vmbr1 n'a pas d'adresse IP.
Les conteneurs 201 et 202 sont en running.
Le ping de 192.168.100.11 vers 192.168.100.12 répond.
Le ping de 192.168.100.11 vers 10.70.0.1 renvoie Network is unreachable.

Question 1¶

Vous n'avez donné aucune adresse IP au bridge vmbr1. Pourquoi les deux conteneurs arrivent-ils quand même à se parler ?

a) Proxmox donne automatiquement une adresse cachée au bridge.
b) Un bridge travaille avec les adresses MAC, pas avec les adresses IP. Il n'a besoin d'aucune adresse pour recopier une trame.
c) Le trafic passe par vmbr0, puisque vmbr1 est incomplet.

Voir la réponse

**b) Un bridge travaille avec les adresses MAC, pas avec les adresses IP.** Le bridge note quelle adresse MAC il a vue arriver sur quel port, puis il recopie chaque trame vers le bon port. Il n'ouvre jamais le paquet IP qui est à l'intérieur. C'est le même fonctionnement qu'un switch de base qu'on branche sans le configurer. Le choix c) est le plus tentant, mais `bridge link show` montre que les deux `veth` ont `master vmbr1`. Rien ne passe par `vmbr0`. Un bridge a besoin d'une adresse IP seulement quand le nœud lui-même doit parler sur ce réseau. C'est le cas de `vmbr0`, qui porte l'adresse de gestion du serveur.

Question 2¶

Qu'est-ce qui se passerait si vous ajoutiez nic1 dans le champ Bridge ports de vmbr1 ?

a) Rien, tant qu'aucun câble n'est branché sur nic1.
b) Les conteneurs perdraient leur adresse IP.
c) Le nœud perdrait son accès de gestion.

Voir la réponse

**a) Rien, tant qu'aucun câble n'est branché sur `nic1`.** Le port serait ajouté au switch, mais un port sans câble ne transporte rien. Par contre, le jour où quelqu'un branche un câble, votre réseau de labo se retrouve d'un coup sur le réseau physique, sans que vous ayez rien reconfiguré. Le choix c) décrit ce qui arriverait avec `nic0`. Cette carte est déjà le port de `vmbr0` : la déplacer couperait le seul lien du serveur vers l'extérieur.

Expérimentations personnelles supplémentaires¶

Ajoutez un troisième conteneur en 192.168.100.13/24. Il joindra les deux autres sans configuration supplémentaire : le bridge apprend son adresse MAC dès la première trame qu'il envoie.
Lancez tcpdump -i vmbr1 -n icmp sur le nœud pendant qu'un ping tourne, pour voir les trames passer dans le bridge.
Donnez l'adresse 192.168.100.1/24 au bridge vmbr1. Le nœud devient alors joignable depuis les conteneurs : le bridge n'est plus seulement un switch, il devient aussi une machine sur ce réseau.