VLAN de clients ou trunk étiqueté : choisir le bon mode OpenVPN

Deux demandes arrivent avec une formulation presque identique : placer chaque client VPN dans un VLAN choisi, ou faire passer un trunk VLAN existant à travers le VPN. Ce sont deux produits différents. Le mode intégré d'OpenVPN conscient des VLAN est un modèle de commutateur pour la première demande, et il n'est pas synonyme de transport transparent d'étiquettes. Choisir le mauvais produit une conception qui semble configurée et abandonne silencieusement les trames qui vous importaient.

Ce que construit réellement le mode conscient des VLAN

Avec vlan-tagging activé sur un déploiement TAP réservé au serveur, le démon modélise son périphérique TAP et chaque client connecté comme des ports d'un commutateur interne. Les ports clients ne sont pas étiquetés, et leur association VLAN est définie sur le serveur via le contexte vlan-pvid par client, et non par ce que le client envoie. C'est tout l'intérêt du modèle : l'appartenance est une décision côté serveur sur un pair authentifié. Rien dans le profil du client n'a besoin de savoir à quel VLAN il appartient.

Le côté TAP du serveur reçoit sa propre politique d'acceptation étiquetée ou non étiquetée via vlan-accept. Le transfert à l'intérieur de ce commutateur n'a lieu qu'entre VID identiques, y compris lorsque client-to-client est défini, si bien que deux clients de VLAN différents ne peuvent pas s'atteindre via le serveur alors que tous deux y sont connectés.

Ce modèle est un modèle de port d'accès. Les trames qui quittent un client ne sont pas étiquetées, et l'association est imposée par le serveur d'après l'identité. Demander au portable d'étiqueter lui-même son trafic revient à demander une autre conception.

Les attributions doivent suivre l'identité authentifiée du client, et non une valeur que le client propose de lui-même. Une attribution omise n'est pas non plus un état de quarantaine : le client atterrit sur le PVID par défaut, donc une entrée ccd manquante est une décision de politique silencieuse plutôt que neutre.

Ce qu'exige à la place un trunk transparent

Transporter des trames déjà étiquetées de bout en bout commence par désactiver le traitement conscient des VLAN. Le modèle de commutateur et la préservation des étiquettes sont des alternatives, et activer les deux demande à une fonction de faire le travail de l'autre.

La désactivation n'est que le début. Le pont à chaque extrémité et les ports physiques du commutateur doivent s'accorder sur les VLAN autorisés, l'étiquette native et le traitement des trames non étiquetées. Étendre un trunk sans restriction expose bien plus de domaines de diffusion que les deux que vous vouliez relier.

La taille des trames mérite son propre budget. Une trame Ethernet étiquetée plus l'encapsulation est plus grande que le chiffre de charge utile que les gens copient d'un guide, et une MTU qui convenait à un tunnel routé ne prouve pas qu'un chemin de trunk fonctionne.

Trois conditions qui décident de la réponse

Premièrement, la plateforme cliente prend-elle en charge TAP ? Android et iOS non, et la prise en charge de macOS est limitée, donc un parc d'utilisateurs mobiles exclut l'une ou l'autre conception TAP, quelle que soit l'organisation des VLAN. Une session TUN routée transporte des paquets IP, pas des trames Ethernet, et aucune configuration VLAN côté serveur n'y change rien. Vérifiez le parc avant de concevoir la topologie, car cette condition est celle qu'on ne peut pas contourner. C'est aussi celle que l'on découvre le plus souvent une fois les travaux de commutation terminés.

Deuxièmement, qui attribue le VLAN ? Si la réponse est « le serveur, selon qui s'est authentifié », le modèle de commutateur convient. Si la réponse est « l'infrastructure de commutateurs existante, avec des étiquettes qui existent déjà », il vous faut la conception trunk.

Troisièmement, quelle part du réseau doit être joignable ? Le modèle de commutateur maintient chaque client dans un seul VLAN par construction. La conception trunk est un pont, et un pont mal configuré réunit des domaines de diffusion censés rester séparés.

Tester le choix retenu

Connectez un client qui doit être dans le VLAN autorisé et un qui ne doit pas l'être, puis testez depuis l'extrémité réelle plutôt que depuis le serveur lui-même. La joignabilité côté serveur prouve que le pont ou le commutateur existe ; elle ne prouve pas dans quel VLAN un client a atterri.

ip -d link show tap0
bridge vlan show

Sur le serveur, la seconde commande affiche l'appartenance VLAN de chaque port du pont, y compris si un port est étiqueté ou non. Comparez-la à l'attribution prévue avant de déboguer quoi que ce soit au-dessus de la couche deux.

Notez laquelle des deux conceptions le déploiement utilise. Une note disant « conscient des VLAN » est ambiguë, et l'ingénieur suivant supposera celle qu'il a apprise en premier. La référence VLAN d'OpenVPNdéfinit le comportement du commutateur et le contexte par client, et c'est le chemin le plus court pour confirmer quel modèle vous exécutez.