Les réseaux logiques (VLANs)

1. Un peu de théorie

Pour bien comprendre ce que sont les VLANs (Virtual Local Area Network), il convient d’introduire certains concepts réseau théoriques. Pas de panique, la pratique sera extrapolée vers la théorie et non l’inverse. Nous allons commencer par discuter les modèles OSI et TCP/IP via le scénario d’un utilisateur effectuant une connexion SSH sur une machine distante située sur le même commutateur (ou switch). Cette introduction au modèle OSI nous aidera à positionner les VLANs dans la pile réseau. Nous allons ensuite préciser le phénomène d’encapsulation. C’est primordial pour l’étude des VLANs car toute la logique repose sur ce phénomène.

1.1 Les modèles OSI et TCP/IP

Quand on parle de réseau, une foultitude de termes vient immédiatement à l’esprit : RJ45, WiFi, fibre optique, 802.3, Ethernet, TCP/IP, etc. Ces termes se réfèrent soient à des médias, soit à des protocoles. Une communication réseau est un transfert d’information entre deux pairs. Le média est le canal physique utilisé par les deux pairs pour communiquer. Le protocole structure l’information de la communication afin qu’elle soit compréhensible par les deux pairs. Une communication peut impliquer une succession de médias hétérogènes. Par exemple, lorsque vous vous connectez à un site Web distant, le premier média peut être votre réseau sans fil entre votre ordinateur et votre box. La communication passe ensuite en ADSL sur Internet. Elle termine ensuite en filaire chez le propriétaire du site Web. La même information transite donc sur trois médias différents. On touche du doigt le fait qu’il doit y avoir une indépendance totale entre le média et la communication réseau à proprement parler.

Pour illustrer le modèle OSI, prenons l’exemple d’un utilisateur sur une machine A se connectant en SSH à une autre machine B située sur le même segment LAN. Dans notre exemple, le segment LAN est l’ensemble des machines connectées au commutateur (ou switch). Les deux renseignements que l’on fournit à la commande SSH sont le nom d’utilisateur distant et l’IP de la machine ciblée. Le port TCP du serveur SSH destination est implicitement fixée à 22. Nous avons donc trois protocoles explicitement impliqués : IP, TCP et SSH. IP fait transiter les données entre les deux machines. TCP établit la connexion entre les deux extrémités concernées (qui sont en fait des sockets réseaux) à savoir le client SSH sur la machine A et le serveur SSH sur la machine B. En effet, chaque machine peut héberger de multiples services réseau et aussi établir des connexions vers plusieurs destinations. Il ne suffit donc pas d’être capable d’acheminer l’information d’un point A à un point B (IP), il faut être capable de savoir à quel service de B livrer ces informations (TCP). On peut dire qu’IP et TCP sont complémentaires (c’est pour ça qu’on parle de TCP/IP, TCP sur IP), ou plus précisément que TCP utilise les services d’IP pour établir une communication de bout en bout entre deux extrémités (socket) réseau. Une extrémité est donc un couple IP / Port dans le monde TCP/IP. Enfin, le protocole SSH définit les primitives utilisées par le processus client et le processus serveur SSH pour communiquer entre eux via la connexion TCP/IP établie.

Il manque une pièce dans le puzzle présenté ci-dessus. Nous n’avons considéré que des extrémités « logiques ». À un moment, il faut quand même acheminer les paquets réseaux d’une interface physique de A à l’autre sur B. Ceci est possible grâce à l’utilisation d’un protocole chargé de gérer le média physique (c’est-à-dire les interfaces et le câble) : Ethernet 802.3. Ce protocole attache à chaque interface une adresse MAC (Media Access Control). Cette adresse est inscrite dans le contrôleur de l’interface, elle n’est pas configurée dans le système d’exploitation (bien que les outils du système d’exploitation puissent la changer). En résumé, nous avons donc une communication SSH qui dépend de TCP (pour toucher la bonne extrémité sur la machine cible), s’appuyant sur IP (pour toucher la bonne interface logique) et enfin le tout utilise l’Ethernet 802.3 (pour toucher la bonne interface physique).Un modèle académique a été introduit pour normaliser ces différentes couches. Il s’agit du modèle OSI (Open Systems Interconnection). Ce modèle se compose de 7 couches, de la plus basse à la plus haute : physique, liaison, réseau, transport, session, présentation et application.

La couche physique concerne la transmission du signal. Il s’agit de transmettre les bits de données de A vers B. La couche liaison (Ethernet 802.3) gère la communication de deux machines reliées par un même média physique (cas de deux machines interconnectées par un commutateur). La couche réseau (IP) intègre des mécanismes de routage pour livrer des paquets qui ne sont pas forcément à destination du segment LAN. La couche transport (TCP ou UDP) définit des ports qui sont attachés (bind) à un service réseau. La couche session gère les transactions, essentiellement les ouvertures et fermetures de session. La couche présentation définit le codage des données applicatives transmises. Enfin la couche application contient toute la batterie de protocoles de haut niveau utilisée par les applications des utilisateurs finaux (HTTP, SSH, DNS etc.).

1.2 En-têtes et encapsulation

Dans un modèle en couches, l’idée est que la couche N va utiliser les services de la couche N-1. Chaque protocole fonctionne sur le modèle en-tête suivi de la charge applicative (payload). Reprenons le modèle OSI à partir de la couche liaison. Nous avons vu que le service au niveau de cette couche est assuré par le protocole Ethernet 802.3. Ce protocole prend en en-tête l’adresse MAC destination et source. Sa charge applicative est le paquet IP. IP est donc encapsulé dans la trame Ethernet 802.3. La couche réseau utilise les services de la couche liaison. L’en-tête d’un paquet IP est l’adresse destination suivi de la source. Sa charge applicative est le paquet TCP. L’en-tête du paquet TCP contient les ports source et destination. Sa charge applicative est la requête SSH. Ces encapsulations sont à la charge de la pile réseau de l’émetteur. Ces encapsulations successives sont schématisées dans la figure 1. Le décapsulage est à la charge du destinataire.

1.3 De l’IP vers l’Ethernet

Reprenons l’exemple de la connexion SSH et plus précisément l’envoi d’un paquet réseau de la machine A vers la machine B. Tout ce qui est au-dessus du niveau 3 (réseau) du modèle OSI est hors sujet de cet article. Le propos ici est d’amener un paquet de l’interface réseau de A jusqu’à l’interface de B. Au niveau de A, nous ne connaissons que l’IP de B. Comme nous l’avons vu dans la section précédente, chaque interface réseau dispose de sa propre adresse MAC (adresse « physique », niveau 2 de l’OSI). A va donc commencer par récupérer l’adresse MAC de B. Cela se fait via un protocole nommé ARP (Address Resolution Protocol). Une adresse MAC à une taille de 6 octets et elle est souvent présentée en hexadécimal. A va envoyer une requête ARP who-has à une adresse MAC particulière, l’adresse de broadcast (FF:FF:FF:FF:FF:FF). Le principe du broadcast est d’arroser « tout le réseau ». Cette notion de « tout le réseau » est différente selon le niveau du modèle OSI où on se positionne. Si on est au niveau liaison en Ethernet, il s’agit du segment LAN. Si on est au niveau réseau en IP, il s’agit de toute la plage. Cette requête sert à demander « quel est l’adresse MAC associée à l’IP B ? ». Comme c’est envoyé sur l’adresse de broadcast, toutes les machines du segment LAN reçoivent cette requête. La machine concernée (B) envoie une réponse ARP reply à A avec son adresse MAC. À partir de là A peut établir une liaison (au sens niveau 2 du modèle OSI) avec B.

2. Les VLANs

Les VLANs sont définis dans la norme 802.1Q. Cette norme spécifie un tag qui est inséré dans les en-têtes de la trame Ethernet. Ce tag comprend essentiellement un VID (VLAN Identifier). En effet chaque VLAN est défini par un entier positif, le VID. Ce tag peut être ajouté au moment de la génération de la trame par la machine ou par le commutateur lors du passage de la trame (voir figure 2). Ce dernier cas entraîne un recalcul du FCS (Frame Check Sequence). L’idée est que ce tag indique au commutateur à quel VLAN circonscrire la trame réseau. Un effet direct des VLANs est une limitation des domaines de brodacast Ethernet. Nous allons examiner plusieurs scénarios basiques d’utilisation des VLANs en précisant les parts de configuration à la charge de la machine et à la charge du commutateur. Nous allons baser nos exemples sur des machines tournant sous Debian et un commutateur Juniper embarquant JunOS (un dérivé de FreeBSD).

Il faut bien comprendre qu’avant l’avènement des VLANs, un routeur A ne pouvait envoyer au commutateur B (non manageable) qu’un seul réseau et l’on devait, dès lors, avoir un deuxième lien physique vers un autre commutateur pour envoyer un autre réseau. Autant dire que l’occupation d’un bâtiment au sens informatique du terme était avant toutes choses affaire de regroupement d’un maximum de personnes travaillant dans le même service, voire dans le pire des cas et faute de moyens la mise en commun de personnes sans aucune interaction les unes avec les autres mais contraintes de partager le même réseau. Assurer la sécurité du SI était alors plus que problématique.

Avec l’apparition du VLAN, le routeur envoie désormais les réseaux via un lien 802.1Q sur un même et unique média (fibre, cuivre, WiFi, etc.) vers les commutateurs. Ces derniers gérant les VLANs, peuvent dès lors avec leur matrice de commutations multi-vlan affecter à un port un vlan indépendamment de la configuration des autres ports. Le confinement ainsi assuré, des utilisateurs sans aucun lien peuvent désormais partager le même commutateur physique en ne se trouvant « que dans leur réseau ». Cette avancée technique a permis, outre une meilleure gestion des mètres carrés d’un bâtiment, de substantielles économies sur le tirage de rocades d’interconnexions et sur l’achat de commutateurs mutualisés.

2.1 Mode « access »

Le mode « access » propose de mettre un port du commutateur dans un VLAN donné. La figure 3 présente un exemple simple de découpage en VLAN configuré en port mode access. Dans cet exemple le commutateur dispose de 4 ports numérotés de 1 à 4. Les ports 1 et 4 sont dans le VLAN identifiés par le VID 3 tandis que les ports 2 et 3 sont dans le VLAN possédant le VID 4. La machine A est connectée au port 1, les machines B et C sont connectées aux ports 2 et 3 et la machine D est connectée au port 4. Le commutateur est donc divisé de façon logique en deux segments LAN. Ainsi la machine A ne peut parler qu’avec D et B ne peut parler qu’avec C. Voyons en pratique comment réaliser un telle configuration sur notre commutateur Juniper pour le port numéro 1 (c’est la même histoire pour les trois autres) :

Dans cette séquence de commandes, on commence par passer le commutateur en mode configuration. Ensuite on crée le VLAN. La chaîne de caractère VLAN003 est libre : on peut mettre ce que l’on veut. En revanche, le paramètre vlan-id est l’identifiant numérique attaché au VLAN utilisé comme tag dans les trames. Nous allons maintenant configurer le port 1 du commutateur. Ce port est nommé ge-1/0/1 dans la logique de numérotation Juniper. La première commande set interface passe le port du commutateur en mode access. La seconde définit le VLAN dans lequel ce port est positionné.

Fig. 3 : Commutateur mode « access »

2.2 Mode « 802.1Q »

Dans ce mode, le port du commutateur s’attend à recevoir des trames déjà taguées par l’émetteur. La configuration se fait donc à la fois côté commutateur et côté machine connectée. La terminologie pour un tel lien est multiple : « port trunk », « lien 802.1Q », etc. Nous allons voir comment configurer une interface de VLAN sur une machine Linux et comment passer un port en mode « trunk » sur notre commutateur Juniper. Le but de la manipulation est de multi-domicilier la machine A dans les VLANs 3 et 4.

2.2.1 Configuration de la machine

Sous Linux, le support des VLANs dépend de deux parties : un module noyau nommé 8021q et une collection d’outils en espace utilisateur pour configurer les interfaces. Le module noyau est disponible dans le système de base de Debian, il suffit de le charger :

Pour rendre le chargement du module persistant au redémarrage il faut ajouter la ligne suivante dans le fichier /etc/module :

Pour la partie outils en espace utilisateurs, il faut installer le package vlan :

Nous allons ensuite créer une interface pour le VLAN 3. Cette interface réseau est une interface logique créée au-dessus d’une interface réelle (par exemple eth0). La seule chose à spécifier lors de la création de cette interface logique est l’identifiant de VLAN (le VID). Le but de cette interface est de taguer une trame avec pour identifiant le VID spécifié lorsqu’elle est émise et de retirer le tag (si le VID de la trame correspond au VID de l’interface de VLAN) pour le faire traiter par la pile réseau. Pour créer une interface de VLAN, il faut utiliser la commande vconfig :

Cette commande va créer une interface eth0.3. Cette interface est une interface logique pour le VLAN 3 construite au-dessus de eth0. Pour l’activer :

Il faut juste répéter ces étapes pour configurer une interface dans le VLAN 4.

2.2.2 Configuration du commutateur

Côté commutateur, la donne a changé sur le port 1. Il faut maintenant qu’il accepte les paquets tagués avec les VID 3 et 4. Il faut donc reconfigurer le port 1 du commutateur en mode 802.1Q. Chez Juniper (comme chez Cisco d’ailleurs) ce mode est appelé « trunk » (voir figure 4) :

Cette étape n’est pas suffisante car nous voulons tout de même restreindre les VID pouvant transiter par le port. Il faut les spécifier en tant que members du lien 802.1Q sinon le port traitera tous les paquets tagués.

À présent, la machine A étant bi-domiciliée dans les deux VLANs et le port étant configuré pour accepter les paquets des deux VLANs, A peut communiquer avec B et C. Nous avons établi une liaison (au sens 2 du modèle OSI) entre les trois machines.

2.3 Et le niveau réseau ?

Établir une liaison entre des machines n’a que peu d’intérêts si les processus tournant dessus ne peuvent pas communiquer. Or dans le monde actuel, les machines communiquent quasiment exclusivement en IP. Nous allons donc voir comment combiner le niveau liaison et réseau pour obtenir des réseaux IP cloisonnés logiquement. Une bonne pratique est de superposer un VLAN et un réseau IP. Dans notre exemple, nous pourrions décider que le VLAN 3 superpose le réseau IP 192.168.3.0/24 et que le VLAN 4 superpose le 192.168.4.0/24. Le but de la manipulation va être que les machines des deux VLANs puissent toutes communiquer entre elles en IP tout en appartenant à des VLANs différents. La machine A servira de passerelle entre les deux VLANs. Nous allons fixer la topologie réseau :

Pour les machines B, C et D il s’agit d’une configuration classique. Pour la machine A c’est un peu plus compliqué. Pour mémoire, A dispose de deux interfaces : eth0.3 et eth0.4. L’interface eth0.3 va prendre l’IP 192.168.3.254 et eth0.4 l’IP 192.168.4.254 :

Examinons maintenant la table de routage de A :

Les deux dernières règles sont des règles implicites qui ont été générées au moment où les interfaces eth0.3 et eth0.4 ont été configurées avec ifconfig. Ces deux règles signifient : pour toucher le réseau 192.168.3.0/24 passer par eth0.3 et pour toucher le réseau 192.168.4.0/24 passer par eth0.4. Cela ne permet pas pour autant à un paquet de passer d’un réseau IP à l’autre. Il faut activer l’IP forwarding :

Il faut également spécifier comme passerelle par défaut le 192.168.3.254 (eth0.3) pour les machines du VLAN 3 et le 192.168.4.254 (eth0.4) pour les machines du VLAN 4.

À partir de ce moment, le transfert de paquets IPv4 est autorisé entre les interfaces de la machine. Quand une trame va arriver du VLAN 3 à destination d’une machine du VLAN 4, le paquet va arriver sur la passerelle par défaut. Le domaine de brodcast est limité par les VLANs donc le who-has ARP échoue sur la machine du VLAN 3, elle va donc envoyer la trame à sa passerelle par défaut : eth0.3 de A. La pile réseau de A va examiner la destination du paquet. Cette destination est dans le VLAN 4. L’IP forwarding étant activé, A va router le paquet vers l’interface eth0.4 qui va faire un who-has ARP couronné de succès. A va donc encapsuler le paquet dans une trame à destination de la machine cible via eth0.4.

Pour inscrire cette configuration en dur, il faut ajouter les lignes suivantes dans le fichier /etc/network/interfaces de A :

Et aussi activer l’IP forwarding dans le fichier /etc/sysctl.conf :

La configuration est maintenant persistante au redémarrage. Évidemment il est possible (et souhaitable) d’ajouter des règles de filtrage iptables sur A entre eth0.3 et eth0.4 pour éviter que n’importe quoi transite d’un VLAN à l’autre. On notera que le travail qui a été fait sur A est tout à fait réalisable directement sur le commutateur (selon ses capacités de management). Pour cela, il faut définir les interfaces de VLAN sur le commutateur :

Ensuite, selon ses capacités, le commutateur peut filtrer / router le trafic inter-VLANs (voir figure 5). Certains services peuvent aussi être déployés directement sur le commutateur attaché aux interfaces de VLAN (comme un serveur DHCP servant un pool dans la plage IP superposant le VLAN).

3. Utilisation avancées des VLANs

Dans cette section nous allons voir une fonctionnalité méconnue des équipements de commutation : le « native VLAN ». Cette fonctionnalité est d’un grand secours lorsqu’une machine connectée au commutateur ne sait pas taguer une trame Ethernet et que l’interface du commutateur attend des paquets tagués (mode 802.1Q). Nous allons ensuite montrer comment les VLANs peuvent participer à l’interconnexion de réseau entre eux. Enfin, nous allons mentionner quelques outils construits au-dessus des VLANs.

3.1 Native VLAN

C’est un VLAN spécifique qui confine les trames non taguées. Autrement dit, sur un port 802.1Q les trames Ethernet non taguées par un ID sont placées dans le native VLAN. Ce VLAN va faire transiter l’ensemble des protocoles non tagués à l’instar de CDP, Spanning Tree, DTP, etc. Le VLAN native est également une option intéressante dans des cas spécifiques. Par défaut le VLAN native est le 1. Il arrive cependant qu’il soit nécessaire de modifier son ID.

Prenons un réseau segmenté de façon logique en deux VLANs : un pour le trafic normal (VLAN002) des machines et un autre hors bande pour les contrôleurs IPMI (VLAN003). Les ports du commutateur doivent donc être configurés en mode 802.1Q ; ils attendent donc des paquets tagués. Supposons que les systèmes soient déployés via PXE. Les cartes réseau effectuant le démarrage en PXE sont pour la plupart incapables de taguer les trames. Grâce aux natives VLAN, il est possible de créer un VLAN de déploiement (VID 4) contenant les trames non taguées des systèmes en cours d’installation PXE. Voici la configuration des ports sur JunOS :

3.2 VLAN d’interconnexion BGP

C’est un VLAN créé entre plusieurs équipements réseaux (c’est-à-dire que chacun des équipements réseau possède une interface dans ce VLAN). Prenons le cas du protocole de routage BGP, ce protocole fonctionne en définissant une chaîne de next hop  appelés neighbors. Chacun de ces neighbors correspond en réalité à une interface d’un équipement de routage connecté au VLAN d’interconnexion. Un VLAN d’interconnexion n’est pas destiné à faire transiter du trafic réseau usuel (stream, web, mail, etc.) mais se présente plutôt comme un réseau hors bande. Dans ce cas l’utilisation des VLANs nous évite de déployer un réseau d’administration physique avec les problèmes de coût et de SPOF (Single Point Of Failure) inhérents.

Conclusion

Bien qu’assez anciens, les VLANs sont encore activement utilisés à la fois dans les environnements de production et expérimentaux. Ils permettent de segmenter des réseaux à moindres frais. Combinés aux capacités de châssis virtuels des équipements réseau, ils contribuent à calquer la topologie réseau de données sur la topologie organisationnelle de l’entité indépendamment de la répartition géographique des postes de travail. Les VLANs sont également utilisés comme briques par plusieurs services. Le plus connu, le 802.1X, concerne la sécurité réseau. Ce protocole permet d’authentifier les machines sur le réseau. Cependant, une solution 802.1X propose des services supplémentaires comme la vérification d’états des machines se raccordant au réseau (statut des mises à jour, dernière analyse antivirale, etc.). Si tous les paramètres (authentification et état) sont au vert alors la machine peut accéder au réseau, sinon elle est raccordée à un VLAN de remédiation où se trouvent uniquement les serveurs de mise à jour et antiviraux chargés de mettre la machine dans l’état attendu.