Contents
Aperçu
Cette formation vous présentera ce que le concept de Virtual Local Area Network (VLAN) représente, à quoi ça peut servir en complément du routage simple, comment ça fonctionne et comment on peut configurer les machines linux et les switches HP qui en ont besoin.
Formations préalables
Temps estimé
60 minutes
Objectifs
- Comprendre pourquoi un VLAN peut être utile. e.g. Sous-réseaux vs. lien physique vs. VLAN
- Chaque VLAN doit avoir un sous-réseau différent
Comme on l'a vu dans la formation routage, le routeur est le point où on peut passer d'un sous-réseau à un autre (on se fait router -- au Niveau 3 (Network Layer) du modèle OSI -- d'un sous-réseau à un autre)
- Le routeur doit avoir accès aux différents VLANs pour pouvoir transporter les paquets d'un à l'autre. On peut par exemple pour ça rendre tous les VLANs accessibles sur le même fil réseau vers le routeur.
- Identifier ce que c'est qu'un VLAN
Implémenté au Niveau 2 (Data Link) du modèle OSI (référez-vous à la formation routage pour revoir le modèle)
Protocole 802.1Q pour tagger les packets
tagged vs. untagged
- Configurer des machines pour interagir avec un certain VLAN
- Linux
- HP Procurve
Préparation des participant.e.s
Personne guide pour la formation
La personne qui donne la formation doit préparer qqch avant qu'on puisse commencer: on utilisera les switches "laboratoire" qui sont au sous-sol du bureau et quelques machines physiques.
Réinitialiser la configuration des switches aux factory defaults
- Trouver quatre machines à brancher dans deux des switches
- Si on en a de disponible, ça peut être des raspberry pi, ou bien des desktops
Donner les IPs 10.33.0.2/24 et 10.33.0.3/24 aux deux machines qui seront dans le même VLAN
Donner l'IP 10.44.0.2/24 à la machine seule dans son VLAN
S'assurer que tout.e.s les participant.e.s peuvent ssh vers le serveur de console série du bureau et a bien accès sudo sur cette machine
Participant.e.s
Rien! Soyez simplement pret.e.s à utiliser la ligne de commande et à plonger dans un OS différent! (celui des switches)
Théorie, concepts et information
La formation sur les VLANs comporte une courte section d'informations puisque le concept lui-même n'est pas très compliqué. La section des exercices occupera une majorité du temps de la session.
TL;DR:
Les VLANs sont interprétés au niveau 2 du modèle OSI, donc dans un réseau local. Les VLANs fonctionnent dans les réseau ethernet
- Un VLAN est numéroté. Son numéro peut aller de 0 à 4095
- On utilise généralement les VLANs pour créer des séparations dans un réseau malgré qu'il soit tout interconnecté physiquement
- Une machine peut recevoir le trafic de plusieurs segments du réseau en étant configurée pour parler à plusieurs VLANs
- Les switches qui relient les machines sont configurées pour diffuser ou non les paquets qui concernent certains VLANs sur certains de leurs ports
Les paquets peuvent être tagged ou untagged
Les paquets tagged sont utiles pour faire du trunking, donc pour rendre un VLAN disponible d'une switch à l'autre, et aussi pour faire converger les VLANs sur le fil réseau du routeur.
Les VLANs untagged sont en fait les VLAN natifs. Aucune information n'est ajoutée sur les paquets et le numéro du VLAN correspondant est interprété implicitement par la switch selon quel VLAN est marqué comme untagged sur le port correspondant. Une machine n'a donc pas besoin de configuration pour parler à son VLAN natif.
- On peut par exemple:
- Utiliser les VLANs en combinaison avec des règles de routage ou de firewall sur le routeur pour restreindre quel trafic peut se rendre d'un VLAN à un autre
- Créer un réseau privé rejoignable seulement par certaines machines
A quoi ça sert un VLAN
Normalement dans un "réseau local", donc dans un réseau dans lequel on n'a normalement pas besoin de routeur pour communiquer avec d'autres machines, on y retrouve généralement un seul sous-réseau.
On peut en fait avoir plusieurs sous-réseaux sur un même réseau local physique, mais à ce moment là il y a quelques adresses IP qui ne peuvent pas parler à d'autres malgré qu'elles soient sur le même réseau local. Il faudra alors passer par un routeur pour transférer d'un sous-réseau à un autre.
Par contre, cette séparation là n'est pas très forte: on peut facilement rejoindre les autres machines en ajoutant une adresse IP dans les autres sous-réseaux.
Les VLANs permettent d'avoir une séparation plus claire en ajoutant une division dans le réseau au niveau 2. En principe, le trafic de niveau 2 (les MAC addresses) d'un VLAN ne peut pas atteindre un autre VLAN, peu importe sa configuration niveau 3 (adresse IP), sans une aide externe. On force donc le trafic qui échange de VLAN à passer par un routeur et/ou un firewall malgré que les câbles réseau se retrouvent branchés dans le même réseau local physique.
Dans l'exemple au dessus, malgré qu'elles sont connectées sur la même switch, donc dans un même "niveau 2", les machines A et B peuvent se parler entre elles, C et D également, mais A ne peut pas parler directement à C ou D puisqu'elle se trouve dans un VLAN différent. A devra alors passer par le routeur via le port trunk pour transiter vers les machines du VLAN bleu. Le routeur pourra à ce moment là appliquer certaines règles de routage ou de firewall pour permettre ou bloquer le transit.
VLAN natif ou untagged vs tagged
Les VLANs sont distingués en étant assignés à un numéro unique dans un réseau local, un VLAN ID. Ces numéros sont encodés sur 12 bits et peuvent donc aller de 1 à 4096.
Il y a deux méthodes sur les switches pour configurer comment un port communique avec un certain VLAN
On peut permettre la communication sans ajouter de tag aux paquets. On appelle cette configuration untagged, et on dénote généralement un port configuré pour une communication untagged à un VLAN comme un port d'accès.
On appelle VLAN natif lorsqu'on peut communiquer avec le réseau d'un VLAN sans encapsuler les paquets dans l'information de VLAN
Donc un port configuré pour communiquer avec un VLAN de manière untagged, c'est en fait son port natif
Le VLAN natif par défaut (quand on n'a pas configuré explicitement un VLAN untagged) est le VLAN numéro 1
- On a donc en fait toujours un VLAN natif sur une interface
Lorsqu'un paquet destiné à un certain VLAN est diffusé vers un port untagged pour ce VLAN-ci, le tag de VLAN sera retiré avant que le paquet soit diffusé sur le port. Le paquet utilise alors le VLAN natif du port.
A l'inverse, lorsqu'un paquet arrive sans tag d'un port untagged, un tag sera ajouté au paquet pour indiquer que celui-ci correspond au VLAN désigné comme celui untagged sur le port d'où la switch a reçu les données. C'est comme ça que la destination saura identifier à quel VLAN ce paquet réseau appartient.
- Il est fortement recommandé de ne pas utiliser le VLAN numéro 1 comme VLAN natif sur les ports d'accès. Comme le numéro 1 est utilisé par défaut lorsqu'une configuration n'a pas été faite, il est très facile si on utilise le VLAN 1 d'obtenir des ports qui peuvent communiquer ensemble alors que ça n'était pas l'intention. Donc pour éviter cette situation, on utilise un numéro configuré explicitement à une valeur différente de 1.
A cause de comment ça fonctionne, si on branche deux switches ensemble et qu'un côté utilise un VLAN untagged mais que l'autre utilise un autre VLAN untagged, on se retrouve à briser le mur entre ces deux VLANs et leur permettre de communiquer directement! En effet la première switch va décapsuler le trafic pour le VLAN natif et lors de la réception la 2ème switch ajoutera un nouveau tag pour un VLAN différent. Il est donc important de faire attention de toujours configurer le même identifiant de VLAN des deux côtés d'un même fil.
On peut envoyer le trafic de plusieurs VLANs sur un même câble réseau an apposant un tag sur les paquets pour noter dans quel VLAN chaque paquet transite. On appelle cette configuration tagged, et on dénote généralement un port configuré pour une communication tagged à plusieurs VLANs comme un port de trunking.
Il est à noter qu'un port de trunking aura également un VLAN natif, donc untagged de configuré.
Il est fortement recommandé de ne pas utiliser le VLAN numéro 1 comme VLAN natif sur les ports de trunking pour les mêmes raisons que pour les ports untagged plus haut.
Format d'un tag 802.1Q
Un tag de VLAN 802.1Q est inséré au niveau 2 du modèle OSI et encapsule le restant du paquet. En pratique, ça veut dire qu'on ajoute un morceau d'information avant les donnés comme démontré dans l'image suivante:
- TPID
Tag protocol identifier. Sur 16 bits. C'est une valeur statique de 0x8100 pour identifier qu'on a un tag 802.1Q
- PCP
- Priority code point. Sur 3 bits. C'est un niveau de priorité pour du Qualilty of Service (QoS) au niveau 2
- DEI
- Drop eligible indicator. Sur 1 bit. Détermine si les paquets de ce vlan peuvent être abandonnés en cas de congestion
- VID
- VLAN identifier. Su 12 bits. C'est le numéro d'identification du VLAN
Cas d'usages de VLANs
Réseau privé:
Deux machines sont sur un VLAN privé, c'est à dire qui ne se rend pas au routeur pour permettre l'échange avec d'autres VLANs et qui n'englobe pas toutes les machines présentes. Les deux machines sur le VLAN privé peuvent communiquer entre elles de manière confidentielle.
DMZ + trunking vers routeur/firewall
Une machine se trouve dans un VLAN identifié comme une DMZ. Les machines sur le VLAN public peuvent communiquer via HTTPS vers la DMZ mais pas par d'autres moyens. La machine dans la DMZ ne peut pas contacter internet et ne peut pas initier une connexion vers le VLAN public. C'est le firewall qui établit ces règles de trafic et le firewall est forcé d'être utilisé vu la différence de VLANs.
Exercices
Configurer les VLANs sur une switch
Créer un VLAN
- céer le même nouveau VLAN sur les deux switches
- besoin de reboot pour qu'un nouveau VLAN soit visible. ça coupe donc malheureusement le trafic pendant le reboot
Assigner un VLAN à certains ports
assigner un même VLAN untagged au port connecté à deux des machines démo pour qu'elles puissent se rejoindre
assigenr un VLAN untagged différent à la troisième machine de démo
- configurer le trunking
assigner un VLAN untagged différent des deux autres au port de trunking entre les deux switches. s'assurer de configurer le même VLAN untagged des deux côtés du lien (donc sur les deux switches)
assigner les deux VLANs de machines démo comme tagged sur le port de trunking. s'assurer de configurer la même chose des deux côtés du lien
- tester que les deux machines demo sur le même VLAN peuvent se rejoindre avec ping
- tester que la machine démo qui est sur un VLAN différent ne peut pas rejoindre les deux autres
Références:
https://wiki.koumbit.net/HP/Procurve2520#Upstream_documentation -- voir "Basic Operation Guide" page 104
- plusieurs autres sections contiennent de l'information sur des opérations possibles sur les switches
Configurer des VLANs sur debian
Faire transiter les paquets d'un VLAN à l'autre via le routeur
- Ajouter les VLANs sur l'interface du routeur
Configurer les VLANs manuellement avec ip link
Retirer la configuration manuelle, puis ajouter la configuration de VLAN dans /etc/network/interfaces pour la rendre permanente
- Configurer une IP "gateway" sur chaque interface VLAN
- Note: des routes pour les sous-réseaux des VLANs seront ajoutées automatiquement
- Tester avec ping qu'on peut bien rejoindre les machines demo dans les deux VLANs
Configurer le routeur pour permettre le forwarding IPv4
- Tester que maintenant les machines demo des deux VLANs peuvent se rejoindre avec ping
Références:
https://wiki.debian.org/NetworkConfiguration#A.2Fetc.2Fnetwork.2Finterfaces -- attention: lisez la note sous l'exemple (pourquoi c'est pas devenu ça l'exemple par défaut? ... la documentation de debian est souvent pas à jour grr)
https://linuxconfig.org/how-to-turn-on-off-ip-forwarding-in-linux
Rétrospective
Pendant un maximum de 15 minutes, les participant.e.s sont invité.e.s à partager les éléments qui ont bien ou moins bien fonctionnés et les idées qui pourraient survenir pour des manières d'améliorer le processus.
Quelques éléments qui peuvent faire partie de la rétrospective, dépendant de la grosseur du projet ou de la formation:
- Sommaire collectif (e.g. résumé rapide en termes que tout le collectif peut comprendre)
Pas trop utile pour les projets vraiment simples ou les formations.
- Chronologie des événements marquant pour le projet
Surtout utile pour les projet qui se sont étalés sur plusieurs jours ou plus ou bien quand beaucoup de choses se sont produites simultanément, ce qui a rendu la compréhension des influences de chaque événement complexe.
- Les bons coups -- qu'est-ce qui a bien fonctionné et qu'on veut tenter de reproduire
- Les problèmes
- échecs -- avec l'aide de la chronologie (si elle a été faite), tenter de situer les échecs dans un contexte selon ce qui était connu des participant.e.s aux moments qui ont mené à l'échec
- problèmes techniques
- manques de ressources
- perturbations externes
- Une liste d'actions à court et/ou à plus long terme pour améliorer les choses telles que soulignées pendant les points précédents
- Transférer les actions dans redmine pour qu'elles puissent être suivies!
N'hésitez pas à partager les échecs à l'extérieur de l'équipe puisqu'on peut apprendre beaucoup de ceux-ci, mais surtout évitez de les formuler comme un blâme sur la/les personne(s) ayant échoué.
Une rétrospective est surtout utile quand on la partage: ça permet aux autres d'apprendre de nos erreurs et aussi de nos idées d'améliorations. On peut par exemple envoyer une forme écrite par email, ou bien sauvegardée comme page wiki.
Information complémentaire
Les VLANs de Koumbit au centre de données: NetworkMappingService#Niveau_2_.28subnets.29
- Plus d'infromation sur les VLANs:
Faiblesses de sécurité des VLANs et contremesures pour protéger contre certaines attaques: https://www.sans.org/reading-room/whitepapers/networkdevs/virtual-lan-security-weaknesses-countermeasures-1090
802.1ad, ou QinQ, permet d'imbriquer des VLANs dans un VLAN de "transport" (ou trunking): https://en.wikipedia.org/wiki/IEEE_802.1ad
- Netelligent ont utilisé ce protocole avant et pendant le grand démanagement de toutes les machines de Koumbit d'un centre de données à un autre pour permettre à Koumbit d'avoir nos mêmes VLANs (ceux publics seulement) de disponibles dans les deux centres de données en même temps.