La ruta de respaldo VPN flotante no toma el relevo: lista de comprobación de conmutación

Su ruta VPN flotante está configurada, la distancia del respaldo es mayor que la de la primaria y, sin embargo, nada se mueve nunca. O se mueve y vuelve a cambiar minutos después, mientras el enlace inalámbrico sigue caído. En ambos casos, algo distinto del fallo que le preocupa decide la elegibilidad de la ruta.

Realice estas comprobaciones en orden. Cada una tiene una condición de parada, y una comprobación fallida no puede salvarse con las siguientes. Los ejemplos usan la sintaxis de RouterOS porque la distancia, el alcance de la puerta de enlace y el siguiente salto recursivo son visibles en la configuración allí, pero el orden se aplica a cualquier router con rutas estáticas monitorizadas.

Nombre el fallo que el respaldo debe cubrir

«La primaria está caída» son cuatro observaciones distintas. Una radio que pierde su par, una interfaz que pierde su portadora, una puerta de enlace remota que deja de responder y una aplicación que deja de funcionar se ven diferentes desde el asiento del router. Anote para cuál de ellas es el diseño antes de que alguien cambie un valor de distancia.

Después compruebe la independencia. Si el transporte exterior de la VPN discurre por el mismo camino inalámbrico, o por un enlace de acceso que comparte el mismo upstream, el respaldo no es un segundo dominio de fallo y estará caído exactamente cuando lo necesite. Tire del cable primario sobre el papel: si el transporte del propio túnel muere con él, la ruta flotante solo cubre errores de configuración, no caídas.

Deje de pedirle a la distancia que detecte algo

Una distancia mayor hace que una ruta sea menos preferida. Ese es todo el trabajo. Mientras la ruta estática primaria siga siendo elegible, la ruta flotante permanece inactiva, y eso es un comportamiento correcto y no un error. El fallo solo se hace visible cuando la primaria se retira o se marca como inalcanzable.

Para las rutas estáticas eso requiere un rastreador explícito:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Lea qué prueba eso: el siguiente salto, no el destino. Una radio que aún responde en su lado local mientras el reenvío más allá está roto mantiene activa la ruta primaria. Ese es el caso silencioso, y la distancia más una comprobación de puerta de enlace no lo detectarán. Si ese caso importa, la detección tiene que venir de algo que observe el lado lejano: una adyacencia de protocolo de enrutamiento, o una sonda cuyo camino y regla de resultado usted mismo haya definido.

Rastree adónde van los propios paquetes de la sonda

Una sonda de salud también tiene una ruta. Una vez que el tráfico de datos pasa a la VPN, una sonda sin restricciones a la misma dirección remota puede seguirla, tener éxito y leerse como prueba de que la primaria se ha recuperado. El tráfico vuelve a un camino roto y el ciclo se repite.

Fije la sonda al camino que se supone que debe juzgar. En RouterOS la forma habitual es una ruta de host hacia el objetivo de monitorización a través de la puerta de enlace primaria, con un alcance lo bastante pequeño como para que ninguna otra ruta pueda resolverla, que es lo que construye el ejemplo de conmutación recursiva del manual de RouterOS. Confírmelo en la tabla viva con el respaldo activo, no desde el comentario de la configuración:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Defina qué significa el resultado de una sonda antes de añadir objetivos

Un objetivo que rechaza ICMP o entra en mantenimiento parece exactamente un fallo de camino, y tres objetivos sin regla solo le dan tres opiniones. Decida la regla primero y luego impleméntela: por ejemplo, la primaria cuenta como caída cuando dos de cada tres objetivos fallan durante dos intervalos consecutivos, escrito en el manual de operaciones donde la siguiente persona lo encontrará.

Ajuste los umbrales de fallo y recuperación para que un paquete perdido no mueva el sitio. La histéresis cuesta un poco de tiempo de detección y devuelve estabilidad. Elija el intervalo según cuánto tiempo es tolerable una caída, no según lo rápido que pueda correr la sonda, y mantenga el retorno más lento que la conmutación para que la primaria tenga que demostrarse antes de recuperar el tráfico.

Compruebe el camino de vuelta y la historia de las sesiones

Una conmutación que solo funciona de salida es medio diseño. El sitio remoto necesita una ruta de vuelta a su rango de origen por la VPN, o el tráfico de retorno llega desde una dirección inesperada y choca con un estado de cortafuegos que ya no coincide. Las sesiones existentes se romperán aunque las conexiones nuevas funcionen, así que ponga eso en los criterios de aceptación en lugar de prometer la supervivencia de la transferencia.

Mantenga el acceso de gestión fuera del camino que se prueba. Si su única entrada es a través de la primaria, una prueba de conmutación le deja fuera del dispositivo que se comporta mal.

Ejecute la secuencia de aceptación

Tres pruebas cubren la mayor parte: pérdida física de la primaria, un fallo de reenvío silencioso con la interfaz aún activa y la restauración de la primaria. Para cada una, registre el origen y el siguiente salto de la sonda, la ruta de destino activa y un intercambio de aplicación permitido y fresco en ambas direcciones.

El caso silencioso es el que separa los diseños. Si el respaldo no toma el relevo allí, ha construido un monitor de enlace en lugar de un monitor de camino. Decida si eso es aceptable y escriba la limitación donde el ingeniero de guardia la leerá. Un segundo túnel conectado no es, por sí mismo, una política de respaldo terminada.