Deux sites ont-ils besoin des mêmes VLAN ID pour un VPN de site ?

Des numéros VLAN identiques dans deux bureaux semblent devoir aider un tunnel entre sites, et ils ne changent rien à ce que le tunnel transporte. Un VLAN ID étiquette un domaine de diffusion Ethernet à l’intérieur d’un bâtiment ; le tunnel achemine les paquets IP entre les passerelles. Deux sites peuvent utiliser une numérotation VLAN totalement différente et pourtant se router l’un vers l’autre, et deux sites peuvent utiliser une numérotation VLAN identique et pourtant ne pas s’atteindre. La variable qui décide de l’accessibilité est le plan d’adressage.

Le mythe : des VLAN ID identiques aux deux extrémités

La croyance vient d’un endroit raisonnable. Dans un bâtiment, deux ports du même VLAN peuvent se parler et deux ports de VLAN différents ne le peuvent pas, donc le numéro VLAN ressemble à ce qui accorde la connectivité. À travers un tunnel routé, il n’y a aucun segment Ethernet partagé que l’étiquette puisse décrire, et les passerelles n’échangent jamais d’étiquettes VLAN.

Ce dont le tunnel a besoin, c’est d’une paire d’espaces d’adresses qui ne se chevauchent pas et d’une politique qui autorise le trafic entre eux. Changez le VLAN dans n’importe quel bureau et le tunnel continue de fonctionner, car rien dans la configuration du tunnel ne le référençait. C’est le test qui tranche le débat : renumérotez un VLAN, laissez les adresses intactes et observez si le tunnel reste actif.

Le test inverse est tout aussi instructif. Donnez aux deux bureaux le même sous-réseau et aucune quantité de numéros VLAN identiques ne rendra une adresse non ambiguë.

Ce que le tunnel transporte réellement

IPsec protège les paquets IP selon une politique exprimée en adresses, protocoles et ports. L’architecture IPsec décrit ces sélecteurs au niveau IP, qui se situe plusieurs couches au-dessus de tout ce que décrit une étiquette de commutateur. Quand un paquet entre dans le tunnel, il a déjà quitté le VLAN ; l’étiquette a été consommée par le commutateur local.

Les conceptions basées sur la politique et sur les routes diffèrent dans la façon dont elles choisissent le tunnel, pas dans ce qu’elles peuvent transporter. Un pair basé sur la politique met en correspondance les sélecteurs de trafic et envoie les paquets correspondants dans le tunnel. Un pair basé sur les routes route le trafic sur une interface de tunnel et laisse la table de routage décider. Les deux négocient encore une portée de protection, donc une route qui pointe vers le tunnel n’élargit pas ce que les pairs ont accepté de protéger.

Cette distinction explique un demi-échec courant : la route existe, les paquets entrent dans le tunnel et le côté distant les rejette parce que les sélecteurs négociés n’ont jamais inclus ce préfixe. La lecture des politiques installées montre quelle portée a réellement pris effet.

ip xfrm policy
ip route show
swanctl --list-sas

Le chevauchement qui casse vraiment

Deux bureaux avec des sous-réseaux distincts se routent proprement à travers un tunnel, et leurs numéros VLAN sont sans importance. Deux bureaux avec le même sous-réseau non, car une demande pour une adresse donnée a deux significations possibles et la table de routage ne peut en choisir qu’une. Renuméroter un site est la solution propre, et elle est généralement moins chère que les alternatives une fois comptés les changements DNS et pare-feu.

Quand la renumérotation est impossible, une conception de traduction délibérée peut présenter des vues d’adresses distinctes à chaque côté. Cela signifie un mappage un à un, des sélecteurs correspondants, des entrées DNS qui reflètent la vue traduite et un routage de retour qui survit à la réécriture. C’est une conception prise en charge avec un coût opérationnel réel, et ce n’est pas ce que fait le changement d’un VLAN ID.

Des numéros VLAN identiques aux deux extrémités sont parfois une coïncidence de modèle partagé, et traiter cette coïncidence comme la cause d’un tunnel fonctionnel mène au mauvais changement quand quelque chose casse plus tard.

Un travail par couche, consigné

Le commutateur local décide quels ports partagent un domaine de diffusion, et sa numérotation VLAN est une comptabilité locale que nul autre site n’a besoin de connaître. La passerelle authentifie le pair et applique la portée de protection négociée. La table de routage décide où va ensuite un paquet déchiffré, et la politique d’accès décide si ce paquet aurait dû être autorisé.

Garder ces travaux séparés est ce qui rend les changements sûrs. Une renumérotation VLAN dans un bureau touche le commutateur local, l’étendue DHCP et peut-être une zone de pare-feu, et elle ne touche pas le tunnel. Un changement de préfixe touche les sélecteurs du tunnel, les routes des deux côtés et la politique d’accès, et il ne touche pas les étiquettes du commutateur.

Les routes de retour, le DNS privé et les exigences d’identité d’application sont encore des travaux séparés, et aucun d’eux n’arrive en copiant un numéro VLAN de l’autre site. Un document de conception qui liste les préfixes joignables et les services autorisés survit à un renouvellement de commutateur ; celui qui liste des numéros VLAN, non.

Confirmez l’image locale avec les outils de bridge avant de supposer qu’une étiquette atteint le tunnel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Quand l’extension de layer-2 est la vraie exigence

Certaines conceptions ont réellement besoin d’un comportement Ethernet entre sites : une application héritée qui dépend de la découverte par diffusion, une migration qui doit conserver une adresse pendant qu’une machine se déplace, ou un protocole qui intègre des hypothèses de layer-2. Ces cas appellent un overlay ou un service ponté qui transporte les trames, et alors l’appartenance au VLAN, la prévention des boucles et la gestion des pannes deviennent des questions de bout en bout.

C’est un domaine de panne bien plus vaste, et cela devrait être un choix délibéré plutôt que le résultat accidentel d’une tentative de faire fonctionner un partage de fichiers. Un serveur de fichiers, une base de données ou une application web ordinaires ont besoin d’un chemin IP autorisé, et ils seront plus heureux sans un domaine de diffusion étiré en dessous.

Écrivez le contrat VPN comme des préfixes joignables plus des services autorisés, et consignez l’étiquette VLAN seulement là où les opérations locales en ont besoin. Chaque bureau peut alors renuméroter sa propre commutation sans transformer chaque changement en refonte du tunnel.