A ruta de reserva VPN flotante non toma o relevo: lista de comprobación de conmutación

A súa ruta VPN flotante está configurada, a distancia da reserva é maior ca a da primaria e, con todo, nada se move nunca. Ou móvese e volve cambiar minutos despois mentres a ligazón sen fíos segue caída. En ambos os casos, algo distinto do fallo que lle preocupa decide a elegibilidade da ruta.

Realice estas comprobacións en orde. Cada unha ten unha condición de parada, e unha comprobación fallida non se pode salvar coas seguintes. Os exemplos usan a sintaxe de RouterOS porque a distancia, o alcance da pasarela e o seguinte salto recursivo son visibles na configuración alí, pero a orde aplícase a calquera router con rutas estáticas monitorizadas.

Nomee o fallo que a reserva debe cubrir

«A primaria está caída» son catro observacións distintas. Unha radio que perde o seu par, unha interface que perde a súa portadora, unha pasarela remota que deixa de responder e unha aplicación que deixa de funcionar vense diferentes desde o asento do router. Anote para cal delas é o deseño antes de que alguén cambie un valor de distancia.

Despois comprobe a independencia. Se o transporte exterior da VPN discorre polo mesmo camiño sen fíos, ou por unha ligazón de acceso que comparte o mesmo upstream, a reserva non é un segundo dominio de fallo e estará caída exactamente cando a necesite. Tire do cable primario sobre o papel: se o transporte do propio túnel morre con el, a ruta flotante só cobre erros de configuración, non caídas.

Deixe de pedirlle á distancia que detecte algo

Unha distancia maior fai que unha ruta sexa menos preferida. Ese é todo o traballo. Mentres a ruta estática primaria siga sendo elegible, a ruta flotante permanece inactiva, e iso é un comportamento correcto e non un erro. O fallo só se fai visible cando a primaria se retira ou se marca como inalcanzable.

Para as rutas estáticas iso require un rastrexador 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 que proba iso: o seguinte salto, non o destino. Unha radio que aínda responde no seu lado local mentres o reenvío máis aló está roto mantén activa a ruta primaria. Ese é o caso silencioso, e a distancia máis unha comprobación de pasarela non o detectarán. Se ese caso importa, a detección ten que vir de algo que observe o lado afastado: unha adxacencia de protocolo de encamiñamento, ou unha sonda cuxo camiño e regra de resultado vostede mesmo definise.

Rastrexar a onde van os propios paquetes da sonda

Unha sonda de saúde tamén ten unha ruta. Unha vez que o tráfico de datos pasa á VPN, unha sonda sen restricións ao mesmo enderezo remoto pode seguila, ter éxito e lerse como proba de que a primaria se recuperou. O tráfico volve a un camiño roto e o ciclo repítese.

Fixe a sonda ao camiño que se supón que debe xulgar. En RouterOS a forma habitual é unha ruta de host cara ao obxectivo de monitorización a través da pasarela primaria, cun alcance o bastante pequeno como para que ningunha outra ruta poida resolvela, que é o que constrúe o exemplo de conmutación recursiva do manual de RouterOS. Confírmelo na táboa viva coa reserva activa, non desde o comentario da configuración:

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

Defina que significa o resultado dunha sonda antes de engadir obxectivos

Un obxectivo que rexeita ICMP ou entra en mantemento parece exactamente un fallo de camiño, e tres obxectivos sen regra só lle dan tres opinións. Decida a regra primeiro e logo implémentea: por exemplo, a primaria conta como caída cando dous de cada tres obxectivos fallan durante dous intervalos consecutivos, escrito no manual de operacións onde a seguinte persoa o atopará.

Axuste os limiares de fallo e recuperación para que un paquete perdido non mova o sitio. A histérese custa un pouco de tempo de detección e devolve estabilidade. Escolla o intervalo segundo canto tempo é tolerable unha caída, non segundo o rápido que poida correr a sonda, e manteña o retorno máis lento que a conmutación para que a primaria teña que demostrarse antes de recuperar o tráfico.

Comprobe o camiño de volta e a historia das sesións

Unha conmutación que só funciona de saída é medio deseño. O sitio remoto necesita unha ruta de volta ao seu rango de orixe pola VPN, ou o tráfico de retorno chega desde un enderezo inesperado e choca cun estado de cortafogos que xa non coincide. As sesións existentes romperán aínda que as conexións novas funcionen, así que poña iso nos criterios de aceptación en lugar de prometer a supervivencia da transferencia.

Manteña o acceso de xestión fóra do camiño que se proba. Se a súa única entrada é a través da primaria, unha proba de conmutación déixao fóra do dispositivo que se comporta mal.

Execute a secuencia de aceptación

Tres probas cobren a maior parte: perda física da primaria, un fallo de reenvío silencioso coa interface aínda activa e a restauración da primaria. Para cada unha, rexistre a orixe e o seguinte salto da sonda, a ruta de destino activa e un intercambio de aplicación permitido e fresco en ambas as direccións.

O caso silencioso é o que separa os deseños. Se a reserva non toma o relevo alí, construíu un monitor de ligazón en lugar dun monitor de camiño. Decida se iso é aceptable e escriba a limitación onde o enxeñeiro de garda a lerá. Un segundo túnel conectado non é, por si mesmo, unha política de reserva terminada.