Waarom je VPN elke keer wegvalt wanneer de sleutels roteren

De verbinding werkt een uur en sterft dan, en de client meldt niets nuttigers dan disconnected. Juist die periode is de aanwijzing, want iets aan de vernieuwingsuitwisseling verschilt van de eerste handshake. De timer bepaalt alleen wanneer je die tegenkomt. Bewaar de berichten uit die uitwisseling in plaats van het eindlabel.

Lees de fase, niet het label

In IKEv2 worden de IKE-associatie en de CHILD-associatie volgens aparte schema's vernieuwd. Een voorstel dat voor de eerste onderhandeling acceptabel was, is dat voor de tweede niet automatisch. De ene kan voltooien terwijl de andere wordt afgewezen, wat een tunnel oplevert die half bestaat. Leg de uitwisseling vast met het gereedschap dat hem bezit, niet met een clientlogregel:

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Bij OpenVPN is de equivalente gebeurtenis een heronderhandeling die door de versie en de uitrolinstellingen wordt gestuurd. Het authenticatiegedrag heeft zijn eigen faalmodi. Het bericht dat ertoe doet, noemt de mislukte fase, en je moet het letterlijk vastleggen in plaats van het in een ticket te parafraseren.

Noteer ook de tijdstempels. Een uitval met een vast interval na de laatste geslaagde onderhandeling is een heel andere bevinding dan een die tijdens gebruik willekeurig optreedt, en het interval is vaak het enige bewijs dat overleeft.

Vergelijk het voorstel dat faalt

Een afgewezen voorstel levert een duidelijke melding op bij de responder. De gebruikelijke oorzaak is een verschil tussen beide uiteinden in algoritme, sleutellengte, groep of levensduur. De eerste CHILD-onderhandeling kan zijn geslaagd omdat de andere kant hem startte, wat betekent dat de voorstellenlijst van de andere kant is gebruikt. Kijk naar beide uiteinden voordat je iets wijzigt.

Afwijkingen in levensduur verdienen extra aandacht, want een waarde die aan de ene kant ruim leek, kan de andere kant een vernieuwing laten starten die hij niet kan afmaken. De documentatie over het gedrag bij sleutelvernieuwing beschrijft hoe associatievernieuwing wordt geactiveerd en hoe de twee uiteinden kunnen verschillen in hun tijdsverwachtingen. Vergelijk wat elk uiteinde zegt te ondersteunen in plaats van wat het configuratiebestand suggereert.

Een oud profiel of een provider-sjabloon kan een voorstel vastpinnen dat de huidige release niet meer biedt. De afwijking komt pas aan het licht wanneer een nieuwe onderhandeling wordt afgedwongen.

Scheid een probleem met inloggegevens van een onbereikbare peer

Een vernieuwing die de authenticatie niet haalt, ziet er in de client hetzelfde uit en op de server totaal anders. Als een inloggegeven bij de heronderhandeling opnieuw wordt gecontroleerd, zorgen een verlopen certificaat, een ingetrokken account of een gewijzigd wachtwoord voor een uitval precies op het vernieuwingsinterval, terwijl elke eerdere verbinding slaagde. Een onbereikbare peer is de derde mogelijkheid, en die levert helemaal geen afwijzing op: de pakketten gaan naar buiten en niets antwoordt. Dat geval volgt meestal een netwerkverandering in plaats van een timer, dus controleer of de fout na een roaming, een inactieve periode of een routewijziging komt.

Onderscheid de drie aan wat de verre kant heeft gelogd. Een afwijzing met reden, een authenticatiefout en stilte zijn drie verschillende correcties. Een herstart van de client plakt ze samen tot één nutteloze observatie.

Controleer de certificaatdatums en de accountstatus voordat je het netwerk de schuld geeft. Beide zijn goedkoop te inspecteren en beide zijn onzichtbaar in het bericht van de client zelf.

Forceer één vernieuwing en lees het resultaat

Forceer één vernieuwing via de door de operator ondersteunde methode in plaats van een uur te wachten op de volgende. Houd het vereiste faalbeleid intact terwijl je dat doet. Verificatie uitschakelen of levensduren oprekken tot een dag laat het symptoom uit je logs verdwijnen zonder iets te corrigeren. Het laat ook een langere storing achter voor de volgende persoon.

Zodra de oplossing er is, controleer de vernieuwde tunnel en doe dan een nieuw verzoek vanuit de applicatie. Een applicatiesessie die leefde toen de associatie veranderde, heeft mogelijk zijn eigen herstel nodig ook al is de tunnel weer gezond. Gebruikers melden dat als een VPN die nog steeds stuk is.

Leg de releaseversies, de onderhandelde timers en de fase die faalde vast. De volgende keer kan dan met deze worden vergeleken in plaats van opnieuw uit het geheugen te worden beschreven.