Los sitios puenteados siguen necesitando una decisión de salida local a internet

La extensión de VLAN pasó limpia: los equipos de ambos sitios se ven, los recursos compartidos funcionan y las impresoras responden. Luego alguien del sitio más pequeño nota que cada descarga usa la línea de internet del otro sitio, y el ticket llega como una queja de ancho de banda. El puente hizo exactamente lo que se le pidió. Transportaba tramas entre dos edificios y nunca tuvo opinión sobre qué router debían usar esas tramas para internet.

El puente transporta tramas, no decisiones

Una extensión de capa 2 hace que dos ubicaciones parezcan un solo dominio de difusión, así que las solicitudes ARP, las difusiones DHCP y el tráfico de la misma subred cruzan el túnel. Ese es todo el servicio que presta. Nada en el puente inspecciona una dirección de destino, la compara con el enlace ascendente de un sitio ni dirige el tráfico hacia la salida más cercana. Cada cliente sigue tomando su propia decisión local o remota con la dirección y la máscara con las que se configuró.

Ponga dos routers en esa subred compartida y ambos se vuelven puertas de enlace plausibles, esté o no alguno cerca del cliente que lo usa.

Cómo elige un cliente su puerta de enlace

La decisión IPv4 descrita en RFC 1122 es sencilla. Un destino dentro de la subred conectada del cliente se alcanza directamente, con ARP, y un destino fuera de ella va a la puerta de enlace predeterminada configurada. Por eso el tráfico de la misma subred entre los sitios puede cruzar el puente sin ninguna intervención del router, y por eso el tráfico de internet depende por completo de la dirección de puerta de enlace que recibió el cliente. Los dos comportamientos son independientes, y un recurso compartido que funciona solo demuestra el primero.

Si un cliente del sitio pequeño se configuró con el router del sitio grande, sus tramas de internet cruzan primero el túnel y salen desde allí.

Cambiar la ruta predeterminada del propio dispositivo VPN no mueve la puerta de enlace de ese cliente, porque el cliente no usa el dispositivo como router en absoluto. El dispositivo también necesita una ruta separada hacia su par remoto para que el túnel que transporta esas tramas siga activo, y confundir ambas cosas es como una extensión de puente tumba su propio transporte.

Deje que el DHCP exprese la salida prevista

La opción 3 de una respuesta DHCP proporciona una lista de direcciones de router en la subred del cliente, en orden de preferencia, y los clientes normalmente toman la primera que responde. El mecanismo está bien; la propiedad es donde fallan los diseños. Anote qué entrega un arrendamiento real en cada sitio en lugar de suponer que el servidor DHCP más cercano entregará la puerta de enlace más cercana.

Ejecute un asignador coordinado, o dos configurados explícitamente para la misma política, y dé a la política un propietario. Un segundo asignador independiente añadido en el sitio remoto no crea localidad, crea dos autoridades para el mismo dominio de difusión.

No asigne una sola dirección de puerta de enlace a dos routers activos de forma independiente solo para que la configuración de ambos sitios parezca idéntica. Una dirección virtual compartida en un segmento puenteado es un diseño de redundancia de primer salto con sus propios requisitos, y una versión improvisada produce conflictos ARP que parecen pérdida de paquetes intermitente. Si la aplicación no necesita realmente un segmento de capa 2 compartido, prefijos enrutados separados con puertas de enlace locales son más sencillos de operar y más fáciles de explicar durante un incidente.

Pruebe las cuatro cosas por separado

Pida cuatro observaciones, no una. Tome un arrendamiento DHCP nuevo en cada sitio y anote el router y la máscara que recibió. Llegue a un servicio de la misma subred en el otro sitio y confirme que el camino es el puente y no un desvío enrutado. Descargue algo de internet público en cada sitio y confirme qué enlace ascendente lo transportó. Luego baje el túnel y vea qué se rompe, porque un sitio que pierde toda la conectividad cuando falla el puente dependía de la puerta de enlace remota sin que nadie lo notara.

Esos cuatro resultados le dicen si tiene un puente entre sitios, una salida local o un retorno accidental, y recogerlos lleva diez minutos.

El principio de diseño no es glamuroso: el puente decide el alcance, el DHCP decide la puerta de enlace y la tabla de enrutamiento del dispositivo decide el camino propio del túnel. Mantenga los tres en conversaciones separadas, porque un solo cambio que intenta arreglar los tres suele romper dos.