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.

Artigos relacionados