Necesitan dúas sedes os mesmos VLAN ID para unha VPN de sede?

Que dúas oficinas teñan os mesmos números VLAN parece que debería axudar a un túnel entre sedes, e non cambia nada do que transporta o túnel. Un VLAN ID etiqueta un dominio de difusión Ethernet dentro dun edificio; o túnel reenvía paquetes IP entre as pasarelas. Dúas sedes poden usar unha numeración VLAN completamente distinta e aínda así encamiñarse entre si, e dúas sedes poden usar a mesma numeración VLAN e aínda así non alcanzarse. A variable que decide o alcance é o plan de enderezos.

O mito: os mesmos VLAN ID nos dous extremos

A crenza vén dun lugar razoable. Dentro dun edificio, dous portos do mesmo VLAN poden falar e dous portos de VLAN distintos non, así que o número VLAN parece o que outorga conectividade. A través dun túnel encamiñado non hai ningún segmento Ethernet compartido que a etiqueta poida describir, e as pasarelas nunca intercambian etiquetas VLAN.

O que o túnel necesita é un par de ámbitos de enderezos que non se solapen e unha política que permita o tráfico entre eles. Cambie o VLAN en calquera oficina e o túnel segue funcionando, porque nada na configuración do túnel o referenciaba. Esa é a proba que resolve a discusión: renumere un VLAN, deixe os enderezos intactos e observe se o túnel se mantén.

A proba inversa é igual de informativa. Dea a ambas oficinas a mesma subrede e ningunha cantidade de números VLAN coincidentes fará que un enderezo sexa inequívoco.

Que transporta realmente o túnel

IPsec protexe os paquetes IP segundo unha política expresada en enderezos, protocolos e portos. A arquitectura IPsec describe eses selectores na capa IP, que está varias capas por riba de todo o que describe unha etiqueta de conmutador. Cando un paquete entra no túnel xa abandonou o VLAN; a etiqueta consumiuna o conmutador local.

Os deseños baseados en política e en rutas difiren en como elixen o túnel, non no que poden transportar. Un par baseado en política fai coincidir os selectores de tráfico e envía os paquetes coincidentes ao túnel. Un par baseado en rutas encamiña o tráfico nunha interface de túnel e deixa decidir á táboa de encamiñamento. Ambos seguen negociando un ámbito de protección, así que unha ruta que apunta ao túnel non amplía o que os pares acordaron protexer.

Esa distinción explica un medio fallo habitual: a ruta existe, os paquetes entran no túnel e o lado remoto descártaos porque os selectores negociados nunca incluíron ese prefixo. Ler as políticas instaladas mostra que ámbito entrou realmente en vigor.

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

O solapamento que realmente rompe

Dúas oficinas con subredes distintas encamiñanse limpiamente por un túnel, e os seus números VLAN son irrelevantes. Dúas oficinas coa mesma subrede non, porque unha petición para un enderezo dado ten dous significados posibles e a táboa de encamiñamento só pode escoller un. Renumerar unha sede é a solución limpa, e adoita ser máis barata que as alternativas unha vez contados os cambios de DNS e cortalumes.

Cando renumerar é imposible, un deseño de tradución deliberado pode presentar vistas de enderezos distintas a cada lado. Iso significa mapaxe un a un, selectores coincidentes, entradas DNS que reflicten a vista traducida e encamiñamento de retorno que sobrevive á reescritura. É un deseño soportado cun custo operativo real, e non é o que fai cambiar un VLAN ID.

Os números VLAN coincidentes nos dous extremos son ás veces unha coincidencia dun modelo compartido, e tratar esa coincidencia como a causa dun túnel funcional leva ao cambio equivocado cando algo rompe máis adiante.

Un traballo por capa, por escrito

O conmutador local decide que portos comparten un dominio de difusión, e a súa numeración VLAN é contabilidade local que ningunha outra sede necesita coñecer. A pasarela autentica o par e aplica o ámbito de protección negociado. A táboa de encamiñamento decide a onde vai despois un paquete descifrado, e a política de acceso decide se ese paquete debería ter sido permitido.

Manter separados eses traballos é o que fai seguros os cambios. Unha renumeración VLAN nunha oficina toca o conmutador local, o ámbito DHCP e quizais unha zona de cortalumes, e non toca o túnel. Un cambio de prefixo toca os selectores do túnel, as rutas dos dous lados e a política de acceso, e non toca as etiquetas do conmutador.

As rutas de retorno, o DNS privado e os requisitos de identidade de aplicación son de novo traballos separados, e ningún deles chega copiando un número VLAN da outra sede. Un documento de deseño que lista prefixos alcanzables e servizos permitidos sobrevive a unha renovación do conmutador; un que lista números VLAN, non.

Confirme a imaxe local coas ferramentas de bridge antes de supor que unha etiqueta chega ao túnel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Cando a extensión de layer-2 é o requisito real

Algúns deseños necesitan de verdade comportamento Ethernet entre sedes: unha aplicación heredada que depende do descubrimento por difusión, unha migración que debe conservar un enderezo mentres unha máquina se move, ou un protocolo que incorpora supostos de layer-2. Eses casos piden un overlay ou un servizo ponte que transporte as tramas, e entón a pertenza ao VLAN, a prevención de bucles e o tratamento de fallos pasan a ser asuntos de extremo a extremo.

É un dominio de fallo moito maior, e debería ser unha elección deliberada en vez do resultado accidental de intentar que funcione un recurso compartido. Un servidor de ficheiros, unha base de datos ou unha aplicación web correntes necesitan unha ruta IP autorizada, e serán máis felices sen un dominio de difusión estirado debaixo.

Escriba o contrato da VPN como prefixos alcanzables máis servizos permitidos, e rexistre a etiqueta VLAN só onde as operacións locais a necesiten. Cada oficina poderá entón renumerar a súa propia conmutación sen converter cada cambio nun redeseño do túnel.