VPN L2 ou tunnel L3 : cinq vérifications avant de créer un pont

Vous pontez un site parce qu'un outil exige d'être sur le même réseau, et trois semaines plus tard vous lisez des journaux de commutateur à deux heures du matin. Ce genre d'intuition décide bien trop de liaisons Ethernet sur IP. Une seule différence compte vraiment ici : si des trames entières voyagent de bout en bout, ou seulement des paquets IP. Déroulez les cinq vérifications ci-dessous dans l'ordre, et arrêtez-vous à la première qui échoue.

Vérifiez ce que l'application met réellement sur le fil

Avant qu'un nom de produit n'entre dans la discussion, capturez une minute du trafic qui doit traverser la liaison : tcpdump -i eth0 -nn -e 'not ip'. L'option -e imprime l'en-tête de la couche liaison, et c'est exactement la partie qu'un tunnel routé jette. Si la capture reste vide, votre application parle IP et un tunnel L3 la transporte sans changement. Si des trames apparaissent, notez l'EtherType, car 0x0806 est ARP, 0x88cc est LLDP, et une valeur constructeur signifie généralement un protocole de découverte sans repli IP. C'est le moment où une tun interface ordinaire ne suffit plus.

Répétez la capture côté distant également. Une trame qui n'existe qu'à l'intérieur du commutateur virtuel d'un seul hôte n'est pas une raison d'étendre un domaine de diffusion sur un WAN.

Vérifiez si la découverte doit traverser la liaison

Un tunnel routé n'a aucun segment partagé, donc rien d'adressé à un groupe n'atteint l'autre extrémité. ARP, les diffusions DHCP, mDNS sur 224.0.0.251, SSDP et les requêtes de nom NetBIOS supposent tous une liaison que plusieurs hôtes entendent en même temps.

Demandez desquels l'application dépend réellement, et si un proxy existe déjà pour eux. Le relais DHCP, la réflexion mDNS et les entrées ARP statiques suppriment chacun une dépendance, et chacun est un service de plus à exploiter et à surveiller. Quand il en reste deux ou trois, le pontage est la réponse honnête.

Vérifiez ce que l'en-tête supplémentaire vous coûte

Les trames doivent bien vivre quelque part, donc tout ce que vous envoyez reçoit une seconde pile d'en-têtes autour. Dans un recouvrement VXLAN, cela signifie un en-tête IP externe, un en-tête UDP et un en-tête VXLAN de 8 octets, ce qui pousse une charge utile pleine de 1,500 octets au-delà du MTU de chemin d'une liaison internet ordinaire de 1,500 octets. OpenVPN en mode tap ajoute sa propre surcharge dans la même direction. Sans un MTU plus bas côté interne, vous obtenez une liaison qui répond aux ping et cale au premier gros transfert.

La facture ne s'arrête pas aux octets d'en-tête. La diffusion et le multicast qu'un commutateur traite en matériel passent désormais par le WAN, et chaque site ponté hérite du même plan d'adressage, de la même étendue DHCP et du même comportement face aux adresses en double. Cela rend la liaison bien plus difficile à auditer qu'un pool routé avec un préfixe par site.

Faites le calcul avant de choisir. Un segment chargé répliqué vers trois sites peut déplacer plus de trafic de diffusion que les transferts de fichiers pour lesquels il a été construit.

Vérifiez quel type de VPN L2 on vous propose

Le terme lui-même est ambigu, et l'ambiguïté décide qui transporte votre trafic. Parfois il décrit la charge utile : des trames Ethernet dans IP, envoyées sur internet comme n'importe quel autre tunnel, comme le font VXLAN, ZeroTier et le mode tap d'OpenVPN. Parfois il décrit un service acheté : un circuit Ethernet opérateur ou un pseudocâble MPLS qui relie deux sites au sein d'un même réseau de fournisseur.

Les deux vous donnent un segment, donc l'application ne peut pas les distinguer, mais la différence opérationnelle est grande. Un recouvrement vous laisse la responsabilité du MTU, du chiffrement et du chemin sous-jacent. Un service opérateur prend tout cela en charge et le facture, et il ne routera pas du tout vos trames sur l'internet public. Lequel vous voulez dépend de si les deux sites partagent un opérateur ou seulement une entreprise.

Vérifiez la solution moins chère avant de créer un pont

La plupart des demandes de liaison pontée viennent d'une seule résolution cassée, pas d'un protocole qui a vraiment besoin de trames. Faites d'abord passer le résolveur et le domaine de recherche par le tunnel routé : dhcp-option DNS 10.8.0.1 avec dhcp-option DOMAIN internal.example dans une configuration de serveur OpenVPN en règle un nombre surprenant. Un redirecteur local côté distant fait le même travail sans déplacer aucun trafic de diffusion.

Si un outil ancien échoue encore, placez-le derrière un proxy ou un hôte de rebond sur le segment de destination. Un seul redirecteur TCP est moins coûteux à exploiter qu'un WAN ponté.

Clôturez la décision dans l'ordre : le trafic porte-t-il un EtherType non IP, la découverte doit-elle traverser, le MTU peut-il absorber les en-têtes supplémentaires, un circuit opérateur est-il réellement disponible, et la solution routée a-t-elle échoué pour une raison que vous pouvez nommer ? Un non à n'importe quelle étape tranche en faveur du tunnel que vous avez déjà. Archivez la capture et la liste des EtherType avec le registre des changements, car la personne suivante posera la même question et ne voudra pas refaire la mesure.