Flytende VPN-backuprute overtar ikke: sjekkliste for failover

Din flytende VPN-rute er konfigurert, backupavstanden er høyere enn den primære, og likevel flytter ingenting seg. Eller det flytter seg, og skifter tilbake noen minutter senere mens den trådløse lenken fortsatt er nede. I begge tilfeller er det noe annet enn feilen du bryr deg om som avgjør rutens egnethet.

Utfør disse kontrollene i rekkefølge. Hver har en stoppbetingelse, og en mislykket kontroll kan ikke reddes av dem som følger. Eksemplene bruker RouterOS-syntaks fordi avstand, gateway-tilgjengelighet og rekursiv neste hopp alle er synlige i konfigurasjonen der, men rekkefølgen gjelder for enhver ruter med sporede statiske ruter.

Navngi feilen backupen skal dekke

«Den primære er nede» er fire forskjellige observasjoner. En radio som mister sin peer, et grensesnitt som mister bæreren, en ekstern gateway som slutter å svare, og en applikasjon som slutter å virke ser alle forskjellige ut fra ruterens sete. Skriv ned hvilken av dem designet er for, før noen endrer en avstandsverdi.

Sjekk deretter uavhengigheten. Hvis VPN-ens ytre transport går over samme trådløse sti, eller over en tilkoblingslenke som deler samme oppstrøms, er backupen ikke et andre feildomene og vil være nede nøyaktig når du trenger den. Trekk den primære kabelen på papiret: hvis tunnelens egen transport dør med den, dekker den flytende ruten bare konfigurasjonsfeil, ikke avbrudd.

Slutt å be avstanden om å oppdage noe

En høyere avstand gjør en rute mindre foretrukket. Det er hele jobben. Så lenge den primære statiske ruten forblir egnet, forblir den flytende ruten inaktiv, og det er korrekt oppførsel og ikke en feil. Feilen blir først synlig når den primære trekkes tilbake eller merkes som utilgjengelig.

For statiske ruter krever det en eksplisitt tracker:

/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 hva det tester: neste hopp, ikke destinasjonen. En radio som fortsatt svarer på sin lokale side mens videresendingen utover er brutt, holder den primære ruten aktiv. Det er det stille tilfellet, og avstand pluss gateway-kontroll vil ikke fange det. Hvis det tilfellet er viktig, må oppdagelsen komme fra noe som observerer den fjerne siden: et nabolag i en rutingsprotokoll, eller en probe der du selv har definert stien og resultatregelen.

Spor hvor probens egne pakker går

En helseprobe har også en rute. Når datatrafikken flytter til VPN-en, kan en ubegrenset probe til samme eksterne adresse følge den, lykkes og bli lest som bevis på at den primære er tilbake. Trafikken går tilbake til en brutt sti, og syklusen gjentas.

Fest proben til stien den skal vurdere. I RouterOS er den vanlige måten en vertsrute til overvåkingmålet gjennom den primære gatewayen, med et omfang lite nok til at ingen annen rute kan løse den, og det er det det rekursive failover-eksempelet i RouterOS-håndboken bygger. Bekreft det i den levende tabellen med backupen aktiv, ikke fra konfigurasjonskommentaren:

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

Definer hva et proberesultat betyr før du legger til mål

Ett mål som avviser ICMP eller går i vedlikehold ser nøyaktig ut som en stifeil, og tre mål uten en regel gir deg bare tre meninger. Bestem regelen først, og implementer den deretter: for eksempel telles den primære som nede når to av tre mål feiler i to påfølgende intervaller, skrevet i driftshåndboken der neste person finner den.

Sett feil- og gjenopprettingsterskler slik at én tapt pakke ikke flytter stedet. Hysterese koster litt oppdagelsestid og kjøper stabilitet tilbake. Velg intervallet ut fra hvor lenge et avbrudd er akseptabelt, ikke ut fra hvor raskt proben kan kjøre, og hold tilbakefallet langsommere enn failover, slik at den primære må bevise seg selv før den får trafikken tilbake.

Kontroller returveien og sesjonshistorien

Failover som bare virker utover, er et halvt design. Fjernstedet trenger en rute tilbake til ditt kildeområde over VPN-en, ellers kommer returtrafikken fra en uventet adresse og treffer brannmur-tilstand som ikke lenger passer. Eksisterende sesjoner vil brytes selv når nye tilkoblinger virker, så sett det i akseptkriteriene i stedet for å love at overføringen overlever.

Hold administrativ tilgang borte fra stien som testes. Hvis din eneste vei inn er gjennom den primære, låser en failover-test deg ute fra enheten som oppfører seg feil.

Kjør akseptsekvensen

Tre tester dekker det meste: fysisk tap av den primære, en stille videresendingsfeil med grensesnittet fortsatt oppe, og gjenoppretting av den primære. For hver, registrer probens kilde og neste hopp, den aktive destinasjonsruten, og en fersk tillatt applikasjonsutveksling i begge retninger.

Det stille tilfellet er det som skiller design. Hvis backupen ikke overtar der, har du bygget en lenkeovervåker i stedet for en stiovervåker. Bestem om det er akseptabelt, og skriv begrensningen der den vakthavende ingeniøren vil lese den. En annen tilkoblet tunnel er ikke i seg selv en ferdig backup-policy.