Dos enlaces de subida pero un solo túnel: conmutación, balanceo o agregación

Dos líneas de internet pueden hacer que una VPN esté más disponible, y pueden hacerla más rápida para algunas cargas de trabajo, pero el mecanismo decide cuál de las dos cosas ocurre. Un router con dos rutas por defecto no está agregado, y un túnel que transporta miles de conexiones internas sigue siendo un único flujo externo. Nombrar la promesa primero es la diferencia entre un diseño y una decepción cara. La tabla de abajo separa las opciones según lo que cada una necesita en el extremo remoto y lo que hace una pérdida de enlace a una transferencia.

Tres promesas, y solo una necesita un socio

La conmutación por fallo mantiene un camino disponible cuando el enlace preferido desaparece. El balanceo por hash de flujos reparte flujos independientes entre ambos enlaces de subida. La agregación de un solo flujo permite que una transferencia use ambos enlaces a la vez. Son productos distintos con requisitos distintos, y solo el último necesita la cooperación de algo más allá de su router.

Nada de esa tabla es un motivo para comprar una segunda línea. Lo que hace es impedir que un diseño de conmutación se evalúe como si fuera agregación.

Por qué un túnel parece un solo flujo para el router

Un router que balancea carga aplica un hash a las direcciones de origen y destino junto con los puertos, y luego envía todo el flujo adonde apunta el hash. Un túnel VPN es uno de esos flujos desde la perspectiva del router, sea lo que sea que corra dentro. Las conexiones internas nunca llegan a la decisión del hash, porque la cabecera externa ya decidió el camino. Por eso un segundo enlace de subida puede duplicar la capacidad total para muchos usuarios y no cambiar nada en la transferencia grande de un solo usuario.

Dos túneles separados pueden darle dos candidatos, pero siguen necesitando una política deliberada que asigne el tráfico y mantenga las respuestas por el camino que llevó la petición. El enrutamiento asimétrico es el resultado habitual de saltarse ese paso. El mínimo es una política que nombre el flujo, el enlace preferido y el enlace de reserva.

La agregación Ethernet no cruza proveedores no relacionados, porque el extremo remoto tiene que participar en el protocolo de agregación. Una agregación entre dos proveedores de internet es un proyecto de investigación salvo que exista un extremo que coopere.

Qué necesita el TCP multipath en ambos extremos

La documentación de Linux sobre Multipath TCP describe varios subflujos que pertenecen a una conexión. El soporte del núcleo en un extremo no convierte nada por sí solo, ya que el par también tiene que aceptar esos subflujos. Un proxy en el lado remoto es la otra disposición habitual, y se convierte en un componente con su propia capacidad y disponibilidad que hay que planificar. La misma lógica descarta una respuesta fácil para WireGuard, cuyo transporte es UDP: MPTCP hace crecer subflujos TCP y no puede agregar ese túnel sin algo más en el diseño.

Compruebe si la función del núcleo está activada antes de diseñar en torno a ella, porque muchas distribuciones la entregan desactivada. Estos tres comandos lo responden en un minuto.

sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show

Elija por la carga de trabajo, no por el folleto

Si la carga de trabajo son muchas sesiones independientes, el balanceo por hash de flujos puede añadir capacidad sin cooperación en el extremo remoto. Si es una transferencia grande, solo ayudará un diseño de agregación, y ese diseño necesita un par que coopere. Si el requisito es que el trabajo continúe cuando muere un enlace, la respuesta es la conmutación por fallo y el caudal de una sola transferencia es irrelevante.

Escriba el requisito en una frase con un verbo dentro: una copia de seguridad termina el doble de rápido, o un enlace caído no termina una sesión. Los objetivos vagos producen diseños que nadie puede aceptar ni rechazar. Luego decida qué se permite que sea el extremo remoto, porque la opción más barata suele ser la que no exige nada nuevo allí. Esa restricción elimina la mayoría de las afirmaciones del folleto antes de la primera reunión.

Mantenga las tres promesas separadas en el documento de requisitos. Un diseño que afirma las tres normalmente entrega una y asume en silencio las otras. La sección siguiente comprueba cuál se entrega de verdad.

Pruebe una transferencia y muchas, y luego tire un enlace

Compare una transferencia sostenida con varias transferencias paralelas al mismo destino, y registre la pérdida, el retardo y la utilización por enlace de cada una. Una ganancia solo con sesiones paralelas apunta a la distribución de flujos, no a la agregación de un solo flujo. Pruebe la pérdida de un enlace de subida por separado, porque la capacidad mientras ambos enlaces funcionan no dice nada sobre la conmutación para una sesión establecida. Capture la ruta, el socket y los contadores de retransmisión antes y después de cada prueba.

ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5

Cuando la transferencia única sigue usando un enlace de subida, el diseño hace exactamente lo que implica un hash de flujo. Cuando las transferencias paralelas se reparten entre ambos, el balanceo funciona y la agregación no. Registre cuál de las tres promesas mantiene realmente el diseño, y la próxima conversación sobre capacidad empezará con pruebas en lugar de una afirmación del proveedor.