Flytande VPN-backupväg tar inte över: checklista för failover

Flytande statiska vägar väntar på lämplighet, inte på att paket ska stanna. Sex ordnade kontroller av probvägen, trösklar och återgång på en VPN-backup.

Din flytande VPN-väg är konfigurerad, backupavståndet är högre än det primära, och ändå flyttar ingenting någonsin. Eller så flyttar det och växlar tillbaka minuter senare medan den trådlösa länken fortfarande är nere. I båda fallen är det något annat än felet du bryr dig om som avgör vägens lämplighet.

Utför dessa kontroller i ordning. Var och en har ett stoppvillkor, och en misslyckad kontroll kan inte räddas av de som följer. Exemplen använder RouterOS-syntax eftersom avstånd, gateway-åtkomst och rekursivt nästa hopp alla syns i konfigurationen där, men ordningen gäller för varje router med spårade statiska vägar.

Namnge felet som backupen måste täcka

«Den primära är nere» är fyra olika observationer. En radio som tappar sin peer, ett gränssnitt som tappar sin bärare, en fjärrgateway som slutar svara och en applikation som slutar fungera ser alla olika ut från routerns plats. Skriv ner vilken av dem designen är för innan någon ändrar ett avståndsvärde.

Kontrollera sedan oberoendet. Om VPN:ens yttre transport går över samma trådlösa väg, eller över en accesslänk som delar samma uppströms, är backupen inte en andra feldomän och kommer att vara nere precis när du behöver den. Dra den primära kabeln på papperet: om tunnelns egen transport dör med den täcker den flytande vägen bara konfigurationsfel, inte avbrott.

Sluta be avståndet att upptäcka något

Ett högre avstånd gör en väg mindre föredragen. Det är hela jobbet. Så länge den primära statiska vägen är lämplig förblir den flytande vägen inaktiv, och det är korrekt beteende och inte en bugg. Felet blir synligt först när den primära dras tillbaka eller markeras som oåtkomlig.

För statiska vägar kräver det en explicit spårare:

/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 vad det testar: nästa hopp, inte destinationen. En radio som fortfarande svarar på sin lokala sida medan vidarebefordran bortom den är trasig håller den primära vägen aktiv. Det är det tysta fallet, och avstånd plus en gateway-kontroll fångar det inte. Om det fallet spelar roll måste upptäckten komma från något som observerar den bortre sidan: ett grannskap i ett routingprotokoll, eller en prob där du själv definierat vägen och resultatregeln.

Spåra vart probens egna paket tar vägen

En hälsoprob har också en väg. När datatrafiken flyttar till VPN:en kan en obegränsad prob till samma fjärradress följa den, lyckas och läsas som bevis på att den primära är tillbaka. Trafiken går tillbaka till en trasig väg och cykeln upprepas.

Fäst proben vid den väg den ska bedöma. I RouterOS är det vanliga sättet en värdväg till övervakningsmålet via den primära gatewayen, med en omfattning liten nog att ingen annan väg kan lösa den, och det är vad det rekursiva failover-exemplet i RouterOS-handboken bygger. Bekräfta det i den levande tabellen med backupen aktiv, inte från konfigurationskommentaren:

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

Definiera vad ett probresultat betyder innan du lägger till mål

Ett mål som avvisar ICMP eller går i underhåll ser exakt ut som ett vägfel, och tre mål utan en regel ger dig bara tre åsikter. Bestäm regeln först och implementera den sedan: till exempel räknas den primära som nere när två av tre mål misslyckas under två på varandra följande intervall, nedskrivet i driftboken där nästa person hittar det.

Ställ in fel- och återhämtningströsklar så att ett förlorat paket inte flyttar platsen. Hysteres kostar lite upptäcktstid och köper tillbaka stabilitet. Välj intervallet utifrån hur länge ett avbrott är tolerabelt, inte utifrån hur snabbt proben kan köra, och håll återgången långsammare än failovern så att den primära måste bevisa sig innan den får tillbaka trafiken.

Kontrollera returvägen och sessionshistoriken

En failover som bara fungerar utåt är ett halvt design. Fjärrplatsen behöver en väg tillbaka till ditt källområde över VPN:en, annars kommer returtrafiken från en oväntad adress och träffar brandväggstillstånd som inte längre stämmer. Befintliga sessioner kommer att brytas även när nya anslutningar fungerar, så sätt det i acceptanskriterierna i stället för att lova att överföringen överlever.

Håll administrativ åtkomst borta från vägen som testas. Om din enda väg in är genom den primära låser ett failovertest ut dig från enheten som beter sig fel.

Kör acceptanssekvensen

Tre tester täcker det mesta: fysisk förlust av den primära, ett tyst vidarebefordringsfel med gränssnittet fortfarande uppe, och återställning av den primära. För varje, registrera probens källa och nästa hopp, den aktiva destinationsvägen, och ett färskt tillåtet applikationsutbyte i båda riktningarna.

Det tysta fallet är det som skiljer designer åt. Om backupen inte tar över där har du byggt en länkmonitor i stället för en vägmonitor. Bestäm om det är acceptabelt, och skriv begränsningen där jourhavande ingenjör kommer att läsa den. En andra ansluten tunnel är inte i sig en färdig backuppolicy.

Relaterade artiklar