Dos puertas de enlace IPsec sin IP compartida: qué hace realmente el failover

Mata la puerta de enlace A durante una reunión y observa cómo el túnel vuelve por B un minuto después; la conexión funciona, la videollamada quizá no. Esa es la forma honesta de la conmutación en frío entre dos puertas de enlace IPsec con direcciones independientes. El cliente vuelve a elegir un extremo y construye una relación nueva, lo que restaura el alcance sin transferir el estado criptográfico de la sesión antigua. Recorrer la secuencia deja claro qué promesas puede cumplir el diseño.

Preparemos la escena: dos direcciones, ninguna IP flotante

La puerta de enlace A responde en una dirección accesible y la puerta de enlace B en otra. El cliente tiene una forma aprobada de elegir B cuando A desaparece, y no hay una dirección exterior compartida que ambas puertas reclamen. En este diseño, una IP virtual significa ese punto de entrada compartido, no la dirección interna asignada a un cliente de acceso remoto.

Esa definición importa porque las dos ideas se mezclan en los tickets, y la solución de una no es la solución de la otra. Un informe de que la entrada compartida no siguió a la puerta describe un diseño. Un informe de que el portátil perdió su dirección interna describe el arrendamiento del cliente. Distintos propietarios, distintos registros, distintas reparaciones.

Recorramos el fallo: detectar y luego volver a elegir

Primero algo advierte que A dejó de responder. Puede ser la detección de par muerto en la capa de túnel, un protocolo de enrutamiento que retira una ruta, o un tiempo de espera de aplicación que por fin fuerza una reconexión. Cada uno tiene una escala temporal distinta, y el más lento suele determinar cuánto esperan los usuarios.

Después el cliente selecciona B mediante el mecanismo que admita el despliegue: un segundo remoto configurado, un nombre DNS resuelto a una dirección sana, o enrutamiento que ahora prefiere otra ruta. La selección es un paso de política, y debe existir antes del fallo o sucederá por accidente.

Qué puede heredar B y qué no

B puede compartir con A una plantilla de configuración, una autoridad de certificación y una política de autenticación. No puede heredar las asociaciones de seguridad vivas. Las claves de sesión, los índices de parámetros de seguridad y el estado de secuencia pertenecen a la relación que establecieron A y el cliente, y B no tiene ninguno.

Mover ese estado entre puertas es un problema real de ingeniería, por eso la documentación de alta disponibilidad de strongSwan lo trata como un diseño de clúster y no como un indicador de configuración. Una receta concreta de clúster no es una respuesta genérica para una red en la nube, y copiarla sin la infraestructura de apoyo compra complejidad en lugar de continuidad.

Establecer una relación nueva

Con B elegida, el cliente realiza un intercambio IKE nuevo: nuevos nonces, nuevos valores Diffie-Hellman, nuevos identificadores para las asociaciones resultantes. La autenticación ocurre de nuevo en B. Si el diseño se apoya en credenciales de máquina, la reconexión puede ser desatendida; si exige un factor humano, alguien tiene que estar presente para que la conmutación se complete.

Defina esa experiencia de usuario antes de la interrupción, no durante ella. Diga con claridad qué hará el cliente, cuánto intentará y qué mostrará cuando se rinda, porque la diferencia entre un minuto de reconexión y una llamada al soporte suele ser documentación y un perfil probado.

Conservar la misma dirección interna ayuda a las aplicaciones que esperan una identidad local estable, y no conserva sus sesiones. Las vinculaciones NAT caducan, las conexiones TCP se reinician y cualquier cosa con su propio tiempo de espera decide por su cuenta si reintentar.

Dos túneles en paralelo son un diseño distinto

Ejecutar ambos túneles a la vez es un patrón válido cuando lo admiten las dos puertas y el diseño de enrutamiento. Entonces la selección de ruta elige el camino activo, y el camino de vuelta debe coincidir, o el tráfico sale por una puerta y vuelve por la otra sin estado que lo empareje.

Las políticas de túnel solapadas no crean por sí solas una conmutación ordenada. Crean dos candidatos, y algo debe decidir entre ellos de forma determinista, sea una métrica de enrutamiento, una prioridad de política o una preferencia explícita en el cliente.

Elija la forma que elija, escriba el contrato: cómo se detecta el fallo, cómo se selecciona el alternativo, qué autenticación exige y cuánto se prevé que tarde la reconexión. Una IP compartida puede simplificar el descubrimiento, pero no es sinónimo de estado continuo, y la disponibilidad es un diseño en cualquier caso.