Aller au contenu

Exercice 2 — Segmenter le bridge avec des VLAN

Objectif

Segementer le switch virtuel vmbr1 en deux réseaux isolés, constater que deux conteneurs qui ont des adresses du même sous-réseau n'arrivent plus à se parler une fois qu'ils sont dans deux VLAN différents.

Prérequis

  • L'exercice 1 terminé : bridge vmbr1 et conteneurs 201 et 202 qui fonctionnent.
  • Le ping entre 192.168.100.11 et 192.168.100.12 doit répondre avant de commencer.

Étape 1 — Inspecter l'état du bridge avant de modifier la configuration

Ouvrez le Shell du nœud et affichez la table VLAN du switch virtuel.

Bash
bridge vlan show

Tous les ports, y compris veth201i0 et veth202i0, sont dans le VLAN 1

Tous les ports sont dans le VLAN 1. Cette table existe toujours, mais tant que le bridge n'est pas en mode VLAN aware, Linux ne la lit même pas. Le switch reste plat : tout le monde parle à tout le monde.

Étape 2 — Activer le mode VLAN sur le bridge

Allez dans System > Network, sélectionnez vmbr1 et cliquez sur Edit.

Cochez la case VLAN Aware, puis validez.

La fenêtre d'édition de vmbr1 avec la case VLAN Aware cochée

À partir de maintenant, le bridge donne un numéro de VLAN à chacun de ses ports. Et il refuse de faire passer une trame entre deux ports qui n'ont pas le même numéro. C'est tout le principe des VLAN : un seul switch, plusieurs réseaux qui s'ignorent.

Étape 3 — Appliquer la configuration

Cliquez sur Apply Configuration et confirmez. Le bridge est reconstruit avec le filtrage actif.

Vérifiez ce que Proxmox a écrit dans le fichier :

Bash
grep -A5 vmbr1 /etc/network/interfaces

Le bloc vmbr1 contient maintenant bridge-vlan-aware yes et bridge-vids 2-4094

Deux lignes se sont ajoutées. bridge-vlan-aware yes active le mode VLAN. bridge-vids 2-4094 donne la liste des numéros de VLAN que le bridge accepte : ici, tous ceux qui existent.

Astuce

L'option -A5 de grep affiche les 5 lignes qui suivent la ligne trouvée. C'est pratique pour voir tout le bloc de configuration d'une interface.

Étape 4 — Mettre le conteneur A dans le VLAN 10

Sélectionnez le conteneur 201, ouvrez son panneau Network et double-cliquez sur net0.

Mettez 10 dans le champ VLAN Tag. Ne touchez à rien d'autre : le bridge reste vmbr1 et l'adresse reste 192.168.100.11/24.

La fenêtre d'édition de net0 avec VLAN Tag à 10 et le bridge toujours à vmbr1

Note

Pas besoin de redémarrer le conteneur. Proxmox reconfigure directement le port du bridge, et le changement prend effet tout de suite.

Étape 5 — Mettre le conteneur B dans le VLAN 20

Refaites la même chose sur le conteneur 202, avec 20 dans VLAN Tag.

Vous avez maintenant une situation volontairement bizarre : deux machines qui ont des adresses du même sous-réseau 192.168.100.0/24, mais qui sont branchées dans deux réseaux séparés.

Étape 6 — Constater que ça ne passe plus

Ouvrez la Console du conteneur 202 et essayez de joindre le conteneur A.

Bash
ping -c 2 -W 2 192.168.100.11

Info

L'option -W 2 dit à la commande ping d'attendre 2 secondes pour chaque réponse. Sans ça, le ping attendrait 10 secondes par défaut.

Le ping part mais reste sans réponse, 100% packet loss, sans message d'erreur

Comparez avec l'étape 11 de l'exercice 1. Là-bas, le ping refusait de partir tout de suite, avec Network is unreachable. Ici, il part, et on attend dans le vide.

La différence vient de ce que croit le conteneur 202. Son masque /24 lui dit que 192.168.100.11 est sur son propre réseau, donc joignable directement. Il essaie, personne ne répond, il attend jusqu'au bout du délai. De son point de vue, le conteneur 201 a l'air éteint. Rien ne lui permet de deviner qu'il existe encore, juste ailleurs.

Étape 7 — Ajouter un troisième conteneur dans le VLAN 20

Est-ce que c'est le fait de mettre un tag qui casse le réseau ? Non, et voici comment le prouver : ajoutez un voisin au conteneur B, dans le même VLAN que lui.

Cliquez sur Create CT et reprenez les valeurs de l'exercice 1, en changeant celles-ci :

Champ Valeur
CT ID 203
Hostname ct-labo-c
Bridge vmbr1
IPv4/CIDR 192.168.100.13/24
VLAN Tag 20

Démarrez le conteneur.

Étape 8 — Tester à l'intérieur du VLAN 20

Depuis la console du conteneur 202 :

Bash
ping -c 2 192.168.100.13

Les deux pings répondent avec 0% packet loss et des temps de quelques centièmes de milliseconde

Mêmes temps de réponse qu'avant la segmentation. Le bridge fonctionne parfaitement, mais seulement entre ports du même VLAN.

Étape 9 — Lire la table VLAN du bridge

Retournez au Shell du nœud.

Bash
bridge vlan show

veth201i0 est dans le VLAN 10, veth202i0 et veth203i0 sont dans le VLAN 20, tous en PVID Egress Untagged

Cette table, c'est la vraie configuration du switch. Chaque port de conteneur est ce qu'on appelle un port d'accès (access port), et les deux mentions à droite disent pourquoi :

  • PVID : le VLAN dans lequel on met les trames qui arrivent sans étiquette. Comme le conteneur envoie toujours des trames sans étiquette, tout ce qu'il émet part dans ce VLAN-là.
  • Egress Untagged : l'étiquette est enlevée avant de rendre la trame au conteneur.

Résultat : le conteneur ne voit jamais d'étiquette VLAN, ni en entrée ni en sortie. Si vous faites ip -brief addr show à l'intérieur, vous verrez une carte réseau tout à fait ordinaire, et rien ne vous dira dans quel VLAN vous êtes. Tout se passe dans le bridge.

Question 1

Les trois conteneurs ont une adresse dans 192.168.100.0/24. Pourquoi le ping du VLAN 20 vers le VLAN 10 échoue-t-il ?

  • a) Un /24 est trop petit pour contenir deux VLAN.
  • b) Il manque un routeur pour passer d'un VLAN à l'autre.
  • c) La séparation se fait avant l'IP : la demande ARP n'arrive jamais dans l'autre VLAN.
Voir la réponse **c) La séparation se fait avant l'IP : la demande ARP n'arrive jamais dans l'autre VLAN.** Avant d'envoyer son ping, le conteneur `202` a besoin de l'adresse MAC de `192.168.100.11`. Il la demande à tout le monde en même temps, avec une requête ARP en broadcast. Le bridge ne recopie ce broadcast que sur les ports du VLAN 20. Personne ne répond, et le paquet ICMP n'est même jamais construit. Le choix b) est le plus tentant, et il est à moitié vrai : ça prendrait effectivement un routeur pour faire communiquer deux VLAN. Mais il faudrait d'abord leur donner deux sous-réseaux différents. Tant que les deux machines se croient sur le même réseau, elles ne chercheront jamais de routeur.

Question 2

Qu'est-ce qu'il faudrait faire pour qu'un switch physique branché sur nic1 reconnaisse vos VLAN 10 et 20 ?

  • a) Ajouter nic1 comme port de vmbr1, et configurer un port trunk du côté du switch.
  • b) Donner l'adresse 192.168.100.1/24 au bridge vmbr1.
  • c) Créer deux bridges séparés, un par VLAN.
Voir la réponse **a) Ajouter `nic1` comme port de `vmbr1`, et configurer un port trunk du côté du switch.** Un port trunk, c'est un port qui accepte les trames étiquetées de plusieurs VLAN sur un seul câble. Sans ça, le switch physique jetterait vos trames étiquetées, ou les mettrait toutes dans son VLAN par défaut. Le choix c) marcherait à l'intérieur du nœud, mais il faudrait un câble physique par VLAN. C'est exactement le problème que la norme 802.1Q a été inventée pour régler.

Expérimentations personnelles supplémentaires

  • Enlevez le VLAN Tag du conteneur 201, puis trouvez avec bridge vlan show dans quel VLAN son port est retombé.
  • Donnez au conteneur 201 une adresse dans 192.168.200.0/24, ce qui est plus cohérent avec le fait qu'il est dans un autre réseau. Refaites le ping depuis le 202 : le message d'erreur change complètement, et vous savez maintenant pourquoi.
  • Lancez tcpdump -i vmbr1 -e -n vlan sur le nœud pendant un ping, pour voir l'étiquette 802.1Q dans l'en-tête des trames.
  • Enchaînez avec l'exercice 3, qui reprend le même mécanisme sur le VLAN public du collège.