La rotta di backup VPN flottante non subentra: lista di controllo del failover

La vostra rotta VPN flottante è configurata, la distanza del backup è maggiore di quella primaria, eppure nulla si sposta mai. Oppure si sposta, poi torna indietro pochi minuti dopo mentre il collegamento wireless è ancora abbassato. In entrambi i casi qualcosa di diverso dal guasto che vi interessa decide l'idoneità della rotta.

Eseguite questi controlli in ordine. Ognuno ha una condizione di arresto, e un controllo fallito non può essere salvato da quelli successivi. Gli esempi usano la sintassi RouterOS perché distanza, raggiungibilità del gateway e salto successivo ricorsivo sono tutti visibili lì nella configurazione, ma l'ordine vale per qualsiasi router con rotte statiche tracciate.

Nominate il guasto che il backup deve coprire

«La primaria è giù» sono quattro osservazioni diverse. Una radio che perde il proprio peer, un'interfaccia che perde la portante, un gateway remoto che smette di rispondere e un'applicazione che smette di funzionare appaiono tutti diversi dal posto del router. Annotate per quale di essi è il progetto prima che qualcuno cambi un valore di distanza.

Poi verificate l'indipendenza. Se il trasporto esterno della VPN passa sullo stesso percorso wireless, o su un collegamento di accesso che condivide lo stesso upstream, il backup non è un secondo dominio di guasto e sarà giù esattamente quando vi serve. Tirate il cavo primario sulla carta: se il trasporto del tunnel stesso muore con esso, la rotta flottante copre solo errori di configurazione, non interruzioni.

Smettete di chiedere alla distanza di rilevare qualcosa

Una distanza maggiore rende una rotta meno preferita. È tutto il lavoro. Finché la rotta statica primaria resta idonea, la rotta flottante resta inattiva, e questo è un comportamento corretto, non un difetto. Il guasto diventa visibile solo quando la primaria viene ritirata o contrassegnata come irraggiungibile.

Per le rotte statiche questo richiede un tracker esplicito:

/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

Leggete cosa verifica: il salto successivo, non la destinazione. Una radio che risponde ancora sul proprio lato locale mentre l'inoltro oltre è rotto mantiene attiva la rotta primaria. È il caso silenzioso, e distanza più controllo del gateway non lo coglieranno. Se quel caso conta, il rilevamento deve venire da qualcosa che osserva il lato lontano: un'adiacenza di protocollo di routing, o una sonda di cui avete definito voi il percorso e la regola di risultato.

Tracciate dove vanno i pacchetti della sonda stessa

Anche una sonda di salute ha una rotta. Una volta che il traffico dati passa sulla VPN, una sonda senza vincoli verso lo stesso indirizzo remoto può seguirla, riuscire ed essere letta come prova che la primaria si è ripresa. Il traffico torna su un percorso rotto e il ciclo si ripete.

Fissate la sonda al percorso che deve giudicare. In RouterOS il modo consueto è una rotta host verso l'obiettivo di monitoraggio attraverso il gateway primario, con un ambito abbastanza piccolo che nessun'altra rotta possa risolverla, ed è ciò che costruisce l'esempio di failover ricorsivo del manuale RouterOS. Confermatelo sulla tabella viva con il backup attivo, non dal commento di configurazione:

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

Definite cosa significa il risultato di una sonda prima di aggiungere obiettivi

Un obiettivo che rifiuta ICMP o va in manutenzione appare esattamente come un guasto di percorso, e tre obiettivi senza regola vi danno solo tre pareri. Decidete prima la regola, poi attuatela: per esempio, la primaria conta come giù quando due obiettivi su tre falliscono per due intervalli consecutivi, scritto nel manuale operativo dove la persona successiva lo troverà.

Impostate soglie di guasto e ripristino così che un pacchetto perso non sposti il sito. L'isteresi costa un po' di tempo di rilevamento e ricompra stabilità. Scegliete l'intervallo in base a quanto è tollerabile un'interruzione, non a quanto velocemente può girare la sonda, e tenete il ritorno più lento del failover così la primaria deve dimostrare se stessa prima di riavere il traffico.

Verificate il percorso di ritorno e la storia delle sessioni

Un failover che funziona solo in uscita è mezzo progetto. Il sito remoto ha bisogno di una rotta di ritorno verso il vostro intervallo sorgente attraverso la VPN, altrimenti il traffico di ritorno arriva da un indirizzo inatteso e urta uno stato del firewall che non corrisponde più. Le sessioni esistenti si romperanno anche quando le nuove connessioni funzionano, quindi mettetelo nei criteri di accettazione invece di promettere la sopravvivenza del trasferimento.

Tenete l'accesso di gestione fuori dal percorso testato. Se la vostra unica via d'ingresso è attraverso la primaria, un test di failover vi chiude fuori dal dispositivo che si comporta male.

Eseguite la sequenza di accettazione

Tre test coprono la maggior parte del terreno: perdita fisica della primaria, guasto di inoltro silenzioso con l'interfaccia ancora attiva, e ripristino della primaria. Per ciascuno, registrate l'origine e il salto successivo della sonda, la rotta di destinazione attiva e uno scambio applicativo consentito e fresco in entrambe le direzioni.

Il caso silenzioso è quello che separa i progetti. Se il backup non subentra lì, avete costruito un monitor di collegamento invece di un monitor di percorso. Decidete se è accettabile e scrivete il limite dove l'ingegnere di guardia lo leggerà. Un secondo tunnel connesso non è, di per sé, una politica di backup compiuta.