VPN-failover: wanneer het retourpad in de oude tunnel blijft

De back-uptunnel komt op, de primaire valt weg, en de applicatie loopt nog steeds in een time-out. Op beide locaties ziet de tunnelstatus er gezond uit, en dat is precies wat verwarrend is. Een failover die verzoeken naar de back-up verplaatst maar de antwoorden op het oude pad laat, is geen failover. De runbook hieronder test het retourpad, niet alleen de handshake.

Leg eerst de routes aan beide uiteinden vast; een beeld van één locatie kan geen asymmetrisch pad laten zien. Het is ook de stap die onder tijdsdruk het vaakst wordt overgeslagen.

Leg de routes van beide locaties vast vóór de test

Noteer voor elk beschermd prefix de primaire route, de back-uproute en de voorkeur die daartussen kiest. Neem de LAN-gateway achter elk VPN-eindpunt mee, want het eindpunt is zelden de laatste hop.

Statische metrieken, gevolgde routes en dynamische routering drukken geschiktheid verschillend uit. Weet welke je ontwerp gebruikt, en wat nodig is om het alternatief actief te maken. Schrijf de voorwaarde naast de route, bijvoorbeeld een lagere metriek tot de probe faalt.

Doe dit op beide locaties. Een back-up die aan de ene kant wordt verkozen en aan de andere kant wordt genegeerd, levert precies de asymmetrie op die je probeert te vermijden.

Observeer verzoeken en antwoorden in elke fase

Gebruik een onschadelijke toegestane applicatie en observeer drie fasen: normaal, uitval van het primaire pad en herstel. Leg in elke fase vast welke tunnel het verzoek en welke het antwoord draagt. Een bereikbaar peeradres bewijst niet dat het beschermde applicatiepad werkt. Leg het op beide locaties vast zodat een eenrichtingsstroom zichtbaar wordt.

Als verzoeken verschuiven en antwoorden niet, controleer dan de route van de externe locatie naar het clientprefix en de voorkeur voor de back-up. Dat is een routeringsbeslissing, geen tunnelfout.

Herstel na de test de oorspronkelijke toestand en bevestig dat het primaire pad weer de voorkeur krijgt. Een hersteld primair pad dat niet de voorkeur krijgt, is een failoverontwerp dat niet af is.

Beheer de sessietoestand wanneer de gateway verandert

Firewalls en NAT kunnen verbindingsstatus op één gateway vasthouden, en een padwijziging naar een andere gateway neemt die niet mee. Sommige applicaties verbinden zelf opnieuw; andere falen tot de sessie is hersteld. Als de back-up de publieke bron of het vertaalde privéadres wijzigt, kunnen regels voor externe toegang ook reageren. Documenteer elke verwachte sessieherstart in plaats van een failover zonder onderbreking te beloven.

Houd de adressering stabiel waar de applicatie dat vereist. Een failoverontwerp dat het bronadres voor elke sessie wijzigt, is een ontwerpkeuze, en die moet worden opgeschreven. Die keuze bepaalt hoeveel van de onderbreking gebruikers werkelijk merken.

Test een applicatie die een lange sessie vasthoudt, niet alleen een nieuw verzoek.

Herstel het primaire pad en controleer op flapping

Bevestig dat routeaankondigingen of voorkeuren tot rust komen zonder te oscilleren. Een flappend primair pad kan verstorender zijn dan een duidelijke storing, omdat elke overgang de toestand reset.

Houd gatewaybeheer bereikbaar via een herstelpad, zodat de test je niet zelf buitensluit. Leg de fasen, de waargenomen paden en de hersteltijd vast; die registratie is wat de volgende failover voorspelbaar maakt. De doorstuurnotities van strongSwan zijn nuttig wanneer de eindpunten Linux-hosts zijn.