Flydende VPN-backuprute overtager ikke: tjekliste til failover

Din flydende VPN-rute er konfigureret, backupafstanden er højere end den primære, og alligevel flytter intet sig nogensinde. Eller det flytter sig og skifter tilbage minutter senere, mens det trådløse link stadig er nede. I begge tilfælde er det noget andet end den fejl, du bekymrer dig om, der afgør rutens egnethed.

Udfør disse kontroller i rækkefølge. Hver har en stopbetingelse, og en mislykket kontrol kan ikke reddes af dem, der følger. Eksemplerne bruger RouterOS-syntaks, fordi afstand, gateway-rækkevidde og rekursivt næste hop alle er synlige i konfigurationen der, men rækkefølgen gælder for enhver router med sporede statiske ruter.

Navngiv den fejl, backupen skal dække

«Den primære er nede» er fire forskellige iagttagelser. En radio, der mister sin peer, et interface, der mister sin carrier, en fjern gateway, der holder op med at svare, og en applikation, der holder op med at virke, ser alle forskellige ud fra routerens sæde. Skriv ned, hvilken af dem designet er til, før nogen ændrer en afstandsværdi.

Kontroller derefter uafhængigheden. Hvis VPN'ens ydre transport kører over samme trådløse sti eller over et adgangslink, der deler samme upstream, er backupen ikke et andet fejldomæne og vil være nede præcis, når du har brug for den. Træk det primære kabel på papiret: hvis tunnelens egen transport dør med det, dækker den flydende rute kun konfigurationsfejl, ikke afbrydelser.

Hold op med at bede afstanden om at detektere noget

En højere afstand gør en rute mindre foretrukken. Det er hele opgaven. Mens den primære statiske rute forbliver egnet, forbliver den flydende rute inaktiv, og det er korrekt adfærd snarere end en fejl. Fejlen bliver først synlig, når den primære trækkes tilbage eller markeres som utilgængelig.

For statiske ruter kræver det en eksplicit 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

Læs, hvad det tester: det næste hop, ikke destinationen. En radio, der stadig svarer på sin lokale side, mens videresendelsen ud over den er brudt, holder den primære rute aktiv. Det er det stille tilfælde, og afstand plus en gateway-kontrol fanger det ikke. Hvis det tilfælde er vigtigt, skal detektionen komme fra noget, der observerer den fjerne side: et routingprotokols naboskab eller en probe, hvis sti og resultatregel du selv har defineret.

Følg, hvor probens egne pakker går hen

En sundhedsprobe har også en rute. Når datatrafik flytter til VPN'en, kan en ubegrænset probe til samme fjernadresse følge den, lykkes og blive læst som bevis på, at den primære er kommet tilbage. Trafikken vender tilbage til en brudt sti, og cyklussen gentages.

Fastgør proben til den sti, den skal bedømme. I RouterOS er den sædvanlige måde en værtsrute til overvågningsmålet gennem den primære gateway, med et omfang lille nok til, at ingen anden rute kan opløse den, hvilket er det, det rekursive failover-eksempel i RouterOS-manualen bygger. Bekræft det på den levende tabel med backupen aktiv, ikke ud fra konfigurationskommentaren:

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

Definér, hvad et probe-resultat betyder, før du tilføjer mål

Ét mål, der afviser ICMP eller går i vedligeholdelse, ser præcis ud som en stifejl, og tre mål uden en regel giver dig bare tre meninger. Beslut reglen først, og implementér den derefter: for eksempel tæller den primære som nede, når to af tre mål fejler i to på hinanden følgende intervaller, skrevet ned i driftshåndbogen, hvor den næste person finder den.

Sæt fejl- og genopretningstærskler, så én mistet pakke ikke flytter stedet. Hysterese koster lidt detektionstid og køber stabilitet tilbage. Vælg intervallet ud fra, hvor lang en afbrydelse er acceptabel, ikke ud fra hvor hurtigt proben kan køre, og hold tilbagefaldet langsommere end failover, så den primære skal bevise sig selv, før den får trafikken tilbage.

Kontroller returvejen og sessionhistorien

Failover, der kun virker udad, er et halvt design. Fjernstedet har brug for en rute tilbage til dit kildeområde over VPN'en, ellers ankommer returtrafik fra en uventet adresse og rammer firewall-tilstand, der ikke længere passer. Eksisterende sessioner vil bryde, selv når nye forbindelser virker, så sæt det i acceptkriterierne i stedet for at love, at overførslen overlever.

Hold administrativ adgang væk fra den sti, der testes. Hvis din eneste vej ind er gennem den primære, låser en failover-test dig ude af den enhed, der opfører sig forkert.

Kør acceptsekvensen

Tre tests dækker det meste: fysisk tab af den primære, en stille videresendelsesfejl med interfacet stadig oppe, og genopretning af den primære. For hver skal du registrere probens kilde og næste hop, den aktive destinationsrute og en frisk tilladt applikationsudveksling i begge retninger.

Det stille tilfælde er det, der adskiller designs. Hvis backupen ikke overtager der, har du bygget en link-monitor i stedet for en sti-monitor. Beslut, om det er acceptabelt, og skriv begrænsningen, hvor den vagthavende ingeniør vil læse den. En anden tilsluttet tunnel er ikke i sig selv en færdig backup-politik.