¿Necesitan dos sedes los mismos VLAN ID para una VPN de sede?

Que dos oficinas tengan los mismos números VLAN parece que debería ayudar a un túnel entre sedes, y no cambia nada de lo que transporta el túnel. Un VLAN ID etiqueta un dominio de difusión Ethernet dentro de un edificio; el túnel reenvía paquetes IP entre las pasarelas. Dos sedes pueden usar una numeración VLAN completamente distinta y aun así enrutarse entre sí, y dos sedes pueden usar la misma numeración VLAN y aun así no alcanzarse. La variable que decide el alcance es el plan de direcciones.

El mito: los mismos VLAN ID en ambos extremos

La creencia viene de un lugar razonable. Dentro de un edificio, dos puertos del mismo VLAN pueden hablar y dos puertos de VLAN distintos no, así que el número VLAN parece lo que otorga conectividad. A través de un túnel enrutado no hay ningún segmento Ethernet compartido que la etiqueta pueda describir, y las pasarelas nunca intercambian etiquetas VLAN.

Lo que el túnel necesita es un par de ámbitos de direcciones que no se solapen y una política que permita el tráfico entre ellos. Cambie el VLAN en cualquier oficina y el túnel sigue funcionando, porque nada en la configuración del túnel lo referenciaba. Esa es la prueba que zanja la discusión: renumere un VLAN, deje las direcciones intactas y observe si el túnel se mantiene.

La prueba inversa es igual de informativa. Dé a ambas oficinas la misma subred y ninguna cantidad de números VLAN coincidentes hará que una dirección sea inequívoca.

Qué transporta realmente el túnel

IPsec protege los paquetes IP según una política expresada en direcciones, protocolos y puertos. La arquitectura IPsec describe esos selectores en la capa IP, que está varias capas por encima de todo lo que describe una etiqueta de conmutador. Cuando un paquete entra en el túnel ya ha abandonado el VLAN; la etiqueta la ha consumido el conmutador local.

Los diseños basados en política y en rutas difieren en cómo eligen el túnel, no en lo que pueden transportar. Un par basado en política hace coincidir los selectores de tráfico y envía los paquetes coincidentes al túnel. Un par basado en rutas enruta el tráfico en una interfaz de túnel y deja decidir a la tabla de enrutamiento. Ambos siguen negociando un ámbito de protección, así que una ruta que apunta al túnel no amplía lo que los pares acordaron proteger.

Esa distinción explica un medio fallo habitual: la ruta existe, los paquetes entran en el túnel y el lado remoto los descarta porque los selectores negociados nunca incluyeron ese prefijo. Leer las políticas instaladas muestra qué ámbito entró realmente en vigor.

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

El solapamiento que realmente rompe

Dos oficinas con subredes distintas se enrutan limpiamente por un túnel, y sus números VLAN son irrelevantes. Dos oficinas con la misma subred no, porque una petición para una dirección dada tiene dos significados posibles y la tabla de enrutamiento solo puede elegir uno. Renumerar una sede es la solución limpia, y suele ser más barata que las alternativas una vez contados los cambios de DNS y cortafuegos.

Cuando renumerar es imposible, un diseño de traducción deliberado puede presentar vistas de direcciones distintas a cada lado. Eso significa mapeo uno a uno, selectores coincidentes, entradas DNS que reflejan la vista traducida y enrutamiento de retorno que sobrevive a la reescritura. Es un diseño soportado con un coste operativo real, y no es lo que hace cambiar un VLAN ID.

Los números VLAN coincidentes en ambos extremos son a veces una coincidencia de una plantilla compartida, y tratar esa coincidencia como la causa de un túnel funcional lleva al cambio equivocado cuando algo se rompe más adelante.

Un trabajo por capa, por escrito

El conmutador local decide qué puertos comparten un dominio de difusión, y su numeración VLAN es contabilidad local que ninguna otra sede necesita conocer. La pasarela autentica al par y aplica el ámbito de protección negociado. La tabla de enrutamiento decide adónde va después un paquete descifrado, y la política de acceso decide si ese paquete debería haberse permitido siquiera.

Mantener separados esos trabajos es lo que hace seguros los cambios. Una renumeración VLAN en una oficina toca el conmutador local, el ámbito DHCP y quizá una zona de cortafuegos, y no toca el túnel. Un cambio de prefijo toca los selectores del túnel, las rutas de ambos lados y la política de acceso, y no toca las etiquetas del conmutador.

Las rutas de retorno, el DNS privado y los requisitos de identidad de aplicación son de nuevo trabajos separados, y ninguno llega copiando un número VLAN de la otra sede. Un documento de diseño que enumera prefijos alcanzables y servicios permitidos sobrevive a una renovación del conmutador; uno que enumera números VLAN, no.

Confirme la imagen local con las herramientas de bridge antes de suponer que una etiqueta llega al túnel.

bridge vlan show
ip -br addr
ip route get 10.62.0.20

Cuando la extensión de layer-2 es el requisito real

Algunos diseños necesitan de verdad comportamiento Ethernet entre sedes: una aplicación heredada que depende del descubrimiento por difusión, una migración que debe conservar una dirección mientras una máquina se mueve, o un protocolo que incorpora supuestos de layer-2. Esos casos piden un overlay o un servicio puente que transporte las tramas, y entonces la pertenencia al VLAN, la prevención de bucles y el tratamiento de fallos pasan a ser asuntos de extremo a extremo.

Es un dominio de fallo mucho mayor, y debería ser una elección deliberada en vez del resultado accidental de intentar que funcione un recurso compartido. Un servidor de archivos, una base de datos o una aplicación web corrientes necesitan una ruta IP autorizada, y serán más felices sin un dominio de difusión estirado debajo.

Escriba el contrato de la VPN como prefijos alcanzables más servicios permitidos, y registre la etiqueta VLAN solo donde las operaciones locales la necesiten. Cada oficina podrá entonces renumerar su propia conmutación sin convertir cada cambio en un rediseño del túnel.