Waarom je VPN langer nodig heeft om te herstellen dan de storing

De wifi kwam dertig seconden geleden terug en de VPN ligt er nog steeds uit, dus de client lijkt kapot. Vaak volgt hij gewoon zijn eigen herhaalplan, en dat plan weet niet dat het netwerk net terug is. Die kloof is het hele verhaal: hersteltijd is de storing plus elke wachttijd waaraan de client zich al heeft gecommitteerd. Elke timer verlagen is één reactie, en begrijpen welke timer ertoe doet is de andere.

Drie voorwaarden bepalen of afstellen helpt: welke fase traag is, of de fout überhaupt herhaalbaar is, en hoe de client leert dat het netwerk terug is.

Drie wachttijden die op één lijken

Eindpuntresolutie, IKE- of TLS-onderhandeling, pakketretransmissie en een nieuwe poging starten zijn afzonderlijke gebeurtenissen met afzonderlijke timers. strongSwan documenteert retransmissie-backoff voor IKE, en OpenVPN heeft zijn eigen herhaalbesturing met een andere semantiek. Een getal van de ene naar de andere kopiëren veronderstelt dat de mechanismen overeenkomen, en dat doen ze niet. Lees de logvolgorde voordat je besluit welk interval je bekijkt.

Een stille minuut in de log is niet per se een bevroren proces. Het kan een exponentiële backoff zijn die precies doet waarvoor hij is ingesteld.

Welke fase is echt traag?

Als de log pogingen toont die mislukken met een authenticatiefout, helpt geen enkele timerwijziging, omdat de inloggegevens onjuist zijn. Als er helemaal geen pogingen worden gedaan, zit de client in zijn wachtvenster en is het plan de oplossing. Als er pogingen worden gedaan en die verlopen, is het probleem bereikbaarheid of een ontbrekende listener, en sneller herhalen vult alleen de log. Elk van die drie toestanden heeft een andere eigenaar, en slechts één ervan is een timingprobleem.

Classificeer de fout voordat je een getal aanraakt.

Wanneer het verlagen van een timer helpt, en wanneer niet

Verlaag het herhaalplafond wanneer de dominante kosten wachten zijn na een korte, frequente storing, zoals een laptop die tussen toegangspunten beweegt. Laat het met rust wanneer storingen lang of zeldzaam zijn, omdat agressief herhalen belasting toevoegt op precies het moment dat de concentrator het minst kan antwoorden. Verander in beide gevallen één parameter, leg hem vast en meet het volgende herstel in plaats van aan te nemen dat het beter is geworden.

Een zeer lage time-out die in elk profiel wordt gekopieerd, is de gebruikelijke eindtoestand van afstellen zonder meting.

Controleer de gereedheid voordat je de client de schuld geeft

De client kan vaak niet zien dat het netwerk bruikbaar is totdat iets het probeert. Een captive portal, een DHCP-vernieuwing of een routewijziging kunnen hem laten wachten op een plan dat is ingesteld voordat dat allemaal gebeurde. Kijk naar de netwerkstatuswijziging van het besturingssysteem en de volgende poging van de client op dezelfde klok, en je ziet van wie de wachttijd is. De snelle versie is het tijdstempel van de netwerk-gereed-gebeurtenis en het tijdstempel van de eerste poging daarna noteren.

Bevestig ook dat direct verkeer tijdens het wachten nog steeds geblokkeerd is, want een snellere herverbinding die verkeer lekt is geen verbetering.

Wat je moet vastleggen

Schrijf op welke timer is gewijzigd, van welke waarde naar welke, en hoe het herstel er daarna uitzag. Noteer ook de clientversie, want standaardwaarden verschuiven tussen releases en een ongedocumenteerde zeer lage time-out zal de volgende persoon die het profiel leest verwarren.

Die vastlegging maakt de volgende software-upgrade een vergelijking in plaats van een experiment.