Semaine 3 — Le réseau virtuel : bridges, cartes et câbles qui n'existent pas¶
0. Plan de la séance¶
Théorie - Ce document : comment une VM (ou un conteneur) atteint le réseau physique. - Retour sur les VLAN : comment segmenter le réseau en morceaux étanches.
Pratique - Exercice 1 — Créer un bridge interne et y raccorder deux conteneurs - Exercice 2 — Segmenter le bridge avec des VLAN - Exercice 3 — Exposer un serveur web sur le VLAN public
Objectifs d'apprentissage¶
- Expliquer ce qu'est un bridge Linux et comment il achemine une trame.
- Justifier pourquoi l'adresse IP du nœud se trouve sur
vmbr0et non sur la carte physique. - Identifier les interfaces virtuelles créées par Proxmox pour une VM et pour un conteneur.
- Retrouver et lire la configuration réseau d'un nœud dans
/etc/network/interfaces. - Choisir entre un bridge raccordé à une carte physique et un bridge isolé selon le besoin.
1. Le problème de départ¶
Dans un centre de données, comme celui du local D3740, les serveurs de virtualisation, sont reliés à l'infrastructure physique par une ou deux cartes réseau. Chaque serveur, lui, doit faire tourner vingt, cinquante, parfois deux cents machines virtuelles. Chacune a besoin de sa propre carte réseau, sa propre adresse IP et sa propre adresse MAC.
Acheter deux cents cartes réseau n'est pas une option. Il faut donc que ces deux cents machines se partagent le même câble, sans se marcher dessus et sans savoir qu'elles le partagent.
La solution existe depuis longtemps dans le monde physique : c'est un switch. Dans le monde virtuels, vous l'aurez compris, le switch est remplacé par un bridge qui fait exactement le même travail.
2. Le bridge Linux, c'est un switch en logiciel¶
Un bridge (le mot français « pont » est peu employé en pratique) fait exactement le travail d'un switch physique. On lui branche des interfaces, qu'on appelle ses ports, et il fait passer les trames de l'une à l'autre.
Son fonctionnement tient en trois règles :
- Quand une trame arrive sur un port, le bridge note l'adresse MAC source et se souvient qu'elle est joignable par ce port. C'est ce qu'on appelle l'apprentissage (MAC learning).
- Il regarde ensuite l'adresse MAC de destination. S'il sait sur quel port elle se trouve, il recopie la trame sur ce port-là uniquement.
- S'il ne le sait pas encore, ou si la destination est une adresse de diffusion (broadcast), il recopie la trame sur tous les ports sauf celui d'où elle vient.
flowchart LR
VM1["VM 1<br/>tap100i0"] --- BR
VM2["VM 2<br/>tap101i0"] --- BR
CT["CT 201<br/>veth201i0"] --- BR
BR["vmbr0<br/>(bridge Linux)"] --- NIC["nic0<br/>carte physique"]
NIC --- SW["Switch du collège"]
Le point important : le bridge travaille avec les adresses MAC, jamais avec les adresses IP. Il n'ouvre pas le paquet qui est à l'intérieur de la trame. C'est pour ça qu'on parle d'un équipement de niveau 2, la couche liaison du modèle OSI. 🤮 je sais...
Le point important : un bridge n'a besoin d'aucune adresse IP pour fonctionner. Vous le testerez à l'exercice 1, avec deux conteneurs qui se parlent à travers un bridge qui n'a aucune adresse.
3. Pourquoi l'adresse IP est sur vmbr0¶
Quand vous installez Proxmox, l'installateur crée un bridge nommé vmbr0, y branche votre carte réseau, et met l'adresse IP du serveur sur le bridge. La carte physique, elle, se retrouve sans adresse.
iface nic0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.70.44.10/24
gateway 10.70.0.1
bridge-ports nic0
Ça paraît abstrait la première fois. La logique est simple : à partir du moment où la carte devient un port de switch, elle n'est plus qu'un tuyau. Lui donner une adresse reviendrait à donner une adresse IP à un port de switch physique, ce qui n'a pas de sens.
Le nœud Proxmox, lui, a besoin de parler sur le réseau : c'est lui qui héberge l'interface web sur le port 8006. Il se branche donc sur son propre switch, comme n'importe quelle VM. vmbr0 est à la fois le switch et la prise réseau du serveur.
Note
Le nom vmbr veut dire virtual machine bridge. La numérotation vmbr0, vmbr1, vmbr2 est une convention de Proxmox, pas une contrainte de Linux.
4. Le câble virtuel entre la machine et le bridge¶
Il manque encore une pièce. Le bridge a des ports, mais comment une VM s'y branche-t-elle ?
Proxmox crée, au démarrage de chaque machine, une interface virtuelle qu'il branche sur le bridge. Son nom dépend du type de machine :
| Type | Nom de l'interface | Technologie |
|---|---|---|
| VM (KVM) | tap<VMID>i<n> — par exemple tap100i0 |
interface TAP |
| Conteneur (LXC) | veth<VMID>i<n> — par exemple veth201i0 |
paire veth |
Dans les deux cas, <VMID> est le numéro de la machine et <n> le numéro de sa carte réseau. Une VM 100 avec deux cartes aura donc tap100i0 et tap100i1.
Une paire veth, c'est littéralement un câble virtuel : deux interfaces créées ensemble et reliées bout à bout. Tout ce qui entre par un bout ressort par l'autre. Un bout est branché sur le bridge, l'autre se retrouve à l'intérieur du conteneur, où il s'appelle eth0.
C'est ce que révèle la notation eth0@if7 que vous verrez à l'exercice 1 : le eth0 du conteneur est l'autre extrémité de l'interface numéro 7 du nœud.
Important
Ces interfaces n'existent que pendant que la machine tourne. Elles sont créées au démarrage et détruites à l'arrêt. Si vous cherchez le veth d'un conteneur éteint, vous ne le trouverez pas : ce n'est pas une panne.
5. Où vit la configuration¶
Proxmox utilise ifupdown2, l'outil de configuration réseau de Debian. Toute la configuration du nœud tient dans un seul fichier :
L'interface web ne fait que remplir ce fichier. Ce qui explique un comportement qui déroute souvent :
- Vous créez un bridge dans l'interface web et vous validez. Proxmox écrit vos changements dans un fichier d'attente,
/etc/network/interfaces.new. Le noyau Linux n'est au courant de rien. - Vous cliquez sur Apply Configuration. Proxmox remplace le vrai fichier par celui en attente, puis lance
ifreload -apour demander au noyau d'appliquer les différences.
C'est pour ça que vos modifications restent affichées en surbrillance tant que vous n'avez pas appliqué. Et c'est aussi pour ça qu'un redémarrage du serveur, dans ce laps de temps, perd tout ce que vous n'avez pas appliqué.
Vous pouvez faire les deux étapes à la main depuis le shell : éditer le fichier, puis lancer ifreload -a. C'est ce que vous ferez à l'exercice 3, pour un réglage que l'interface web n'expose pas.
6. Les autres types d'interfaces¶
Le bridge n'est pas le seul objet réseau que Proxmox sait créer. Vous les rencontrerez plus tard dans la session, mais il vaut la peine de savoir qu'ils existent :
| Type | À quoi ça sert |
|---|---|
| Linux Bond | Regrouper plusieurs cartes physiques en une seule, pour le débit ou la tolérance de panne. |
| Linux VLAN | Créer une sous-interface dédiée à un seul VLAN, du genre vmbr0.460. C'est l'autre façon de faire des VLAN, celle qu'on verra dans la note suivante. |
| OVS Bridge | Un bridge Open vSwitch, plus riche en fonctions, utilisé quand on a besoin de règles de commutation avancées. |
| SDN | Le module de réseau défini par logiciel de Proxmox, qui automatise la création de réseaux à l'échelle d'une grappe entière. |
Pour ce cours, le bridge Linux suffit largement. C'est aussi ce que la très grande majorité des installations utilisent en production.
7. Deux bridges, deux usages¶
Un bridge peut être raccordé à une carte physique, ou pas. C'est ce seul détail qui décide de tout.
Bridge raccordé (bridge-ports nic0) |
Bridge isolé (bridge-ports none) |
|
|---|---|---|
| Les machines se parlent entre elles | oui | oui |
| Les machines joignent le réseau physique | oui | non |
| Usage typique | production, accès au réseau de l'entreprise | labo, réseau interne, DMZ derrière un pare-feu virtuel |
Un bridge isolé est très utile en vrai, et pas seulement en classe. C'est la façon normale de brancher un réseau entre deux VM qui ne doivent parler qu'entre elles, par exemple un serveur d'application et sa base de données.
Vérification des acquis¶
Question 1¶
Sur un nœud Proxmox fraîchement installé, où se trouve l'adresse IP de gestion ?
- a) Sur
nic0, la carte réseau physique. - b) Sur
vmbr0, le bridge. - c) Sur les deux, pour assurer la redondance.
Voir la réponse
**b) Sur `vmbr0`, le bridge.** La carte physique devient un port du switch virtuel et passe en `manual`, c'est-à-dire allumée mais sans adresse. Le nœud se branche sur son propre bridge comme n'importe quelle VM, et c'est le bridge qui porte l'adresse. Le choix a) est celui qu'on donne spontanément, parce que c'est la carte qui porte le câble. Mais lui donner une adresse reviendrait à en donner une à un port de switch physique.Question 2¶
Un bridge Linux reçoit une trame dont il ne connaît pas encore l'adresse MAC de destination. Que fait-il ?
- a) Il jette la trame et renvoie une erreur à l'émetteur.
- b) Il la recopie sur tous ses ports, sauf celui d'où elle vient.
- c) Il consulte la table de routage du noyau.
Voir la réponse
**b) Il la recopie sur tous ses ports, sauf celui d'où elle vient.** C'est le comportement normal d'un switch. La machine visée répondra, et le bridge apprendra à ce moment-là sur quel port elle se trouve. Les trames suivantes ne partiront que vers ce port. Le choix c) confond deux couches. Un bridge travaille au niveau 2, sur les adresses MAC. La table de routage sert au niveau 3, pour décider où envoyer un paquet IP, et c'est le travail d'un routeur.Question 3¶
Vous créez un bridge vmbr1 sans lui donner d'adresse IP ni de port physique, et vous y branchez deux VM. Que se passe-t-il ?
- a) Rien, un bridge sans adresse IP ne peut pas fonctionner.
- b) Les deux VM se parlent entre elles, mais ne joignent rien d'autre.
- c) Les deux VM sortent quand même par
vmbr0.
Voir la réponse
**b) Les deux VM se parlent entre elles, mais ne joignent rien d'autre.** Le bridge commute les trames d'après les adresses MAC, ce qui ne demande aucune adresse IP. Comme aucune carte physique n'est branchée dessus, il n'existe simplement aucun chemin vers l'extérieur. Le choix c) suppose que Linux chercherait une autre sortie de lui-même. Il n'en fait rien : une machine branchée sur un bridge ne connaît que ce bridge.Question 4¶
À quoi sert le fichier /etc/network/interfaces.new ?
- a) C'est une sauvegarde de la configuration précédente.
- b) Il contient les modifications en attente, pas encore appliquées au noyau.
- c) Il est utilisé seulement lors de l'installation de Proxmox.