Por que dúas sedes coa mesma subrede non son unha soa LAN
Un host decide entre enlace directo e seguinte salto antes de que calquera encamiñador VPN vexa o paquete. Dúas sedes que comparten un prefixo necesitan un enlace estendido ou un plan de renumeración.
Dúas oficinas usan ambas 192.168.77.0/24, e alguén propón un túnel para que sexan unha soa rede. A frase soa simple e agocha tres deseños distintos: dúas LAN independentes que coliden, un segmento Ethernet estendido a propósito por unha WAN e un arranxo de proxy ARP que responde por enderezos remotos. Cal deles teña vostede decide que fai un host co paquete, e a resposta é visible antes de que interveña a pasarela VPN.
O host decide antes que o encamiñador
Un host con enderezo 192.168.77.10/24 compara o destino co seu propio prefixo. Todo o que está dentro dese prefixo está no enlace directo, así que o host resolve directamente o enderezo de capa de enlace do destino. Todo o que queda fóra vai á pasarela predeterminada.
Esa decisión ocorre na pila do host, non no túnel. Unha ruta engadida na pasarela non pode salvar un paquete que o host nunca envía alí.
Así que cando 192.168.77.20 existe só na outra sede, o host local pídeo por ARP e non recibe resposta. O aperto de mans VPN pode estar perfectamente san mentres isto falla. O fallo parece un host morto e non un problema de encamiñamento. Recoñecer esa sinatura aforra unha hora de depuración do túnel.
ARP é unha pregunta de enlace local
ARP pregunta quen posúe un enderezo neste enlace, e a resposta ten que vir de algo que escoite a difusión. Un encamiñador no outro extremo dun túnel IPsec non a escoita, agás que o deseño faga das dúas sedes un só dominio de difusión.
Dous dispositivos co mesmo enderezo empeórano: nin sequera unha resolución exitosa pode dicir cal respondeu.
O enderezamento duplicado non é un fallo de encamiñamento e ningunha ruta o arranxa. Ou as sedes se renumeran en prefixos distintos, ou se converten a propósito nun só dominio de capa de enlace.
Un segmento estendido transporta tramas, non rutas
Un túnel que transporta Ethernet e se conecta a pontes fai que ambas as sedes formen parte dun só dominio de capa de enlace. As difusións ARP chegan ao outro lado, e cada ponte aprende que enderezos MAC están onde. A documentación da ponte de Linux describe esa fronteira de reenvío baseada en MAC.
Aquí a pasarela remota non encamiña en absoluto entre dúas subredes idénticas. As tramas cruzan unha capa inferior que encamiña IP pola súa conta, mentres as pontes estenden a conversa Ethernet.
O custo é un radio de impacto maior. A inundación cara a destinos descoñecidos, os bucles, a asignación DHCP e o enderezamento único necesitan todos un plan que abranga as dúas sedes. Cando a WAN cae, os hosts perden tráfico que consideran local. O filtrado na ponte e as regras VLAN poden restrinxir que cruza, pero o transporte aínda non promete que chegue cada trama de control de enlace local.
O proxy ARP é un terceiro deseño
Un encamiñador pode responder ao ARP por un enderezo remoto e logo encamiñar cara a el. Iso fai que o host remoto pareza estar no enlace directo para o emisor sen estender un dominio de difusión.
É unha ferramenta máis estreita que a ponte: depende do reenvío, das rutas de retorno e dun dono claro para cada enderezo.
Tampouco fai encamiñables protocolos arbitrarios que non sexan IP, nin reproduce un dominio de difusión Ethernet. Úseo cando o requisito sexa exactamente esa substitución, non como atallo para pospoñer a renumeración.
Escolla segundo o requisito e despois verifique
Para o acceso normal de aplicacións entre oficinas, prefixos distintos e rutas explícitas dan unha fronteira máis clara. Ponte cando o requisito sexa realmente adxacencia de capa de enlace. Renumere cando a única razón do prefixo compartido sexa que ninguén o fixo aínda.
Confirme que deseño ten en realidade preguntándolle a un host que fai co destino:
ip route get 192.168.77.20
ip neigh show 192.168.77.20
Un resultado de enlace directo cunha entrada de veciño fallida apunta a unha ruta de capa de enlace ausente. Un resultado via nomea a pasarela e traslada a pregunta ao encamiñamento. Nunha ponte, revise a base de datos de reenvío para ver se a MAC se aprendeu a través do túnel. Cada saída estreita a pregunta de deseño en lugar de reiniciala.