Duas sedes precisam dos mesmos VLAN ID para uma VPN de sede?

Números VLAN iguais em dois escritórios parecem dever ajudar um túnel entre sedes, e não mudam nada do que o túnel transporta. Um VLAN ID identifica um domínio de difusão Ethernet dentro de um edifício; o túnel reencaminha pacotes IP entre as gateways. Duas sedes podem usar uma numeração VLAN completamente diferente e ainda assim encaminhar uma para a outra, e duas sedes podem usar a mesma numeração VLAN e ainda assim não se alcançarem. A variável que decide o alcance é o plano de endereços.

O mito: os mesmos VLAN ID nas duas pontas

A crença vem de um lugar razoável. Dentro de um edifício, duas portas no mesmo VLAN conseguem falar e duas portas em VLAN diferentes não, por isso o número VLAN parece aquilo que concede conectividade. Através de um túnel encaminhado não existe nenhum segmento Ethernet partilhado que a etiqueta possa descrever, e as gateways nunca trocam etiquetas VLAN.

O que o túnel precisa é de um par de âmbitos de endereços que não se sobreponham e de uma política que permita o tráfego entre eles. Mude o VLAN em qualquer escritório e o túnel continua a funcionar, porque nada na configuração do túnel lhe fazia referência. É esse o teste que resolve a discussão: renumerar um VLAN, deixar os endereços intactos e ver se o túnel se mantém.

O teste inverso é igualmente informativo. Dê aos dois escritórios a mesma sub-rede e nenhuma quantidade de números VLAN iguais tornará um endereço inequívoco.

O que o túnel transporta realmente

O IPsec protege os pacotes IP segundo uma política expressa em endereços, protocolos e portas. A arquitetura IPsec descreve esses seletores na camada IP, que está várias camadas acima de tudo o que uma etiqueta de comutador descreve. Quando um pacote entra no túnel já saiu do VLAN; a etiqueta foi consumida pelo comutador local.

Os desenhos baseados em política e em rotas diferem na forma como escolhem o túnel, não no que podem transportar. Um par baseado em política faz corresponder os seletores de tráfego e envia os pacotes correspondentes para o túnel. Um par baseado em rotas encaminha o tráfego numa interface de túnel e deixa a tabela de encaminhamento decidir. Ambos continuam a negociar um âmbito de proteção, por isso uma rota que aponta para o túnel não alarga aquilo que os pares acordaram proteger.

Essa distinção explica uma meia-falha comum: a rota existe, os pacotes entram no túnel e o lado remoto descarta-os porque os seletores negociados nunca incluíram esse prefixo. Ler as políticas instaladas mostra que âmbito entrou realmente em vigor.

ip xfrm policy
ip route show
swanctl --list-sas

A sobreposição que realmente quebra

Dois escritórios com sub-redes distintas encaminham-se limpidamente por um túnel, e os seus números VLAN são irrelevantes. Dois escritórios com a mesma sub-rede não, porque um pedido para um determinado endereço tem dois significados possíveis e a tabela de encaminhamento só pode escolher um. Renumerar uma sede é a solução limpa, e costuma ser mais barata do que as alternativas depois de contadas as alterações de DNS e firewall.

Quando renumerar é impossível, um desenho de tradução deliberado pode apresentar vistas de endereços distintas a cada lado. Isso significa mapeamento um para um, seletores correspondentes, entradas DNS que refletem a vista traduzida e encaminhamento de retorno que sobrevive à reescrita. É um desenho suportado com um custo operacional real, e não é o que muda um VLAN ID faz.

Números VLAN iguais nas duas pontas são por vezes uma coincidência de um modelo partilhado, e tratar essa coincidência como a causa de um túnel funcional leva à alteração errada quando algo se quebra mais tarde.

Um trabalho por camada, escrito

O comutador local decide que portas partilham um domínio de difusão, e a sua numeração VLAN é contabilidade local que nenhuma outra sede precisa de conhecer. A gateway autentica o par e aplica o âmbito de proteção negociado. A tabela de encaminhamento decide para onde vai em seguida um pacote desencriptado, e a política de acesso decide se esse pacote devia ter sido permitido.

Manter esses trabalhos separados é o que torna as alterações seguras. Uma renumeração VLAN num escritório toca no comutador local, no âmbito DHCP e talvez numa zona de firewall, e não toca no túnel. Uma alteração de prefixo toca nos seletores do túnel, nas rotas dos dois lados e na política de acesso, e não toca nas etiquetas do comutador.

As rotas de retorno, o DNS privado e os requisitos de identidade de aplicação são de novo trabalhos separados, e nenhum deles chega copiando um número VLAN da outra sede. Um documento de desenho que lista prefixos alcançáveis e serviços permitidos sobrevive a uma renovação do comutador; um que lista números VLAN não.

Confirme a imagem local com as ferramentas de bridge antes de supor que uma etiqueta chega ao túnel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Quando a extensão de layer-2 é o requisito real

Alguns desenhos precisam genuinamente de comportamento Ethernet entre sedes: uma aplicação legada que depende da descoberta por difusão, uma migração que tem de conservar um endereço enquanto uma máquina se desloca, ou um protocolo que incorpora pressupostos de layer-2. Esses casos exigem um overlay ou um serviço ponte que transporte as tramas, e então a pertença ao VLAN, a prevenção de ciclos e o tratamento de falhas passam a ser questões de ponta a ponta.

É um domínio de falha muito maior, e deveria ser uma escolha deliberada em vez do resultado acidental de uma tentativa de pôr uma partilha de ficheiros a funcionar. Um servidor de ficheiros, base de dados ou aplicação web correntes precisam de um caminho IP autorizado, e serão mais felizes sem um domínio de difusão esticado por baixo.

Escreva o contrato da VPN como prefixos alcançáveis mais serviços permitidos, e registe a etiqueta VLAN apenas onde as operações locais precisarem dela. Cada escritório pode então renumerar a sua própria comutação sem transformar cada alteração num redesenho do túnel.