Conmutación por fallo de VPN: cuando el camino de vuelta se queda en el túnel antiguo

El túnel de respaldo se levanta, el primario cae y la aplicación sigue agotando el tiempo de espera. En ambos sitios el estado del túnel parece saludable, y eso es lo que confunde. Una conmutación que mueve las peticiones al respaldo pero deja las respuestas en el camino antiguo no es una conmutación. La guía de abajo prueba el camino de vuelta, no solo el saludo inicial.

Registre primero las rutas en ambos extremos; una vista de un solo sitio no puede mostrar un camino asimétrico. También es el paso que más se omite bajo presión de tiempo.

Registre las rutas de ambos sitios antes de la prueba

Para cada prefijo protegido, escriba la ruta primaria, la ruta de respaldo y la preferencia que elige entre ellas. Incluya la puerta de enlace LAN detrás de cada extremo de VPN, porque el extremo rara vez es el último salto.

Las métricas estáticas, las rutas seguidas y el enrutamiento dinámico expresan la elegibilidad de formas distintas. Sepa cuál usa su diseño y qué hace falta para que la alternativa se vuelva activa. Escriba la condición junto a la ruta, por ejemplo una métrica más baja hasta que falle la sonda.

Hágalo en ambos sitios. Un respaldo preferido en un lado e ignorado en el otro produce exactamente la asimetría que intenta evitar.

Observe las peticiones y las respuestas en cada fase

Use una aplicación permitida e inofensiva y observe tres fases: normal, fallo del primario y restauración. En cada fase, registre qué túnel lleva la petición y cuál lleva la respuesta. Una dirección de par accesible no demuestra que el camino protegido de la aplicación funcione. Capture en ambos sitios para que se vea un flujo unidireccional.

Si las peticiones se mueven y las respuestas no, compruebe la ruta del sitio remoto hacia el prefijo del cliente y su preferencia por el respaldo. Eso es una decisión de enrutamiento, no un fallo del túnel.

Restaure la condición original después de la prueba y confirme que el primario vuelve a ser preferido. Un primario restaurado que no es preferido es un diseño de conmutación que no ha terminado.

Gestione el estado de la sesión cuando cambia la puerta de enlace

Los cortafuegos y el NAT pueden mantener el estado de la conexión en una puerta de enlace, y un cambio de camino a otra puerta no lo transporta. Algunas aplicaciones se reconectan solas; otras fallan hasta que se restablece la sesión. Si el respaldo cambia la fuente pública o la dirección privada traducida, las reglas de acceso remoto también pueden reaccionar. Documente cualquier reinicio de sesión esperado en lugar de prometer una conmutación sin interrupciones.

Mantenga un direccionamiento estable donde la aplicación lo exija. Un diseño de conmutación que cambia la dirección de origen en cada sesión es una decisión de diseño, y debería escribirse. Esa decisión determina cuánta parte de la interrupción notan realmente los usuarios.

Pruebe una aplicación que mantenga una sesión larga, no solo una petición nueva.

Restaure el primario y compruebe si oscila

Confirme que los anuncios de ruta o las preferencias se estabilizan sin oscilar. Un primario que oscila puede ser más perturbador que una caída clara, porque cada transición reinicia el estado.

Mantenga la administración de la puerta de enlace accesible mediante un camino de recuperación para que la propia prueba no lo deje fuera. Registre las fases, los caminos observados y el tiempo de recuperación; ese registro es lo que hace previsible la siguiente conmutación. Las notas de strongSwan sobre reenvío son útiles cuando los extremos son hosts Linux.