Por qué dos sedes con la misma subred no son una sola LAN

Dos oficinas usan ambas 192.168.77.0/24, y alguien propone un túnel para que sean una sola red. La frase suena simple y esconde tres diseños distintos: dos LAN independientes que colisionan, un segmento Ethernet extendido a propósito por una WAN y un arreglo de proxy ARP que responde por direcciones remotas. Cuál de ellos tenga usted decide qué hace un host con el paquete, y la respuesta es visible antes de que intervenga la puerta de enlace VPN.

El host decide antes que el enrutador

Un host con dirección 192.168.77.10/24 compara el destino con su propio prefijo. Todo lo que está dentro de ese prefijo está en el enlace directo, así que el host resuelve directamente la dirección de capa de enlace del destino. Todo lo que queda fuera va a la puerta de enlace predeterminada.

Esa decisión ocurre en la pila del host, no en el túnel. Una ruta añadida en la puerta de enlace no puede rescatar un paquete que el host nunca envía allí.

Así que cuando 192.168.77.20 existe solo en la otra sede, el host local lo pide por ARP y no recibe respuesta. El saludo VPN puede estar perfectamente sano mientras esto falla. El fallo parece un host muerto y no un problema de enrutamiento. Reconocer esa firma ahorra una hora de depuración del túnel.

ARP es una pregunta de enlace local

ARP pregunta quién posee una dirección en este enlace, y la respuesta tiene que venir de algo que oiga la difusión. Un enrutador en el otro extremo de un túnel IPsec no la oye, salvo que el diseño haga de las dos sedes un solo dominio de difusión.

Dos dispositivos con la misma dirección lo empeoran: ni siquiera una resolución exitosa puede decirle cuál respondió.

El direccionamiento duplicado no es un fallo de enrutamiento y ninguna ruta lo arregla. O las sedes se renumeran en prefijos distintos, o se convierten a propósito en un solo dominio de capa de enlace.

Un segmento extendido transporta tramas, no rutas

Un túnel que transporta Ethernet y se conecta a puentes hace que ambas sedes formen parte de un solo dominio de capa de enlace. Las difusiones ARP llegan al otro lado, y cada puente aprende qué direcciones MAC están dónde. La documentación del puente de Linux describe esa frontera de reenvío basada en MAC.

Aquí la puerta de enlace remota no enruta en absoluto entre dos subredes idénticas. Las tramas cruzan una capa inferior que enruta IP por su cuenta, mientras los puentes extienden la conversación Ethernet.

El costo es un radio de impacto mayor. La inundación hacia destinos desconocidos, los bucles, la asignación DHCP y el direccionamiento único necesitan todos un plan que abarque ambas sedes. Cuando la WAN cae, los hosts pierden tráfico que consideran local. El filtrado en el puente y las reglas VLAN pueden restringir qué cruza, pero el transporte todavía no promete que llegue cada trama de control de enlace local.

El proxy ARP es un tercer diseño

Un enrutador puede responder al ARP por una dirección remota y luego enrutar hacia ella. Eso hace que el host remoto parezca estar en el enlace directo para el emisor sin extender un dominio de difusión.

Es una herramienta más estrecha que el puenteo: depende del reenvío, de las rutas de retorno y de un dueño claro para cada dirección.

Tampoco hace enrutables protocolos arbitrarios que no sean IP, ni reproduce un dominio de difusión Ethernet. Úselo cuando el requisito sea exactamente esa sustitución, no como atajo para posponer la renumeración.

Elija según el requisito y luego verifique

Para el acceso normal de aplicaciones entre oficinas, prefijos distintos y rutas explícitas dan una frontera más clara. Puentee cuando el requisito sea realmente adyacencia de capa de enlace. Renumere cuando la única razón del prefijo compartido sea que nadie lo ha hecho todavía.

Confirme qué diseño tiene en realidad preguntándole a un host qué hace con el destino:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Un resultado de enlace directo con una entrada de vecino fallida apunta a una ruta de capa de enlace ausente. Un resultado via nombra la puerta de enlace y traslada la pregunta al enrutamiento. En un puente, revise la base de datos de reenvío para ver si la MAC se aprendió a través del túnel. Cada salida estrecha la pregunta de diseño en lugar de reiniciarla.