Zwevende VPN-backuproute neemt niet over: failover-checklist

Uw zwevende VPN-route is geconfigureerd, de afstand van de backup is hoger dan die van de primaire, en toch beweegt er nooit iets. Of hij beweegt en springt minuten later terug terwijl de draadloze verbinding nog steeds plat ligt. In beide gevallen beslist iets anders dan de storing die u aangaat over de geschiktheid van de route.

Voer deze controles in volgorde uit. Elk heeft een stopvoorwaarde, en een mislukte controle kan niet door de volgende worden gered. De voorbeelden gebruiken RouterOS-syntaxis omdat afstand, gateway-bereikbaarheid en recursieve volgende hop daar allemaal zichtbaar zijn in de configuratie, maar de volgorde geldt voor elke router met gevolgde statische routes.

Benoem de storing die de backup moet afdekken

„De primaire ligt eruit“ zijn vier verschillende waarnemingen. Een radio die zijn peer verliest, een interface die zijn drager verliest, een externe gateway die stopt met antwoorden en een applicatie die stopt met werken zien er allemaal anders uit vanaf de plek van de router. Schrijf op voor welke daarvan het ontwerp is, voordat iemand een afstandswaarde wijzigt.

Controleer daarna de onafhankelijkheid. Als het buitenste transport van de VPN over hetzelfde draadloze pad loopt, of over een toegangslink die dezelfde upstream deelt, is de backup geen tweede storingsdomein en ligt hij er precies uit wanneer u hem nodig hebt. Trek de primaire kabel op papier los: als het transport van de tunnel zelf daarmee sterft, dekt de zwevende route alleen configuratiefouten, geen storingen.

Stop met de afstand te vragen iets te detecteren

Een hogere afstand maakt een route minder gewenst. Dat is de hele taak. Zolang de primaire statische route geschikt blijft, blijft de zwevende route inactief, en dat is correct gedrag en geen bug. De storing wordt pas zichtbaar wanneer de primaire wordt ingetrokken of als onbereikbaar gemarkeerd.

Voor statische routes vereist dat een expliciete 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

Lees wat dat test: de volgende hop, niet de bestemming. Een radio die nog op zijn lokale kant antwoordt terwijl de doorsturing verderop kapot is, houdt de primaire route actief. Dat is het stille geval, en afstand plus een gateway-controle zullen het niet vangen. Als dat geval ertoe doet, moet de detectie komen van iets dat de verre kant waarneemt: een nabuurschap van een routeringsprotocol, of een probe waarvan u zelf het pad en de resultaatregel hebt gedefinieerd.

Volg waar de pakketten van de probe zelf heen gaan

Een gezondheidsprobe heeft ook een route. Zodra het dataverkeer naar de VPN gaat, kan een onbeperkte probe naar hetzelfde externe adres hem volgen, slagen en gelezen worden als bewijs dat de primaire is hersteld. Het verkeer keert terug naar een kapot pad en de cyclus herhaalt zich.

Pin de probe vast aan het pad dat hij moet beoordelen. In RouterOS is de gebruikelijke manier een hostroute naar het monitoringdoel via de primaire gateway, met een bereik dat klein genoeg is dat geen andere route hem kan oplossen, en dat is wat het recursieve failover-voorbeeld in de RouterOS-handleiding bouwt. Bevestig het in de live tabel met de backup actief, niet uit het configuratiecommentaar:

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

Definieer wat een proberesultaat betekent voordat u doelen toevoegt

Eén doel dat ICMP weigert of in onderhoud gaat ziet er precies uit als een padstoring, en drie doelen zonder regel geven u alleen drie meningen. Bepaal eerst de regel en implementeer die daarna: bijvoorbeeld, de primaire telt als neer wanneer twee van de drie doelen falen gedurende twee opeenvolgende intervallen, opgeschreven in de runbook waar de volgende persoon het vindt.

Stel storings- en hersteldrempels zo in dat één verloren pakket de locatie niet verplaatst. Hysterese kost wat detectietijd en koopt stabiliteit terug. Kies het interval op basis van hoe lang een storing acceptabel is, niet op basis van hoe snel de probe kan lopen, en houd de terugkeer langzamer dan de failover zodat de primaire zich eerst moet bewijzen voordat hij het verkeer terugkrijgt.

Controleer de terugweg en het sessieverhaal

Een failover die alleen uitgaand werkt, is een half ontwerp. De externe locatie heeft een route terug naar uw bronbereik via de VPN nodig, anders komt retourverkeer van een onverwacht adres en botst het op firewallstatus die niet meer klopt. Bestaande sessies breken zelfs wanneer nieuwe verbindingen werken, dus zet dat in de acceptatiecriteria in plaats van te beloven dat de overdracht overleeft.

Houd beheerstoegang weg van het pad dat wordt getest. Als uw enige ingang via de primaire loopt, sluit een failovertest u buiten het apparaat dat zich misdraagt.

Voer de acceptatiesequentie uit

Drie tests dekken het grootste deel: fysiek verlies van de primaire, een stille doorstuurfout met de interface nog omhoog, en herstel van de primaire. Noteer voor elk de bron en de volgende hop van de probe, de actieve bestemmingsroute, en een verse toegestane applicatie-uitwisseling in beide richtingen.

Het stille geval is degene die ontwerpen scheidt. Als de backup daar niet overneemt, hebt u een linkmonitor gebouwd in plaats van een padmonitor. Beslis of dat acceptabel is, en schrijf de beperking op waar de bereikbaarheidsingenieur die leest. Een tweede verbonden tunnel is op zichzelf geen afgerond back-upbeleid.