« Vlan - linux » : différence entre les versions
(Page créée avec « Category:réseaux linux {{chantier}} Dans cette documentation, nous allons traiter de la configuration du protocole 802.1Q avec un noyau Linux. Cette fonctionnalité... ») |
(Plus en chantier + correction de fautes de français.) |
||
| Ligne 1 : | Ligne 1 : | ||
[[Category:réseaux linux]] | [[Category:réseaux linux]] | ||
Dans cette documentation, nous allons traiter de la configuration du protocole 802.1Q avec un noyau Linux. Cette fonctionnalité est gérée nativement par le noyau, les commandes sont donc transposables sous toute les distributions comportant le paquet ''iproute2''. | Dans cette documentation, nous allons traiter de la configuration du protocole 802.1Q avec un noyau Linux. Cette fonctionnalité est gérée nativement par le noyau, les commandes sont donc transposables sous toute les distributions comportant le paquet ''iproute2''. | ||
| Ligne 8 : | Ligne 6 : | ||
J'en profite également pour dire aux | J'en profite également pour dire aux habitués des produits Cisco que dans le cas présent comme chez de nombreux constructeurs, la terminologie autour du 802.1Q est quelque peu différente (allez savoir pourquoi...). En effet nous avons: | ||
* trunk{{=}}tagged | * trunk{{=}}tagged | ||
* access{{=}}untagged}} | * access{{=}}untagged}} | ||
Traditionnellement, la méthode de configuration des VLAN sous Linux était quelque peu merdique (on ne va pas se mentir). Il fallait utiliser un pont par VLAN, une interface VLAN était rattaché à une interface physique (eth0.120 par exemple pour le VLAN 120) et la configuration d'un lien trunk relevait plus de la farce que d'une réelle fonctionnalité (c'était l'interface physique auquel était rattaché plusieurs VLAN qui était trunk. Dans ces conditions, il faudra m'expliquer | Traditionnellement, la méthode de configuration des VLAN sous Linux était quelque peu merdique (on ne va pas se mentir). Il fallait utiliser un pont par VLAN, une interface VLAN était rattaché à une interface physique (eth0.120 par exemple pour le VLAN 120) et la configuration d'un lien trunk relevait plus de la farce que d'une réelle fonctionnalité (c'était l'interface physique auquel était rattaché plusieurs VLAN qui était trunk. Dans ces conditions, il faudra m'expliquer comment on donne un trunk à une machine virtuelle destinée à faire pare feux par exemple...). Bref, c'était tout pourris et c'est encore la façon de faire documentée sur 99% des sites sur Internet ! Les gens ne savent tout simplement pas qu'il existe une fonctionnalité nommée ''VLAN filtering'' sur un pont Linux et qu'il est ainsi possible de calquer exactement le fonctionnement d'[[Open vSwitch]] sur un pont natif (les [[Strongswan#Sur_les_clients|bogues de ce dernier]] en moins). | ||
=Usage= | =Usage= | ||
Version du 21 octobre 2019 à 15:52
Dans cette documentation, nous allons traiter de la configuration du protocole 802.1Q avec un noyau Linux. Cette fonctionnalité est gérée nativement par le noyau, les commandes sont donc transposables sous toute les distributions comportant le paquet iproute2.
INFORMATION
Dans cette documentation, je part du principe qu'une machine Linux est branchée via son interface eth0 à un commutateur configuré en trunk avec deux VLAN (le 10 et le 20). Je part également du principe qu'une deuxième machine quelconque est branchée sur l'interface eth1 du Linux afin de tester le mode access/untagged de la solution.
J'en profite également pour dire aux habitués des produits Cisco que dans le cas présent comme chez de nombreux constructeurs, la terminologie autour du 802.1Q est quelque peu différente (allez savoir pourquoi...). En effet nous avons:
- trunk=tagged
- access=untagged
Traditionnellement, la méthode de configuration des VLAN sous Linux était quelque peu merdique (on ne va pas se mentir). Il fallait utiliser un pont par VLAN, une interface VLAN était rattaché à une interface physique (eth0.120 par exemple pour le VLAN 120) et la configuration d'un lien trunk relevait plus de la farce que d'une réelle fonctionnalité (c'était l'interface physique auquel était rattaché plusieurs VLAN qui était trunk. Dans ces conditions, il faudra m'expliquer comment on donne un trunk à une machine virtuelle destinée à faire pare feux par exemple...). Bref, c'était tout pourris et c'est encore la façon de faire documentée sur 99% des sites sur Internet ! Les gens ne savent tout simplement pas qu'il existe une fonctionnalité nommée VLAN filtering sur un pont Linux et qu'il est ainsi possible de calquer exactement le fonctionnement d'Open vSwitch sur un pont natif (les bogues de ce dernier en moins).
Usage
Création du pont
Création d'un pont Linux avec gestion des VLAN
ip link add br0 type bridge vlan_filtering 1
Allumage de l'interface du pont
ip link set br0 up
Provisionnement du pont
Allumage de l'interface physique liée au pont
ip link set eth0 up ip link set eth1 up
Ajout des interfaces physiques au pont
ip link set eth0 master br0 ip link set eth1 master br0
Pour sortir une interface physique du pont, on utilisera la commande suivante:
ip link set eth0 nomaster
Isolation du pont
Un pont Linux, bien qu'étant un objet de niveau 2 OSI, peut accepter et traiter du trafic IP (contrairement aux interfaces qui le compose qui elles, respectent strictement le modèle OSI). Cette propriété offre des avantages mais peut également occasionner des failles.
Conformément à ce qu'explique l'excellent Vincent Bernat dans sa page dédié, il existe différente façons de cloisonner notre pont, la plus efficace étant de filtrer le trafic du VLAN par défaut, de sorte à ce que la trame soit rejetée directement dans la fonction br_pass_frame_up() du noyau. Pour ce faire, nous utiliserons la commande suivante:
bridge vlan del dev br0 vid 1 self
J'en profite également pour supprimer ce VLAN sur les interfaces composant ce pont afin de ne pas polluer le visuel lors d'un listage de celui-ci:
bridge vlan del dev eth0 vid 1 master bridge vlan del dev eth1 vid 1 master
Configuration du 802.1Q
À ce stade, notre pont est configuré avec 2 interfaces réseaux (eth0 et eth1) et leur VLAN par défaut a été supprimé. Actuellement, aucun VLAN n'est configuré et un bridge vlan show nous montre une liste sous forme de tableau de nos interface avec la mention none dans la colonne vlan ids. Il est temps de passer à la configuration du pont à proprement parler.
Interface trunk
Nous allons étiqueter les trames passant par eth0. Il faut également produire cette opération pour le pont lui-même afin d'autoriser les trames à passer.
bridge vlan add dev br0 vid 10 tagged self bridge vlan add dev br0 vid 20 tagged self
Le paramètre désignant l'étiquetage est tagged. On autorise donc le VLAN 10 et 20 à transiter par notre lien trunk via eth0 appartenant à br0. Vous noterez qu'une opération sur "br0" se fait via le paramètre self alors que sur l'une des interfaces esclaves, c'est master qui est utilisé.
Un bridge vlan show nous montre désormais les ID des VLAN que nous venons de configurer dans la colonne correspondante.
De la même manière que n'importe quelle commande avec iproute2, un del permet de supprimer une donnée précédemment configurée via un add. Ainsi, pour supprimer un VLAN du trunk, il suffit de faire:
bridge vlan del dev br0 vid 20 tagged self
Interface access
Pour attribuer un VLAN à une interface sans étiquetage, on utilisera la méthode suivante:
bridge vlan add dev eth1 vid 10 pvid untagged master
L'interface eth1 est donc dans le VLAN 10, tout client se branchant dessus y sera sans avoir à gérer le 802.1Q (équivalent du switchport acces vlan 10 sous Cisco).
Interface VLAN
Pour créer une interface de VLAN, il suffit de faire ceci:
ip link add link br0 name vlan10 type vlan id 10 ip link set vlan10 up ip address add 192.168.10.254/24 dev vlan10
Fichier interfaces
Il est possible de configurer le filtrage de VLAN via le traditionnel fichier /etc/network/interfaces mais comme à son habitude, il existe zéro documentation sur le sujet donc c'est grave la mort d'arriver à quelque chose de fonctionnel. De plus, nous avons constaté qu'un résultat fonctionnel sur une machine ne donnera pas forcement le même sur une autre... Bref c'est de la merde.
Je détaillerai peu être un plus cette partie ici prochainement...
