Estender uma VLAN entre sites com WireGuard e VXLAN

A parte mais cara de mudar de fornecedor raramente são os servidores. São os endereços: cada registo DNS, regra de firewall, chave de licença e lista de permissões de um parceiro que tem os seus IP escritos lá dentro. Se a mesma VLAN puder existir nos dois lados enquanto a mudança decorre, nada disso tem de mudar. Eis como se constrói uma extensão Layer 2 a partir de peças simples de Linux, e o que é preciso acertar antes de lhe confiar tráfego de produção.

Porquê estender sequer

Alterar endereços obriga a um cutover do tipo big bang: tudo muda numa noite, ou nada muda. Uma VLAN estendida transforma isso em muitos passos pequenos. Um servidor já migrado e um servidor ainda por migrar partilham a subnet e o gateway, pelo que é possível mover um host, testá-lo na nova casa e trazê-lo de volta se algo correr mal. O custo é um túnel temporário. A poupança são semanas de alteração de endereços e uma noite de cutover sem caminho de retorno.

A objeção habitual é que Layer 2 entre sites é frágil. É, se for construído como uma bridge plana sobre a internet. Construído como um overlay encriptado, por VLAN, que aterra num fabric a sério, é uma ferramenta de migração disciplinada.

Os blocos de construção

Quatro peças, todas no kernel Linux mainline:

1. WireGuard para o caminho encriptado ponto a ponto entre os dois endpoints. É pequeno, rápido e quase não tem nada que se possa configurar mal.
2. VXLAN por cima do WireGuard, uma interface VXLAN por VLAN estendida, para que cada segmento fique separado dentro do túnel.
3. Uma bridge Linux por VLAN, que liga a interface VXLAN à VLAN local.
4. Uma sub-interface VLAN no trunk do endpoint em direção ao switch local.

Em cada endpoint, para uma VLAN, a forma é esta:

# 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

Torne a configuração persistente com NetworkManager ou systemd-networkd assim que funcionar. A forma em comandos é a maneira mais clara de ver as camadas.

Acerte primeiro o MTU

Quase todos os problemas de «faz ping mas a aplicação bloqueia» numa VLAN estendida são MTU. Cada camada acrescenta overhead:

• O WireGuard acrescenta 60 bytes sobre IPv4 (80 sobre IPv6).
• O VXLAN acrescenta 50 bytes (Ethernet exterior, IP, UDP e o cabeçalho VXLAN).

Com um caminho padrão de 1500 bytes entre sites, uma frame completa de 1500 bytes vinda de um servidor não cabe. Há duas opções honestas: subir o MTU do caminho underlay (se o percurso de fibra e as duas pontas suportarem jumbo frames, esta é a resposta limpa), ou baixar o MTU no segmento estendido durante a migração. O que não se deve fazer é esperar que a fragmentação resolva. Teste com pings don't-fragment no tamanho esperado:

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

Mantenha a proteção contra loops intacta

Uma VLAN estendida junta dois domínios Layer 2, e a solução tentadora para as queixas do spanning tree é desligar o spanning tree na porta. Não o faça. Filtre BPDUs apenas onde o endpoint da extensão se liga, para que os dois lados não fundam os seus domínios de spanning tree, enquanto todas as outras portas mantêm a proteção completa contra loops. E nunca construa duas extensões paralelas para a mesma VLAN, a menos que algo impeça explicitamente que ambas estejam ativas ao mesmo tempo.

Faça-a aterrar num fabric a sério

No lado recetor, o trunk do endpoint deve aterrar numa porta de switch normal do fabric, para que a VLAN estendida se torne um segmento normal: mesmo gateway, mesmo dual-homing, mesma monitorização que qualquer segmento nativo. Se os números de VLAN colidirem com números já usados no destino, mapeie-os para um intervalo livre à entrada e mantenha uma tabela escrita do mapeamento. Num fabric EVPN, derive o identificador do segmento do número local do destino, nunca do da origem, para que a regra de numeração do próprio fabric continue a valer.

Planeie o throughput

Encriptação mais encapsulamento é trabalho de CPU, e um único túnel num dado endpoint tem um teto de throughput definido por esse trabalho. Chega e sobra para a maioria das migrações, mas é um teto real. Meça-o no hardware do endpoint antes da migração com iperf3 através do túnel, fixe as interrupções e o trabalho do túnel a um core dedicado, e decida de antemão a que carga acrescenta um segundo túnel num segundo core e divide as VLAN entre eles.

Uma ordem de migração que funciona

1. Construa a extensão e teste-a com um host descartável de cada lado.
2. Verifique o MTU de ponta a ponta com frames de tamanho completo.
3. Mova primeiro um servidor de baixo risco. Verifique o acesso ao gateway, o DNS, a monitorização e os backups a partir da nova casa.
4. Mova os restantes em lotes que respeitem as dependências da aplicação (réplicas de bases de dados antes dos primários, workers antes dos front ends).
5. Mova o gateway em último lugar, quando a maior parte do tráfego já for local ao novo lado.
6. Remova a extensão apenas quando nada no lado antigo continuar a responder no segmento.

Antes de começar, verifique

• O túnel está encriptado de ponta a ponta, e não apenas «numa linha privada»?
• Conhece o teto de MTU do caminho, medido e não presumido?
• A filtragem de BPDU está limitada às portas da extensão?
• Existe uma tabela escrita de mapeamento de VLAN?
• Tem um teto de throughput medido e um plano para quando for ultrapassado?

Construímos estas extensões entre os nossos próprios sites e a partir de qualquer localização que consigamos alcançar por fibra, para que os clientes venham para nós sem alterar endereços. Se está a planear uma mudança e quer que os endereços fiquem como estão, teremos todo o gosto em planeá-la consigo.

Fale com um engenheiro

Relacionados: Mude para nós sem alterar endereços: extensão Layer 2 · Fabric do datacenter: EVPN/VXLAN em Cisco Nexus · Backbone encriptado multi-site: a mesh DMVPN