La ruta de reserva VPN flotant no pren el relleu: llista de comprovació de commutació

La vostra ruta VPN flotant està configurada, la distància de reserva és més gran que la primària i no es mou mai res. O es mou, i torna enrere uns minuts després mentre l'enllaç sense fil encara està caigut. En tots dos casos, una cosa diferent de la fallada que us importa decideix l'elegibilitat de la ruta.

Feu aquestes comprovacions en ordre. Cadascuna té una condició d'aturada, i una comprovació fallida no es pot salvar amb les següents. Els exemples fan servir la sintaxi de RouterOS perquè la distància, l'abast del gateway i el salt següent recursiu són visibles a la configuració, però l'ordre s'aplica a qualsevol router amb rutes estàtiques seguides.

Anomeneu la fallada que la reserva ha de cobrir

«La primària està caiguda» són quatre observacions diferents. Una ràdio que perd el seu parell, una interfície que perd la portadora, un gateway remot que deixa de respondre i una aplicació que deixa de funcionar es veuen diferents des del seient del router. Anoteu per a quina és el disseny abans que ningú canviï un valor de distància.

Després comproveu la independència. Si el transport exterior de la VPN passa pel mateix camí sense fil, o per un enllaç d'accés que comparteix el mateix upstream, la reserva no és un segon domini de fallada i estarà caiguda exactament quan la necessiteu. Estireu el cable primari sobre el paper: si el transport propi del túnel mor amb ell, la ruta flotant només cobreix errors de configuració, no caigudes.

Deixeu de demanar a la distància que detecti res

Una distància més gran fa que una ruta sigui menys preferida. Aquesta és tota la feina. Mentre la ruta estàtica primària segueixi elegible, la ruta flotant roman inactiva, i això és un comportament correcte, no un error. La fallada només es fa visible quan la primària es retira o es marca com a inabastable.

Per a les rutes estàtiques això requereix un rastrejador explícit:

/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

Llegiu què prova això: el salt següent, no la destinació. Una ràdio que encara respon al seu costat local mentre el reenviament més enllà està trencat manté la ruta primària activa. Aquest és el cas silenciós, i la distància més una comprovació del gateway no el capturaran. Si aquest cas importa, la detecció ha de venir d'alguna cosa que observi el costat llunyà: una adjacència de protocol d'encaminament, o una sonda el camí i la regla de resultat de la qual hàgiu definit vosaltres mateixos.

Rastregueu on van els paquets propis de la sonda

Una sonda de salut també té una ruta. Quan el trànsit de dades es mou a la VPN, una sonda sense restriccions a la mateixa adreça remota pot seguir-la, tenir èxit i ser llegida com a prova que la primària s'ha recuperat. El trànsit torna a un camí trencat i el cicle es repeteix.

Fixeu la sonda al camí que ha de jutjar. A RouterOS la manera habitual és una ruta d'amfitrió cap a l'objectiu de monitoratge a través del gateway primari, amb un abast prou petit perquè cap altra ruta la pugui resoldre, que és el que construeix l'exemple de commutació recursiva del manual de RouterOS. Confirmeu-ho a la taula viva amb la reserva activa, no des del comentari de la configuració:

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

Definiu què significa un resultat de sonda abans d'afegir objectius

Un objectiu que rebutja ICMP o entra en manteniment sembla exactament una fallada de camí, i tres objectius sense regla només us donen tres opinions. Decidiu la regla primer i després implementeu-la: per exemple, la primària compta com a caiguda quan dos de tres objectius fallen durant dos intervals consecutius, escrit al manual d'operacions on la propera persona el trobarà.

Establiu llindars de fallada i recuperació perquè un paquet perdut no mogui el lloc. La histèresi costa una mica de temps de detecció i torna estabilitat. Trieu l'interval segons quant de temps és tolerable una caiguda, no segons com de ràpid pot córrer la sonda, i manteniu el retorn més lent que la commutació perquè la primària s'hagi de demostrar abans de recuperar el trànsit.

Comproveu el camí de tornada i la història de les sessions

Una commutació que només funciona de sortida és mig disseny. El lloc remot necessita una ruta de tornada al vostre rang d'origen per la VPN, o el trànsit de tornada arriba d'una adreça inesperada i topa amb un estat de tallafoc que ja no coincideix. Les sessions existents es trencaran encara que les connexions noves funcionin, així que poseu-ho als criteris d'acceptació en lloc de prometre la supervivència de la transferència.

Manteniu l'accés de gestió fora del camí que es prova. Si la vostra única entrada és a través de la primària, una prova de commutació us deixa fora del dispositiu que es comporta malament.

Executeu la seqüència d'acceptació

Tres proves cobreixen la major part del terreny: pèrdua física de la primària, una fallada de reenviament silenciosa amb la interfície encara aixecada, i restauració de la primària. Per a cadascuna, registreu l'origen i el salt següent de la sonda, la ruta de destinació activa i un intercanvi d'aplicació permès nou en totes dues direccions.

El cas silenciós és el que separa els dissenys. Si la reserva no pren el relleu allà, heu construït un monitor d'enllaç, no un monitor de camí. Decidiu si això és acceptable i escriviu la limitació on l'enginyer de guàrdia la llegirà. Un segon túnel connectat no és, per si mateix, una política de reserva acabada.