Os sitios ponteados seguen necesitando unha decisión de saída local a internet
Un segmento Ethernet compartido non decide que router usa un cliente. Separe a ponte da opción de router do DHCP e faga deliberada a saída de cada sitio.
A extensión de VLAN pasou limpa: os equipos de ambos os sitios vense, os recursos compartidos funcionan e as impresoras responden. Despois alguén do sitio máis pequeno nota que cada descarga usa a liña de internet do outro sitio, e o ticket chega como unha queixa de ancho de banda. A ponte fixo exactamente o que se lle pediu. Transportaba tramas entre dous edificios e nunca tivo opinión sobre que router debían usar esas tramas para internet.
A ponte transporta tramas, non decisións
Unha extensión de capa 2 fai que dúas localizacións parezan un só dominio de difusión, así que as solicitudes ARP, as difusións DHCP e o tráfico da mesma subrede cruzan o túnel. Ese é todo o servizo que presta. Nada na ponte inspecciona un enderezo de destino, compárao coa ligazón ascendente dun sitio nin dirixe o tráfico cara á saída máis próxima. Cada cliente segue tomando a súa propia decisión local ou remota co enderezo e a máscara cos que se configurou.
Pon dous routers nesa subrede compartida e ambos se converten en portas de enlace plausibles, estea ou non algún preto do cliente que o usa.
Como escolle un cliente a súa porta de enlace
A decisión IPv4 descrita en RFC 1122 é sinxela. Un destino dentro da subrede conectada do cliente alcánzase directamente, con ARP, e un destino fóra dela vai á porta de enlace predeterminada configurada. Por iso o tráfico da mesma subrede entre os sitios pode cruzar a ponte sen ningunha intervención do router, e por iso o tráfico de internet depende por completo do enderezo de porta de enlace que recibiu o cliente. Os dous comportamentos son independentes, e un recurso compartido que funciona só demostra o primeiro.
Se un cliente do sitio pequeno se configurou co router do sitio grande, as súas tramas de internet cruzan primeiro o túnel e saen desde alí.
Cambiar a ruta predeterminada do propio dispositivo VPN non move a porta de enlace dese cliente, porque o cliente non usa o dispositivo como router en absoluto. O dispositivo tamén necesita unha ruta separada cara ao seu par remoto para que o túnel que transporta esas tramas siga activo, e confundir ambas as cousas é como unha extensión de ponte bota abaixo o seu propio transporte.
Deixa que o DHCP exprese a saída prevista
A opción 3 dunha resposta DHCP fornece unha lista de enderezos de router na subrede do cliente, por orde de preferencia, e os clientes normalmente collen a primeira que responde. O mecanismo está ben; a propiedade é onde fallan os deseños. Anota que entrega un arrendamento real en cada sitio en lugar de supoñer que o servidor DHCP máis próximo dará a porta de enlace máis próxima.
Executa un asignador coordinado, ou dous configurados explicitamente para a mesma política, e dálle un propietario á política. Un segundo asignador independente engadido no sitio remoto non crea localidade, crea dúas autoridades para o mesmo dominio de difusión.
Non asignes unha soa dirección de porta de enlace a dous routers activos de forma independente só para que a configuración de ambos os sitios pareza idéntica. Unha dirección virtual compartida nun segmento ponteado é un deseño de redundancia de primeiro salto cos seus propios requisitos, e unha versión artesanal produce conflitos ARP que parecen perda de paquetes intermitente. Se a aplicación non necesita realmente un segmento de capa 2 compartido, prefixos encamiñados separados con portas de enlace locais son máis sinxelos de operar e máis fáciles de explicar durante un incidente.
Proba as catro cousas por separado
Pide catro observacións, non unha. Colle un arrendamento DHCP novo en cada sitio e anota o router e a máscara que recibiu. Chega a un servizo da mesma subrede no outro sitio e confirma que o camiño é a ponte e non un desvío encamiñado. Descarga algo de internet público en cada sitio e confirma que ligazón ascendente o transportou. Despois baixa o túnel e mira que se rompe, porque un sitio que perde toda a conectividade cando falla a ponte dependía da porta de enlace remota sen que ninguén o notase.
Eses catro resultados dinche se tes unha ponte entre sitios, unha saída local ou un retorno accidental, e recollelos leva dez minutos.
O principio de deseño non é glamuroso: a ponte decide o alcance, o DHCP decide a porta de enlace e a táboa de encamiñamento do dispositivo decide o camiño propio do túnel. Mantén os tres en conversas separadas, porque un só cambio que intenta arranxar os tres adoita romper dous.