Dans l’article sur les adresses MAC, on a vu comment un switch apprend qui est branché où, et pourquoi un broadcast finit par atteindre toutes les machines du réseau. C’est précisément ce « toutes » qui pose problème dès que le réseau grossit : les postes, les serveurs, l’imprimante, la caméra IP et le Wi-Fi invités se retrouvent dans la même pièce, à entendre les conversations des autres.

La réponse classique s’appelle le VLAN. Et plutôt que de partir de la norme, je vais partir d’une image qui m’a toujours servi pour l’expliquer : un switch physique qui contient plusieurs switchs virtuels, empilés les uns sur les autres, qui ne se voient pas.

Cet article se veut un complément à l’excellent guide Cisco ASA & Firepower FTD de @SilenS. Son guide découpe le réseau en zones (utilisateurs en VLAN 10, DMZ en VLAN 20, serveurs internes en VLAN 30, management en VLAN 99) et montre comment le pare-feu les protège. Ici, je descends d’un étage pour expliquer ce qu’est un VLAN et comment le switch le fabrique. J’ai repris sa numérotation et son plan d’adressage, pour qu’on puisse passer d’un article à l’autre sans rien retraduire.

L’essentiel en 30 secondes

  • Un VLAN (Virtual LAN) découpe un switch physique en plusieurs switchs virtuels étanches : chacun a ses ports, sa table d’adresses MAC et son propre domaine de broadcast.
  • Un port access appartient à un seul switch virtuel. La machine branchée dessus ne sait même pas que les VLAN existent.
  • Un port trunk transporte plusieurs switchs virtuels sur un seul câble. Pour savoir à quel VLAN appartient chaque trame, on lui colle une étiquette 802.1Q de 4 octets.
  • Deux VLAN ne se parlent jamais directement : il faut passer par la couche 3 (routeur, switch L3 ou pare-feu). C’est là qu’on filtre.
  • Un VLAN isole, il ne protège pas à lui seul : un trunk mal configuré suffit à percer la cloison.

Le problème : un switch, un seul domaine de broadcast

Un switch sorti du carton se comporte comme une multiprise intelligente. Tous ses ports appartiennent au même réseau de couche 2 : une requête ARP émise sur le port 1 est recopiée sur les 23 autres, une trame vers une MAC inconnue est inondée partout.

Tant qu’on a dix machines, personne ne s’en plaint. Mais dès qu’on veut séparer des usages, on tombe sur trois limites :

  • Le bruit : chaque broadcast (ARP, DHCP, mDNS, NetBIOS…) réveille toutes les cartes réseau du domaine. Sur quelques centaines de machines, ça se mesure.
  • La confidentialité : une machine compromise dans ce domaine peut écouter, usurper (ARP spoofing) ou scanner tout ce qui partage sa couche 2.
  • La politique : impossible de dire « les invités accèdent à Internet mais pas au NAS » si invités et NAS sont sur le même segment, car leur trafic ne passe par aucun équipement capable de filtrer.

La solution d’avant les VLAN, c’était d’acheter un switch par réseau. Un switch pour les utilisateurs, un pour la DMZ, un pour les serveurs, chacun relié à sa propre patte du routeur. Ça marche parfaitement… et ça coûte trois switchs, trois alimentations, trois fois plus de câbles et de place dans la baie.

L’image : une pile de switchs virtuels dans un châssis physique

Un VLAN, c’est exactement ce montage à trois switchs, mais logé dans un seul boîtier. Le switch physique devient un châssis qui héberge plusieurs switchs virtuels, et l’administrateur décide quel port en façade est câblé, en interne, sur quel switch virtuel.

Un switch physique découpé en trois switchs virtuels : VLAN 10 utilisateurs, 20 DMZ et 30 serveurs, avec un port trunk commun

Si on pousse l’image, tout le reste en découle naturellement :

Dans un vrai switch indépendant… …dans un VLAN
Il a ses propres ports Chaque port access est affecté à un seul VLAN
Il a sa propre table MAC La table CAM est indexée par le couple (VLAN, MAC) : la même MAC peut exister dans deux VLAN sans conflit
Un broadcast reste dans le boîtier Un broadcast ne sort que sur les ports du même VLAN
Deux switchs non câblés ne se parlent pas Deux VLAN ne se parlent pas sans routeur
On l’identifie par une étiquette sur la façade On l’identifie par un numéro, le VLAN ID (1 à 4094)

Un point me paraît essentiel à comprendre dès le départ : la machine branchée sur un port access ne voit rien de tout ça. Elle émet une trame Ethernet parfaitement ordinaire, sans aucune mention de VLAN. C’est le switch qui sait que le port 3 est câblé sur le switch virtuel 10, et qui s’arrange pour que la trame n’en sorte pas.

Relier les switchs virtuels entre deux châssis : le trunk

L’image tient tant qu’on a un seul switch. Mais dans une baie, on en a rarement un seul : un switch cœur, un switch d’étage, un point d’accès Wi-Fi, un hyperviseur. Et le VLAN 10 des utilisateurs doit exister partout.

Avec de vrais switchs séparés, il faudrait un câble par VLAN entre chaque paire de châssis. Trois VLAN, trois câbles ; vingt VLAN, vingt câbles. Intenable.

Le trunk règle le problème : un seul câble, sur lequel circulent les trames de tous les switchs virtuels. Mais à l’arrivée, le switch d’en face doit savoir sur quel switch virtuel remettre chaque trame. On ajoute donc, uniquement sur le trunk, une étiquette qui dit « cette trame appartient au VLAN 10 ».

Une trame part non taguée d’un port access, reçoit le tag VID 10 sur le trunk, puis est livrée non taguée sur le port access du même VLAN en face

Le cycle de vie d’une trame est toujours le même :

  1. Le PC A émet une trame non taguée sur son port access (VLAN 10).
  2. Le switch 1 la range dans son switch virtuel 10. La destination est de l’autre côté : il l’envoie sur le trunk en ajoutant le tag VID 10.
  3. Le switch 2 lit le tag, le retire, et remet la trame dans son propre switch virtuel 10.
  4. Le PC B la reçoit non taguée sur son port access. Il n’a jamais su qu’un tag avait existé.

Le serveur du VLAN 30 branché sur le switch 2 ne voit rien passer, même si la trame était un broadcast : elle n’a jamais été déposée dans son switch virtuel.

Anatomie du tag 802.1Q

L’étiquette est normalisée par l’IEEE 802.1Q. Elle fait 4 octets et s’insère dans l’en-tête Ethernet, juste après l’adresse MAC source, à l’endroit où l’on trouverait normalement l’EtherType.

Trame Ethernet sans tag et avec tag 802.1Q : TPID 0x8100, PCP, DEI et VID

Champ Taille Rôle
TPID 16 bits Toujours 0x8100. Placé là où le récepteur attend un EtherType, il lui signale « attention, ce qui suit est un tag ».
PCP 3 bits Priorité de 0 à 7 pour la qualité de service (l’ancien 802.1p, désormais intégré à 802.1Q). La voix sur IP s’en sert beaucoup.
DEI 1 bit Drop Eligible Indicator : « en cas de congestion, jette-moi en premier ».
VID 12 bits Le numéro de VLAN. 12 bits donnent 4096 valeurs, dont 0 (trame « priorité seule », sans VLAN) et 4095 (réservée) : il reste 1 à 4094.

Deux conséquences pratiques :

  • La trame grossit de 4 octets. La taille maximale passe de 1518 à 1522 octets (norme 802.3ac). Tous les équipements modernes le gèrent, mais une vieille carte ou un pilote mal fichu peut jeter ces trames « trop grandes ».
  • Le FCS est recalculé à chaque ajout ou retrait du tag, puisque le contenu de la trame change. C’est le travail du switch, invisible pour l’administrateur.

Quand 4094 VLAN ne suffisent pas (opérateurs, hébergeurs multi-clients), on empile deux tags : c’est le QinQ (IEEE 802.1ad), avec un tag externe 0x88A8. Hors sujet pour une infra perso, mais bon à connaître.

Le VLAN natif : la trame sans étiquette sur un trunk

Sur un trunk, que fait le switch d’une trame qui arrive sans tag ? Il la range dans le VLAN natif, par défaut le VLAN 1.

C’est un mécanisme de compatibilité (pour les équipements qui ne comprennent pas 802.1Q) et c’est aussi l’un des pièges les plus fréquents :

  • Si les deux extrémités d’un trunk n’ont pas le même VLAN natif, les trames non taguées sortent d’un VLAN côté A pour atterrir dans un autre côté B. Deux switchs virtuels se retrouvent soudés sans que personne ne l’ait voulu.
  • Le VLAN natif est la porte d’entrée de l’attaque par double étiquetage (double tagging) : un attaquant placé dans le VLAN natif forge une trame portant deux tags. Le premier switch retire le tag externe (celui du natif, qu’il n’enverrait jamais tagué sur le trunk), et le switch suivant lit le tag interne et livre la trame dans le VLAN cible. L’attaque est unidirectionnelle, mais elle traverse la cloison.

La parade est simple : choisir comme VLAN natif un VLAN inutilisé, sans aucune machine dedans (un « VLAN parking »), et le déclarer identique aux deux bouts.

Faire communiquer les switchs virtuels : le routage inter-VLAN

Revenons à l’image. Deux switchs physiques non reliés ne peuvent pas échanger de trames. Pour que le VLAN 10 (utilisateurs) atteigne le VLAN 30 (serveurs internes), il faut un routeur branché sur les deux, exactement comme avec des switchs séparés.

Trois façons de faire, par ordre de fréquence dans les petites infrastructures :

Méthode Principe Quand l’utiliser
Pare-feu / routeur « on a stick » Un seul lien trunk vers le pare-feu, qui a une sous-interface par VLAN (eth0.10, eth0.20…) et une passerelle par réseau Le cas le plus courant en PME et en infra perso : tout le trafic inter-VLAN passe par le pare-feu, donc tout est filtré et journalisé
Switch de couche 3 (SVI) Le switch lui-même porte une interface IP par VLAN et route en matériel Gros volumes inter-VLAN (serveurs ↔ stockage), quand le pare-feu deviendrait un goulot d’étranglement
Routeur à une patte par VLAN Un port physique du routeur par VLAN, en access Historique, ou quand le routeur ne sait pas faire de 802.1Q

Chaque VLAN correspond en pratique à un sous-réseau IP, avec sa passerelle sur l’équipement de routage. Dans le plan de @SilenS : VLAN 10 = 192.168.1.0/24, VLAN 20 = 10.0.10.0/24, VLAN 30 = 10.0.20.0/24. La correspondance VID ↔ sous-réseau n’obéit à aucune règle technique : l’important est qu’elle soit documentée et identique sur tous les équipements.

Et c’est ici que se joue la sécurité : c’est la règle de filtrage sur le routeur inter-VLAN qui protège, pas le VLAN. Un VLAN sans filtrage à sa frontière, c’est une cloison avec une porte grande ouverte.

Je m’arrête volontairement à cette frontière, parce que la suite est déjà traitée. Quelles zones créer, quels niveaux de sécurité leur donner, quelles ACL et quel NAT poser entre elles : c’est le cœur du guide de @SilenS, qui prend le relais exactement là où cet article s’arrête. Pour la même logique sur une solution libre, le guide pfSense montre les interfaces VLAN et le routeur « on a stick » en pratique.

Configurer les ports d’un switch

Côté switch, la configuration tient en quelques lignes. Exemple en syntaxe Cisco IOS, la plus répandue en formation, reprenant les VLAN du plan de @SilenS, avec un VLAN 999 inutilisé (« parking ») comme VLAN natif :

vlan 10
 name UTILISATEURS
vlan 20
 name DMZ
vlan 30
 name SERVEURS
vlan 99
 name MANAGEMENT
vlan 999
 name PARKING
!
interface range GigabitEthernet1/0/1 - 4
 description Serveurs internes
 switchport mode access
 switchport access vlan 30
 switchport nonegotiate
 spanning-tree portfast
!
interface GigabitEthernet1/0/24
 description Trunk vers pare-feu
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30,99
 switchport nonegotiate

Et pour vérifier :

show vlan brief
show interfaces trunk
show mac address-table vlan 30

Quand le switch virtuel devient littéral : l’hyperviseur

Sur un hyperviseur, l’image n’en est plus une. Proxmox VE, par exemple, crée un vrai switch logiciel (un pont Linux, vmbr0) auquel sont branchées les cartes réseau virtuelles des VM, et dont l’unique port physique est… un trunk vers le switch de la baie.

En mode VLAN aware, ce pont se comporte comme un switch 802.1Q complet :

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Il suffit ensuite d’indiquer un numéro dans le champ VLAN Tag de la carte réseau d’une VM : son port virtuel devient un port access dans ce VLAN. La VM émet des trames non taguées, le pont ajoute le tag en sortie vers eno1, exactement comme le switch 1 de tout à l’heure. Côté switch physique, le port relié à l’hyperviseur doit donc être configuré en trunk, avec les VLAN des VM autorisés.

bridge vlan show sur l’hôte affiche l’affectation de chaque port virtuel, l’équivalent direct de show vlan brief.

Là où l’image s’arrête

Les switchs virtuels d’un même châssis partagent plus de choses que de vrais switchs séparés, et c’est important de le savoir :

  • Le même processeur et le même fond de panier. Une tempête de broadcast dans le VLAN 10 ne sort pas du VLAN 10… mais elle peut saturer le CPU du switch et dégrader tous les autres.
  • Le même spanning tree, parfois. En STP ou RSTP classiques, il n’existe qu’un seul arbre pour tous les VLAN. MSTP permet de regrouper des VLAN en instances, et les variantes propriétaires (PVST+ chez Cisco) calculent un arbre par VLAN. Selon le cas, une boucle dans un VLAN peut bloquer des ports utilisés par les autres. J’ai détaillé tout ça dans l’article Spanning Tree Protocol : comprendre et déployer STP/MSTP.
  • La même configuration. Une seule commande mal placée (un port passé en trunk, un VLAN natif différent) soude deux switchs virtuels. Avec des switchs physiques séparés, il aurait fallu tirer un câble.
  • La même surface d’attaque. Sur certains équipements, un port laissé en négociation automatique (DTP chez Cisco) peut être convaincu par un attaquant de devenir un trunk : c’est l’usurpation de switch (switch spoofing), qui donne accès à tous les VLAN autorisés.

Autrement dit : le VLAN offre une isolation logique très efficace, pas une isolation physique. Pour des réseaux dont l’étanchéité est vitale, on reste sur du matériel séparé.

Les erreurs classiques

  • Tout laisser dans le VLAN 1. C’est le VLAN par défaut de tous les ports, souvent le VLAN natif et parfois celui du plan de gestion. On ne met rien dedans.
  • Un VLAN natif différent aux deux bouts d’un trunk. Les trames non taguées changent de VLAN en traversant le câble. Les switchs Cisco le signalent via CDP (native VLAN mismatch), beaucoup d’autres ne disent rien.
  • Oublier d’autoriser le VLAN sur le trunk. Le VLAN existe des deux côtés, le port access est bon, mais le trunk intermédiaire a une liste allowed qui ne le contient pas : la VM ou le poste n’obtient jamais de bail DHCP.
  • Laisser la négociation automatique active. Ports utilisateur en switchport mode access + nonegotiate, trunks déclarés explicitement. Jamais de mode « dynamic ».
  • Croire que le VLAN suffit. Sans règle sur le routeur inter-VLAN, le VLAN utilisateurs atteint le VLAN serveurs en un seul saut. Le filtrage est obligatoire (voir l’article de @SilenS pour la mise en œuvre).
  • Oublier le DHCP. Un serveur DHCP ne reçoit que les broadcasts de son propre VLAN. Pour servir les autres, il faut un relais DHCP (ip helper-address) sur l’interface de routage de chaque VLAN, ou un serveur par VLAN.
  • Mettre l’interface d’administration du switch dans le VLAN des postes. Le plan de gestion va dans le VLAN de management (le 99 dans le plan de @SilenS), point.

Ce que je retiens

Un VLAN, c’est un switch que l’on n’a pas eu besoin d’acheter. Tant qu’on garde en tête l’image du châssis qui héberge des switchs virtuels empilés, tout devient logique : un port access est câblé sur un seul d’entre eux, un trunk est un faisceau de câbles fusionnés en un seul grâce à l’étiquette 802.1Q, et deux switchs virtuels ne se parlent qu’à travers un routeur.

Le vrai travail commence d’ailleurs à ce routeur : le VLAN crée les pièces, c’est le pare-feu qui pose les serrures. Et pour poser ces serrures, place au guide de @SilenS, dont cet article n’est qu’un prérequis, puis à ce qu’un pare-feu lit vraiment dans vos paquets.

Sources et références