VPN L2 versus túnel L3: cinco verificações antes de ligar um site em ponte
Um túnel L3 descarta o cabeçalho Ethernet, por isso ARP, PXE e protocolos não IP deixam de funcionar. Cinco verificações decidem se você precisa mesmo de tramas.
Você liga um site em ponte porque alguma ferramenta insiste que ele deve estar na mesma rede, e três semanas depois está lendo logs de switch às duas da manhã. Esse tipo de intuição decide ligações Ethernet sobre IP demais. Aqui só uma diferença realmente importa: se tramas inteiras viajam de ponta a ponta, ou apenas pacotes IP. Execute as cinco verificações abaixo em sequência e pare na primeira que falhar.
Verifique o que a aplicação coloca realmente no cabo
Antes de qualquer nome de produto entrar na discussão, capture um minuto do tráfego que precisa atravessar o enlace: tcpdump -i eth0 -nn -e 'not ip'. A opção -e imprime o cabeçalho da camada de enlace, e é exatamente a parte que um túnel roteado descarta. Se a captura ficar vazia, sua aplicação fala IP e um túnel L3 a transporta sem alteração. Se surgirem tramas, anote o EtherType, porque 0x0806 é ARP, 0x88cc é LLDP, e um valor de fabricante normalmente significa um protocolo de descoberta sem alternativa IP. É nesse ponto que uma tun interface comum deixa de bastar.
Repita a captura também do lado remoto. Uma trama que existe apenas dentro do switch virtual de um host não é motivo para esticar um domínio de difusão por uma WAN.
Verifique se a descoberta precisa atravessar o enlace
Um túnel roteado não tem segmento compartilhado, então nada endereçado a um grupo chega ao outro lado. ARP, difusões DHCP, mDNS em 224.0.0.251, SSDP e consultas de nome NetBIOS assumem todos um enlace que vários hosts ouvem ao mesmo tempo.
Pergunte de quais deles a aplicação realmente depende e se já existe um proxy para eles. O relay DHCP, a reflexão mDNS e as entradas ARP estáticas removem cada um uma dependência, e cada um é mais um serviço a executar e monitorar. Quando restam dois ou três, a ponte é a resposta honesta.
Verifique quanto custa o cabeçalho extra
As tramas precisam de um lugar para viver, então tudo o que você envia ganha uma segunda pilha de cabeçalhos ao redor. Num overlay VXLAN isso significa um cabeçalho IP externo, um cabeçalho UDP e um cabeçalho VXLAN de 8 bytes, o que empurra uma carga completa de 1,500 bytes além da MTU de caminho de um enlace de internet comum de 1,500 bytes. O OpenVPN no modo tap acrescenta a sua própria sobrecarga na mesma direção. Sem uma MTU menor do lado interno, você fica com um enlace que responde a ping e trava na primeira transferência grande.
A conta não para nos bytes de cabeçalho. A difusão e o multicast que um switch trata em hardware agora correm pela WAN, e cada site em ponte herda o mesmo plano de endereços, a mesma faixa DHCP e o mesmo comportamento com endereços duplicados. Isso torna o enlace bem mais difícil de auditar do que um conjunto roteado com um prefixo por site.
Faça as contas antes de escolher. Um segmento movimentado replicado para três sites pode mover mais tráfego de difusão do que as transferências de arquivos para as quais foi construído.
Verifique que tipo de VPN L2 estão lhe oferecendo
O próprio termo é ambíguo, e a ambiguidade decide quem transporta o seu tráfego. Às vezes descreve a carga: tramas Ethernet dentro de IP, enviadas pela internet como qualquer outro túnel, como fazem VXLAN, ZeroTier e o modo tap do OpenVPN. Às vezes descreve um serviço comprado: um circuito Ethernet de operadora ou um pseudocabo MPLS que une dois sites dentro de uma única rede de provedor.
Ambos lhe dão um segmento, então a aplicação não consegue distingui-los, mas a diferença operacional é grande. Um overlay deixa a responsabilidade pela MTU, pela cifragem e pelo caminho subjacente com você. Um serviço de operadora assume isso e cobra por ele, e não vai rotear as suas tramas pela internet pública de jeito nenhum. Qual você quer depende de os dois sites compartilharem uma operadora ou apenas uma empresa.
Verifique a solução mais barata antes de ligar em ponte
A maioria dos pedidos de um enlace em ponte vem de uma única consulta quebrada, não de um protocolo que realmente precise de tramas. Passe primeiro o resolver e o domínio de busca pelo túnel roteado: dhcp-option DNS 10.8.0.1 junto com dhcp-option DOMAIN internal.example numa configuração de servidor OpenVPN resolve um número surpreendente deles. Um encaminhador local do lado remoto faz o mesmo trabalho sem mover nenhum tráfego de difusão.
Se uma ferramenta antiga ainda falhar, coloque essa ferramenta atrás de um proxy ou de um host de salto no segmento de destino. Um único encaminhador TCP é mais barato de operar do que uma WAN em ponte.
Feche a decisão em ordem: o tráfego carrega um EtherType que não é IP, a descoberta precisa atravessar, a MTU consegue absorver os cabeçalhos extras, um circuito de provedor está realmente disponível, e a solução roteada falhou por um motivo que você consegue nomear? Um não em qualquer etapa encerra o debate a favor do túnel que você já tem. Arquive a captura e a lista de EtherType com o registro de mudanças, porque a próxima pessoa fará a mesma pergunta e não vai querer repetir a medição.