Flytande VPN-reserverute tek ikkje over: sjekkliste for failover

Den flytande VPN-ruta di er konfigurert, reserveavstanden er høgare enn den primære, og likevel flyttar ingenting seg. Eller det flyttar seg, og skiftar tilbake nokre minutt seinare medan den trådlause lenka framleis er nede. I begge tilfelle er det noko anna enn feilen du bryr deg om som avgjer eignaheita til ruta.

Gjer desse kontrollane i rekkjefølgje. Kvar har ein stoppbetingelse, og ein mislukka kontroll kan ikkje reddast av dei som følgjer. Døma brukar RouterOS-syntaks fordi avstand, gateway-tilgjenge og rekursiv neste hopp alle er synlege i konfigurasjonen der, men rekkjefølgja gjeld for kvar ruter med spora statiske ruter.

Namngi feilen som reserven skal dekkje

«Den primære er nede» er fire ulike observasjonar. Ein radio som mistar partnaren sin, eit grensesnitt som mistar beraren, ein ekstern gateway som sluttar å svare, og ein applikasjon som sluttar å verke ser alle ulike ut frå setet til ruteren. Skriv ned kva for ein designet er for, før nokon endrar ein avstandsverdi.

Sjekk deretter sjølvstende. Viss den ytre transporten til VPN-en går over same trådlause sti, eller over ei tilkoplingslenke som deler same oppstraums, er reserven ikkje eit andre feildomene og vil vere nede nøyaktig når du treng han. Trekk den primære kabelen på papiret: viss transporten til tunnelen sjølv døyr med han, dekkjer den flytande ruta berre konfigurasjonsfeil, ikkje avbrot.

Slutt å be avstanden om å oppdage noko

Ein høgare avstand gjer ei rute mindre føretrekt. Det er heile jobben. Så lenge den primære statiske ruta blir verande eigna, blir den flytande ruta verande inaktiv, og det er korrekt åtferd og ikkje ein feil. Feilen blir først synleg når den primære blir trekt tilbake eller merkt som utilgjengeleg.

For statiske ruter krev det ein eksplisitt sporar:

/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

Les kva det testar: neste hopp, ikkje destinasjonen. Ein radio som framleis svarar på si lokale side medan vidaresendinga utover er broten, held den primære ruta aktiv. Det er det stille tilfellet, og avstand pluss gateway-kontroll vil ikkje fange det. Viss det tilfellet er viktig, må oppdaginga kome frå noko som observerer den fjerne sida: eit nabolag i ein rutingsprotokoll, eller ein probe der du sjølv har definert stien og resultatregelen.

Spor kvar pakkane til proben sjølv går

Ein helseprobe har òg ei rute. Når datatrafikken flyttar til VPN-en, kan ein ubegrensa probe til same eksterne adresse følgje han, lukkast og bli lesen som prov på at den primære er tilbake. Trafikken går tilbake til ein broten sti, og syklusen blir gjenteken.

Fest proben til stien han skal vurdere. I RouterOS er den vanlege måten ei vertsrute til overvakingsmålet gjennom den primære gatewayen, med eit omfang lite nok til at inga anna rute kan løyse han, og det er det det rekursive failover-dømet i RouterOS-handboka byggjer. Stadfest det i den levande tabellen med reserven aktiv, ikkje frå konfigurasjonskommentaren:

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

Definer kva eit proberesultat tyder før du legg til mål

Eitt mål som avviser ICMP eller går i vedlikehald ser nøyaktig ut som ein stifeil, og tre mål utan ein regel gjev deg berre tre meiningar. Bestem regelen først, og implementer han deretter: til dømes blir den primære rekna som nede når to av tre mål feilar i to påfølgjande intervall, skrive i driftshandboka der neste person finn han.

Set feil- og gjenopprettingstersklar slik at ein tapt pakke ikkje flyttar staden. Hysterese kostar litt oppdagingstid og kjøper stabilitet tilbake. Vel intervallet ut frå kor lenge eit avbrot er akseptabelt, ikkje ut frå kor raskt proben kan køyre, og hald tilbakefallet seinare enn failover, slik at den primære må prøve seg sjølv før han får trafikken tilbake.

Kontroller returvegen og sesjonshistoria

Failover som berre verkar utover, er eit halvt design. Fjernstaden treng ei rute tilbake til kjeldeområdet ditt over VPN-en, elles kjem returtrafikken frå ei uventa adresse og treff brannmur-tilstand som ikkje lenger passar. Eksisterande sesjonar vil bryte sjølv når nye tilkoplingar verkar, så set det i akseptkriteria i staden for å love at overføringa overlever.

Hald administrativ tilgang borte frå stien som blir testa. Viss den einaste vegen inn er gjennom den primære, låser ein failover-test deg ute frå eininga som oppfører seg feil.

Køyr akseptsekvensen

Tre testar dekkjer det meste: fysisk tap av den primære, ein stille vidaresendingsfeil med grensesnittet framleis oppe, og gjenoppretting av den primære. For kvar, registrer kjelda og neste hopp til proben, den aktive destinasjonsruta, og ein fersk tillaten applikasjonsutveksling i begge retningar.

Det stille tilfellet er det som skil design. Viss reserven ikkje tek over der, har du bygd ein lenkjeovervakar i staden for ein stiovervakar. Bestem om det er akseptabelt, og skriv avgrensinga der den vakthavande ingeniøren vil lese ho. Ein annan tilkopla tunnel er ikkje i seg sjølv ein ferdig reservepolitikk.