VPN por múltiples rutas: cuatro garantías que debe ofrecer el operador

Añada un segundo enlace WAN y los túneles se levantan, pero una copia de archivo sigue atascándose cuando una ruta falla. Los enlaces están sanos y los procesos VPN se ejecutan; lo que falta es un contrato entre el operador y el túnel. Varios sockets no se comportan automáticamente como una sola conexión, y la aplicación que está encima no nota la diferencia hasta que la entrega se rompe. Cada parte del contrato corresponde a un fallo que puede probar, y eso es lo que lo hace útil.

Escriba ese contrato antes de elegir un producto. Tiene cuatro partes: el flujo que recibe la VPN, cómo recupera el operador los datos perdidos, qué identidad de extremo sobrevive a un cambio de ruta y cómo se comporta todo cuando una ruta falla.

El síntoma: los enlaces están activos, la sesión sigue cayendo

Un gráfico de monitorización que muestra ambos enlaces activos solo demuestra que cada ruta puede transportar tráfico. No demuestra que la VPN vea un único flujo ordenado, que un paquete perdido en una ruta se recupere en otra, ni que el par siga sabiendo con qué sesión habla. El resto del contrato cubre lo que ese gráfico no puede mostrar.

Cuando una transferencia se atasca, averigüe si el operador siguió entregando por la ruta superviviente. Si la sesión muere mientras el segundo enlace está inactivo, el operador nunca lo usó. Si la sesión sobrevive pero los datos llegan desordenados o duplicados, el operador mueve paquetes sin un contrato de nivel de conexión. Las marcas de tiempo en ambos lados suelen dejarlo claro.

Esa distinción decide la solución. Un problema de enrutamiento o de política necesita un cambio de selección de ruta; una capa de ordenación y recuperación ausente necesita otro transporte, no un búfer mayor.

Garantía uno: un flujo de bytes a nivel de conexión

Si la VPN necesita un flujo ordenado y fiable, el operador debe identificar rangos de bytes por encima de la ruta individual. Cada conexión TCP subyacente numera solo sus propios segmentos, así que un receptor no puede reordenar entre rutas usando solo esos números.

Multipath TCP es el ejemplo estandarizado. Presenta un flujo de bytes fiable mientras coordina varios subflujos TCP, con mapeo de secuencia y acuse de recibo a nivel de datos. La aplicación lee un flujo, no el subflujo que entregó un fragmento primero.

En Linux, MPTCP se activa por socket mediante IPPROTO_MPTCP. Cuando la negociación no puede usar comportamiento multipath, el retroceso documentado es TCP normal, lo que significa que la aplicación puede seguir funcionando por una ruta sin usar nunca la segunda. Compruebe qué comportamiento negoció realmente el socket desplegado en lugar de suponer que se aplicó la configuración del núcleo.

Garantía dos: ordenación, duplicación y recuperación

Las rutas con retardos y tasas de pérdida distintos obligan al operador a almacenar, reordenar y retransmitir. El contrato debe indicar cuánto almacenamiento se permite, qué contrapresión ve la aplicación y qué ruta transporta una retransmisión.

Una ruta que sigue conectada pero deja de entregar es más difícil que un cierre limpio. El operador debe detectarla, mover los datos pendientes y evitar esperar para siempre un segmento que nunca llegará. Una comprobación simple de que ambos enlaces están activos no cubre este estado.

La duplicación necesita su propia regla. Enviar la misma carga por ambas rutas puede mejorar la latencia, pero el receptor debe suprimir la copia antes de que llegue a la VPN. La protección anti-replay de IPsec es opcional por asociación de seguridad y comprueba los números de secuencia; una capa de duplicación que reordena o repite paquetes puede activarla u ocultar el problema hasta que el túnel caiga.

Garantía tres: identidad de extremo y unión de rutas

El par necesita una forma estable de reconocer la sesión cuando aparece una ruta nueva. Si cada ruta se autentica como un túnel separado, la VPN puede ver dos sesiones en lugar de una. Si el operador une rutas bajo una sesión, debe definir cómo se autentica la nueva y qué ocurre con la antigua.

Anote qué direcciones e identificadores permanecen estables: el extremo del túnel, el identificador de sesión del operador y cualquier proxy intermedio. Un proxy añade otra frontera de disponibilidad y confianza aunque nunca vea la carga protegida.

Aquí también reside la política. Una ruta que se une desde una red inesperada puede ser técnicamente válida y aun así violar el modelo de confianza previsto. Decida si las rutas nuevas se aceptan automáticamente, exigen autenticación o se rechazan.

Garantía cuatro: comportamiento acotado ante fallos

Pruebe un fallo completo de ruta, no solo una ruta lenta. La ruta superviviente debería transportar la sesión sin un crecimiento ilimitado de memoria, y la recuperación no debería depender de un temporizador más largo de lo que la aplicación puede tolerar. Cuando vuelve la ruta fallida, el operador debe decidir si reequilibra o deja el flujo donde está.

Fije límites de almacenamiento, retransmisión y número de rutas, y verifíquelos con pérdida, reordenación, duplicación y desequilibrio de retardo. El ancho de banda agregado es el número menos interesante aquí; la continuidad de entrega y los límites de memoria son el contrato.

Mantenga el estado de recuperación del operador separado del estado criptográfico de la VPN. Una capa de fiabilidad propia que sustituya la autenticación o el cifrado establecidos no es un atajo, y reutilizar números de secuencia entre capas hace que la protección contra repeticiones y el diagnóstico dejen de ser fiables.

Acepte al operador con un plan de pruebas

Escriba las cuatro garantías como comprobaciones de pasa o falla: un flujo ordenado, recuperación definida, identidad de sesión estable y comportamiento de fallo acotado. Ejecute cada comprobación con una ruta degradada y luego con una ruta eliminada.

Una única transferencia de archivo correcta a través de un cambio de ruta no demuestra un funcionamiento continuo. Repita la transferencia mientras alterna la ruta preferida e inspeccione tanto la visión del operador como los contadores propios de la VPN. Si los dos no coinciden sobre qué ruta transportó los datos, el contrato aún no es observable.

Guarde la matriz aprobada con el despliegue. Indica al siguiente ingeniero qué comportamiento se prometió, qué combinaciones de rutas se probaron y qué modo de fallo sigue sin soporte, sin otra ronda de conjeturas a partir de las luces de estado de los enlaces.