Extender una VLAN entre sedes con WireGuard y VXLAN

La parte más cara de cambiar de proveedor rara vez son los servidores. Son las direcciones: cada registro DNS, regla de firewall, clave de licencia y lista de permitidos de un socio que lleva sus IP escritas dentro. Si la misma VLAN puede existir en los dos sitios mientras se muda, nada de eso tiene que cambiar. Así se construye una extensión de capa 2 con piezas de Linux normales, y qué hay que hacer bien antes de confiarle tráfico de producción.

Por qué extender

Renumerar obliga a un cutover de golpe: todo se mueve en una noche, o no se mueve nada. Una VLAN extendida convierte eso en muchos pasos pequeños. Un servidor ya movido y otro aún sin mover comparten subred y gateway, así que puede mover un host, probarlo en su nuevo hogar y devolverlo si algo va mal. El coste es un túnel temporal; el ahorro son semanas de renumeración y una noche de cutover sin vuelta atrás.

La objeción habitual es que la capa 2 entre sedes es frágil. Lo es, si se construye como un bridge plano sobre internet. Construida como un overlay cifrado por VLAN que aterriza en un fabric como es debido, es una herramienta de migración que se porta bien.

Las piezas

Cuatro piezas, todas en el kernel Linux principal:

WireGuard para la ruta cifrada punto a punto entre los dos extremos. Es pequeño, rápido y casi no tiene nada que configurar mal.
VXLAN encima de WireGuard, una interfaz VXLAN por VLAN extendida, para que cada segmento se mantenga separado dentro del túnel.
Un bridge de Linux por VLAN, que une la interfaz VXLAN con la VLAN local.
Una subinterfaz VLAN en el trunk del extremo hacia el switch local.

En cada extremo, para una VLAN, la forma es:

# 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

Hágalo persistente con NetworkManager o systemd-networkd una vez que funcione; la forma de comandos es la manera más clara de ver las capas.

Acierte primero con la MTU

Casi todos los problemas de «hace ping pero la aplicación se cuelga» en una VLAN extendida son MTU. Cada capa añade sobrecarga:

WireGuard añade 60 bytes sobre IPv4 (80 sobre IPv6).
VXLAN añade 50 bytes (Ethernet exterior, IP, UDP y la cabecera VXLAN).

Con una ruta estándar de 1500 bytes entre sedes, una trama completa de 1500 bytes de un servidor no cabe. Tiene dos opciones honestas: subir la MTU de la ruta del underlay (si la ruta de fibra y ambos extremos soportan jumbo frames, esta es la respuesta limpia), o bajar la MTU en el segmento extendido mientras dure la migración. Lo que no debe hacer es esperar que la fragmentación lo resuelva. Pruebe con pings don't-fragment al tamaño que espera:

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

Mantenga intacta la protección contra bucles

Una VLAN extendida une dos dominios de capa 2, y la solución tentadora para las quejas del spanning tree es desactivar el spanning tree en el puerto. No lo haga. Filtre las BPDU solo donde se conecta el extremo de la extensión, para que los dos lados no fusionen sus dominios de spanning tree, mientras todos los demás puertos conservan la protección completa contra bucles. Y nunca construya dos extensiones paralelas para la misma VLAN a menos que algo impida explícitamente que ambas estén activas a la vez.

Aterrícela en un fabric de verdad

En el lado receptor, el trunk del extremo debería aterrizar en un puerto de switch ordinario del fabric, para que la VLAN extendida se convierta en un segmento normal: mismo gateway, misma doble conexión, misma monitorización que cualquiera nativa. Si sus números de VLAN chocan con números ya usados en el destino, mapéelos a un rango libre a la entrada y mantenga una tabla escrita del mapeo. En un fabric EVPN, derive el identificador de segmento del número local del destino, nunca del origen, para que la propia regla de numeración del fabric siga cumpliéndose.

Planifique el rendimiento

Cifrado más encapsulación es trabajo de CPU, y un solo túnel en un extremo dado tiene un techo de rendimiento fijado por ese trabajo. Es de sobra para la mayoría de las migraciones, pero es un techo real. Mídalo en el hardware de su extremo antes de la migración con iperf3 a través del túnel, fije las interrupciones y el trabajo del túnel a un núcleo dedicado, y decida de antemano a qué carga añade un segundo túnel en un segundo núcleo y reparte las VLAN entre ambos.

Un orden de migración que funciona

Construya la extensión y pruébela con un host desechable a cada lado.
Verifique la MTU de extremo a extremo con tramas de tamaño completo.
Mueva primero un servidor de bajo riesgo. Compruebe la alcanzabilidad del gateway, el DNS, la monitorización y los backups desde su nuevo hogar.
Mueva el resto en lotes que respeten las dependencias de su aplicación (réplicas de base de datos antes que primarios, workers antes que front ends).
Mueva el gateway en último lugar, cuando la mayor parte del tráfico sea local al nuevo lado.
Retire la extensión solo cuando nada en el lado antiguo responda ya en el segmento.

Antes de empezar, compruebe

¿Está el túnel cifrado de extremo a extremo, y no solo «sobre una línea privada»?
¿Conoce el techo de MTU de la ruta, medido, no supuesto?
¿El filtrado de BPDU se limita a los puertos de la extensión?
¿Hay una tabla escrita de mapeo de VLAN?
¿Tiene un techo de rendimiento medido y un plan para superarlo?

Construimos estas extensiones entre nuestras propias sedes y desde cualquier ubicación a la que lleguemos por fibra, para que los clientes se muden a nosotros sin renumerar. Si planifica una mudanza y quiere que las direcciones se queden donde están, con gusto la planificamos con usted.

Hable con un ingeniero

Related (rows[1])

Relacionado: Múdese a nosotros sin renumerar: extensión de capa 2 · Fabric del datacenter: EVPN/VXLAN sobre Cisco Nexus · Backbone cifrado multisede: la malla DMVPN