De DPD-timer inkorten maakt VPN-failover niet sneller

Tunnels vallen weg, herstel duurt negentig seconden en de dead-peer-timer staat op tien, dus de timer krijgt de schuld. Die redenering slaat drie fasen over die na de detectie plaatsvinden en meestal het grootste deel van de tijd kosten. Livenessdetectie merkt de stilte op; daarna nemen peerselectie, authenticatie, route-installatie en herverbinding van de applicatie elk hun beurt. De eerste fase inkorten kan de andere niet inkorten, en het kan onrust toevoegen aan een systeem dat al worstelde.

Vier fasen, waarvan je er één kunt timen

Schrijf het herstel als vier gebeurtenissen met tijdstempels. De storing wordt waarneembaar: het laatste nuttige beschermde verkeer en het eerste mislukte verzoek. Het verantwoordelijke mechanisme reageert: livenessdetectie, een routemonitor of een andere gedocumenteerde trigger. Het alternatief wordt bruikbaar: peerselectie, authenticatie, een nieuwe associatie en een route die daadwerkelijk het bedoelde verkeer draagt. De applicatie herstelt: een nieuwe bewerking slaagt en wat in uitvoering was heeft een bepaalde uitkomst.

De liveness-regels van IKEv2 beschrijven bewijs over de peer en zijn uitwisselingen, en zeggen niets over een database of bestandsdienst achter die peer. Een liveness-time-out lezen als een gezondheidscontrole van het hele pad is de fout die de timerjacht begint.

Waarom de timer het minst interessante getal is

Geconfigureerde waarden zijn geen uitwisselbare eenheden. Sommige zijn herhaalintervallen, sommige zijn bovengrenzen voor een poging, en sommige lopen gelijktijdig met andere. Ze bij elkaar optellen levert een getal op dat op een voorspelling lijkt en zich als een gerucht gedraagt. Lees de documentatie voor het veld dat je op het punt staat aan te raken, en noteer welke van de drie soorten het is.

Andere fasen zijn helemaal geen timers. Een herverbindings-backoff, een interactieve authenticatievraag of een client die zijn configuratie alleen bij herstart opnieuw beoordeelt, kunnen elk de storing domineren terwijl elke protocoltimer comfortabel laag staat.

Meet de fase die echt traag is

Leg de storing één keer vast, met tijdstempels aan beide kanten, en vergelijk dan de vier gebeurtenissen in plaats van de eigen tellers van het protocol. Eén goed uitgevoerd observatievenster is beter dan een maand afstellen.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Als het alternatieve eindpunt nooit antwoordt, helpt geen enkele timerwijziging, want onbereikbaarheid is geen detectieprobleem. Als nieuwe beveiligingstoestand snel ontstaat maar de route nog steeds naar het dode pad wijst, zit het probleem in route-installatie en voegt nog een liveness-aanpassing alleen onrust toe.

Het alternatief moet al bruikbaar zijn

Een back-up die in een configuratie is gedefinieerd is geen back-up die werkt. Hij moet bereikbaar zijn vanuit het huidige netwerk van de client, dezelfde identiteit kunnen authenticeren en toestemming hebben om hetzelfde verkeer onder hetzelfde beleid te dragen. Ontdek je een van die drie hiaten tijdens een storing, dan wordt de timerdiscussie irrelevant. Test het alternatief terwijl de primaire gezond is, want dat is de enige keer dat je beide logboeken naast elkaar kunt lezen.

Voorzie het alternatief vooraf, test het bewust terwijl de primaire gezond is, en noteer welke van de vier fasen de tijd kost. Die registratie maakt de volgende wijziging een meting in plaats van een gok.

Onrust bij terugkeer en het beheerpad

De primaire herstellen is een aparte beslissing. Agressief terugkeren kan werk onderbreken dat al op de back-up was hersteld, en een flakkerend pad kan op een instabiele tunnel lijken wanneer de echte fout een route is die blijft oscilleren tussen twee gelijke opties.

Twee gelijkwaardige paden zonder voorkeur zijn de gebruikelijke bron van zichtbaar flakkeren, omdat elke monitor reageert op de keuze van de ander. Bepaal welk pad onder normale omstandigheden de voorkeur heeft, en maak die voorkeur expliciet in de configuratie in plaats van hem aan de routevolgorde over te laten. Definieer vooraf het gewenste terugkeergedrag en wie ervoor verantwoordelijk is. Houd de vorige instellingen en een onafhankelijk beheerpad aan, want een wijziging die je eigen toegang tijdens een storing wegneemt, verandert een netwerkincident in een bezoek ter plaatse.

Herhaal daarna dezelfde werklast en vergelijk dezelfde vier tijdstempels. Een korter herstel dat de applicatie nog steeds laat wachten op dezelfde ontbrekende route of login is geen vooruitgang, het is een ander getal op dezelfde grafiek.