Pont TAP pour un seul VLAN : attachez la sous-interface

Un client TAP qui atteignait le LAN avant les VLAN et s'est arrêté ensuite possède en général un pont qui contient encore la mauvaise interface. Le transfert de trames n'ajoute pas d'étiquette VLAN, donc une trame client non étiquetée envoyée vers l'uplink physique arrive non étiquetée sur un port trunk et est soit rejetée, soit atterrit dans le VLAN natif. Que la sous-interface existe quelque part sur l'hôte ne change rien à la liste des membres du pont. C'est le mythe à tuer en premier : l'étiquette est appliquée par l'interface qui la possède, pas par l'hôte simplement parce qu'il en a une.

Une extension d'un seul VLAN signifie un seul domaine layer-2, et le pont doit rejoindre ce domaine plutôt que le trunk qui les porte tous.

L'étiquette n'apparaît pas parce que vous avez ponté le trunk

Prenez un uplink Linux eno1 qui porte le VLAN 120 vers un commutateur administré. La conception qui fonctionne pour un seul VLAN est tap_vpn ponté vers br_vpn, avec br_vpn contenant eno1.120 plutôt que eno1. La sous-interface VLAN applique l'étiquette en sortie et la retire en entrée, donc le pont ne voit que des trames non étiquetées pour ce seul VLAN. Mettez plutôt l'interface physique dans le pont et les mêmes trames sortent non étiquetées sur un port trunk, ce qui n'est pas ce que vous aviez prévu.

Ponter le trunk avec le filtrage VLAN désactivé n'est pas un raccourci vers le même résultat. Cela donne au pont tous les VLAN de ce câble, y compris ceux que les clients ne devraient pas voir.

Deux conceptions légitimes, un seul propriétaire de l'étiquette

Un pont conscient des VLAN est l'autre disposition valable : le trunk entre dans un port du pont, et l'appartenance par port, le PVID et les réglages de sortie étiquetée décident quels VLAN passent. Là, le pont possède l'étiquetage, et ajouter une sous-interface VLAN en dessous installerait un second propriétaire pour une seule tâche. Les deux conceptions fonctionnent ; les fragments des deux non. Décidez quel objet applique l'étiquette avant de modifier la moindre liste de membres.

Le port du commutateur doit s'accorder avec la conception que vous choisissez. Un port d'accès qui porte le VLAN non étiqueté s'associe à l'interface physique comme attachement, tandis qu'un port trunk s'associe à une sous-interface étiquetée. Ajouter une sous-interface à un port d'accès inadéquat ne répare rien.

Déplacez l'adresse avec l'appartenance

Dans la conception avec sous-interface, l'adresse de l'hôte pour le sous-réseau ponté appartient à br_vpn, pas au port VLAN asservi où elle a pu vivre auparavant. La laisser sur le port peut sembler fonctionner puis se comporter étrangement, car le pont commute en layer 2 tandis que l'adresse repose sur un membre. Déplacez-la dans le cadre du changement d'appartenance plutôt que comme une expérience séparée.

Déplacer une adresse peut couper le chemin d'administration. Établissez une route de récupération indépendante, sauvegardez la configuration existante via le gestionnaire de réseau de la distribution, et évitez un script de démarrage concurrent qui se battra avec elle après la prochaine mise à niveau.

L'adressage des clients demande le même soin. Un VPN ponté place les clients dans le sous-réseau étendu, donc un pool ne doit pas chevaucher d'autres baux ni affectations statiques, et la disposition servie par DHCP doit être celle que le LAN attend réellement. Un chemin layer-2 qui fonctionne ne dit rien sur les adresses en double.

Vérifiez l'appartenance avant d'accuser les routes

Lisez l'état actuel plutôt que l'état voulu : ip -d link show dev eno1.120 affiche l'id de VLAN et son parent, ip link show master br_vpn liste les membres du pont, et bridge vlan show rapporte l'appartenance par port et le traitement en sortie. Dans la conception avec sous-interface, confirmez que le périphérique TAP et le périphérique VLAN sont les membres. Dans un pont conscient des VLAN, vérifiez la politique du port elle-même, car un pont existant ne prouve pas ce qu'il autorise.

Testez ensuite un client autorisé contre un service de ce VLAN, en vous rappelant que l'ARP, la politique du pare-feu et le chemin de retour sont des questions distinctes de l'appartenance. Si vous capturez des paquets, notez que le déchargement matériel peut changer l'endroit où les étiquettes VLAN apparaissent dans une trace. Gardez aussi le périmètre honnête : un client TUN routé ne devient pas membre d'un VLAN par un changement de pont, et le trafic client-à-client ne remplace pas l'attachement de l'hôte au VLAN.