Étendre un VLAN entre deux sites avec WireGuard et VXLAN

La partie la plus coûteuse d'un changement de fournisseur est rarement les serveurs. Ce sont les adresses : chaque enregistrement DNS, règle de firewall, clé de licence et liste d'autorisation partenaire où vos IP sont inscrites. Si le même VLAN peut exister aux deux endroits pendant que vous déménagez, rien de tout cela n'a à changer. Voici comment une extension de couche 2 se construit à partir de simples briques Linux, et ce qu'il faut réussir avant de lui confier du trafic de production.

Pourquoi étendre, au juste

Renuméroter impose une bascule big bang : tout déménage en une nuit, ou rien. Un VLAN étendu transforme cela en de nombreuses petites étapes. Un serveur déjà déplacé et un serveur pas encore déplacé partagent un sous-réseau et une passerelle, donc vous pouvez déplacer un hôte, le tester dans son nouveau foyer, et le ramener si quelque chose ne va pas. Le coût est un tunnel temporaire ; l'économie est des semaines de renumérotation et une nuit de bascule sans retour possible.

L'objection habituelle est que la couche 2 entre sites est fragile. Elle l'est, si elle est construite comme un bridge plat sur Internet. Construite comme un overlay chiffré, par VLAN, atterrissant dans un vrai fabric, c'est un outil de migration bien élevé.

Les briques

Quatre pièces, toutes dans le noyau Linux mainline :

• WireGuard pour le chemin chiffré point à point entre les deux extrémités. Il est petit, rapide et n'a presque rien que l'on puisse mal configurer.
• VXLAN par-dessus WireGuard, une interface VXLAN par VLAN étendu, pour que chaque segment reste séparé à l'intérieur du tunnel.
• Un bridge Linux par VLAN, joignant l'interface VXLAN au VLAN local.
• Une sous-interface VLAN sur le trunk de l'extrémité vers le switch local.

Sur chaque extrémité, pour un VLAN, la forme est :

# encrypted underlay
ip link add wg0 type wireguard
wg setconf wg0 /etc/wireguard/wg0.conf
ip address add 10.255.0.1/30 dev wg0
ip link set wg0 up

# one VXLAN per stretched VLAN, unicast to the far end over the tunnel
ip link add vx210 type vxlan id 210 local 10.255.0.1 remote 10.255.0.2 dstport 4789
ip link add br210 type bridge
ip link add link eth1 name eth1.210 type vlan id 210
ip link set vx210 master br210
ip link set eth1.210 master br210
ip link set vx210 up; ip link set eth1.210 up; ip link set br210 up

Rendez-le persistant avec NetworkManager ou systemd-networkd une fois que cela fonctionne ; la forme en commandes est la façon la plus claire de voir les couches.

Réglez d'abord le MTU

Presque tous les problèmes « ça pingue mais l'application se fige » sur un VLAN étendu sont du MTU. Chaque couche ajoute une surcharge :

• WireGuard ajoute 60 octets sur IPv4 (80 sur IPv6).
• VXLAN ajoute 50 octets (Ethernet externe, IP, UDP et l'en-tête VXLAN).

Avec un chemin standard de 1500 octets entre les sites, une trame pleine de 1500 octets venant d'un serveur ne peut pas tenir. Vous avez deux options honnêtes : augmenter le MTU du chemin sous-jacent (si le chemin en fibre et les deux extrémités prennent en charge les trames jumbo, c'est la réponse propre), ou abaisser le MTU sur le segment étendu pour la durée de la migration. Ce qu'il ne faut pas faire, c'est espérer que la fragmentation arrange les choses. Testez avec des pings don't-fragment à la taille attendue :

ping -M do -s 1472 <host-on-far-side>

Gardez la protection contre les boucles intacte

Un VLAN étendu joint deux domaines de couche 2, et la correction tentante face aux plaintes du spanning tree est de désactiver le spanning tree sur le port. Ne le faites pas. Filtrez les BPDU uniquement là où l'extrémité de l'extension se raccorde, pour que les deux côtés ne fusionnent pas leurs domaines de spanning tree, pendant que chaque autre port garde une protection complète contre les boucles. Et ne construisez jamais deux extensions parallèles pour le même VLAN à moins que quelque chose n'empêche explicitement que les deux soient actives à la fois.

Faites-le atterrir dans un vrai fabric

Du côté récepteur, le trunk de l'extrémité doit atterrir sur un port de switch ordinaire du fabric, pour que le VLAN étendu devienne un segment normal : même passerelle, même double rattachement, même supervision que n'importe quel segment natif. Si vos numéros de VLAN entrent en conflit avec des numéros déjà utilisés à destination, mappez-les vers une plage libre à l'entrée et tenez une table écrite du mappage. Dans un fabric EVPN, dérivez l'identifiant de segment du numéro local de la destination, jamais de celui de la source, pour que la règle de numérotation propre au fabric tienne toujours.

Prévoyez le débit

Chiffrement plus encapsulation, c'est du travail CPU, et un seul tunnel sur une extrémité donnée a un plafond de débit fixé par ce travail. C'est largement suffisant pour la plupart des migrations, mais c'est un vrai plafond. Mesurez-le sur votre matériel d'extrémité avant la migration avec iperf3 à travers le tunnel, épinglez les interruptions et le travail du tunnel sur un cœur dédié, et décidez à l'avance à quelle charge vous ajoutez un second tunnel sur un second cœur et répartissez les VLAN entre eux.

Un ordre de migration qui fonctionne

• Construisez l'extension et testez-la avec un hôte jetable de chaque côté.
• Vérifiez le MTU de bout en bout à pleine taille de trame.
• Déplacez d'abord un serveur à faible risque. Vérifiez la joignabilité de la passerelle, le DNS, la supervision et les sauvegardes depuis son nouveau foyer.
• Déplacez le reste par lots qui suivent les dépendances de votre application (réplicas de base de données avant les primaires, workers avant les frontaux).
• Déplacez la passerelle en dernier, une fois que la plus grande partie du trafic est locale au nouveau côté.
• Retirez l'extension seulement quand plus rien de l'ancien côté ne répond sur le segment.

Avant de commencer, vérifiez

• Le tunnel est-il chiffré de bout en bout, pas seulement « sur une ligne privée » ?
• Connaissez-vous le plafond de MTU du chemin, mesuré, pas supposé ?
• Le filtrage des BPDU est-il limité aux ports de l'extension ?
• Existe-t-il une table écrite de mappage des VLAN ?
• Avez-vous un plafond de débit mesuré et un plan pour le dépasser ?

Nous construisons ces extensions entre nos propres sites et depuis tout emplacement que nous pouvons atteindre en fibre, pour que les clients viennent chez nous sans renuméroter. Si vous planifiez un déménagement et voulez que les adresses restent en place, nous serons heureux de le planifier avec vous.

Parler à un ingénieur

Related (rows[1])

Voir aussi : Venez chez nous sans renuméroter : extension de couche 2 · Fabric du datacenter : EVPN/VXLAN sur Cisco Nexus · Backbone chiffré multi-sites : le maillage DMVPN