Dos túneles IPsec activos siguen necesitando un plan de camino de vuelta

Abre una terminal en una estación de trabajo de un sitio y conéctate a un servidor del otro. Esa única conversación TCP ahora tiene que cruzar cuatro puertas de enlace en lugar de dos, y lo interesante no es si funciona en un buen día. Lo interesante es qué par de puertas de enlace eligió la dirección de ida, qué par elige la respuesta y quién mantiene el estado del flujo mientras ocurre. Nada en la tabla de rutas decide eso por ti.

Dibuja cuatro puertas de enlace antes de dibujar una ruta

Un diseño doblemente activo con dos cortafuegos VPN independientes por sitio, un par por proveedor, te da dos caminos utilizables y tres formas de romperlos. Anota las direcciones antes de configurar nada: el cliente tal como se ve antes y después de cada puerta de enlace, el servidor igual, el siguiente salto de ida y el siguiente salto de vuelta.

Esa tabla es el diseño. Todo lo que viene después es una cuestión de si los dispositivos están de acuerdo con la tabla.

Cómo se elige el camino de ida

Una capa de enrutamiento multipath de igual coste distribuye los flujos entre los siguientes saltos mediante hash de campos de la cabecera, lo que RFC 2992 describe en detalle. Esa selección puede ser totalmente sin estado: no necesita ninguna entrada de seguimiento de conexiones, solo un hash estable sobre campos sin cambios. Mantén constantes el conjunto de caminos y las entradas del hash, y cada paquete del flujo elegirá el mismo siguiente salto.

La selección por flujo evita la reordenación que causaría el balanceo paquete a paquete entre enlaces con retrasos distintos. No promete que un coste de enrutamiento igual signifique una latencia medida igual, porque no es así. Y cuando cambia la composición de los caminos, los flujos se vuelven a mapear, así que la supervivencia de la conexión durante un fallo es un requisito aparte de la selección de camino.

Qué necesita de verdad el camino de vuelta

Aquí el recorrido deja de ser simétrico. Un hash de ida estable no te dice nada sobre lo que hará el sitio remoto con la respuesta. Si un cortafuegos independiente debe ver las dos direcciones de la conexión para mantener un estado útil, una ruta de vuelta que lo evita deja el tráfico sin coincidir con nada. Dos cajas con conjuntos de reglas parecidos no son estado compartido.

Confirma el comportamiento bidireccional implementado o escribe una política explícita que mantenga coherentes los límites necesarios. Una suposición aquí se descubre durante una caída, por gente que no lo está disfrutando.

Dónde la traducción decide por ti

NAT es la otra palanca, y es opcional en vez de obligatoria. Las identidades traducidas específicas del camino pueden dirigir las respuestas de vuelta a la puerta de enlace que mantiene el estado, lo cual es un diseño legítimo. También añaden mapas, rutas de vuelta y un propietario de ese estado, así que acepta la carga solo por un requisito que puedas decir en voz alta.

Si el requisito es simplemente que ambos caminos lleven tráfico y que cualquiera sobreviva a la pérdida de un proveedor, el multipath por flujo con enrutamiento de vuelta coherente suele ser el diseño más pequeño.

Recorre la aceptación en orden

Prueba en esta secuencia y registra las direcciones en cada paso: una conexión nueva en el camino A y su camino de respuesta, lo mismo en el camino B, luego la pérdida de un proveedor y luego la restauración. Para cada resultado, anota qué flujos establecidos se movieron, cuáles tuvieron que reconectarse y adónde fueron los flujos nuevos después. Escribe primero el valor esperado y luego compáralo con la captura. Dos túneles establecidos no demuestran nada de eso.

El diseño está terminado cuando la tabla que escribiste coincide con lo que muestra la captura, no cuando ambos túneles están levantados.