De VPN-sessietimer en het authenticatietoken verlopen apart

Een VPN-onderbreking kan ontstaan door oorzaken die er vanaf de client identiek uitzien en onder de oppervlakte niets gemeen hebben: de tunnelsessie eindigde, een inactiviteitstimer sprong aan, of een referentie die de client hergebruikte raakte verouderd. Elk heeft een andere eigenaar en een andere oplossing. Juist de foutenreeks op het moment van de onderbreking onderscheidt ze, en die is meestal één regel.

Drie klokken lopen tegen één tunnel, en slechts één ervan is de tunnel.

Drie verschillende klokken op één tunnel

De sessieklok is van de gateway: een maximale verbindingsduur, een inactiviteitstimeout of beide, en hij beëindigt de tunnel zodra een van beide is bereikt. De tokenklok is van het authenticatiesysteem, en die bepaalt hoe lang een referentie zonder mens opnieuw kan worden aangeboden. De padklok is van elke NAT of firewall tussen client en gateway, en die laat de mappings verlopen voor stromen die hij als afgelopen beschouwt. Alle drie veroorzaken een verbreking, en geen ervan levert dezelfde logregel op.

Alleen de eerste is een VPN-begrip. De andere twee komen uit identiteit en netwerk, en ze worden er routinematig mee verward.

Hoe het token werkelijk wordt hergebruikt

OpenVPN-servers kunnen na de eerste aanmelding een authenticatietoken uitgeven, zodat een heronderhandeling van het controlekanal de gebruiker niet opnieuw om referenties vraagt. De client blijft dat token aanbieden en de server bepaalt hoe lang het aanvaardbaar blijft. Als de levensduur van het token korter is dan het heronderhandelingsinterval, mislukt de volgende heronderhandeling en meldt de client een authenticatiefout in plaats van een time-out. Daarom werkt hetzelfde profiel een uur lang en faalt het daarna op een vast punt.

Het heronderhandelingsinterval is een aparte instelling. Het wijzigen ervan verschuift wanneer het token wordt aangeboden, niet hoe lang het leeft.

Hoe elk verlopen er vanaf de client uitziet

Een sessietimeout komt meestal als een schone verbreking met een reden van de serverzijde, vaak na een voorspelbare duur en zonder enige authenticatiefout. Een inactiviteitstimeout ziet eruit als stilte: de tunnel draagt geen verkeer meer, dan geeft de keepalive het op. Een tokenverloop komt als AUTH_FAILED midden in een sessie die een seconde eerder nog werkte.

Lees de regel en kijk dan naar de klok. Een duur die bij een ingestelde waarde past, is geen toeval.

Waarom een opgeslagen wachtwoord niet helpt

Een gecached wachtwoord beantwoordt een uitdaging voor een wachtwoord. Het verlengt geen tokenlevensduur en het voldoet niet aan een uitdaging voor een tweede factor of een apparaatstatuscontrole. Vaker opnieuw proberen, kortere verbindingstimeouts of het profiel opnieuw importeren verandert niets aan hoe lang het identiteitssysteem de referentie accepteert.

De duurzame oplossingen zijn de juiste levensduur op het juiste object, of een clientstroom die de vereiste uitdaging zonder mens kan voltooien.

Wat te documenteren en te testen

Schrijf alle drie de waarden op: de sessie- en inactiviteitslimieten van de gateway, de levensduur van het token en de kortste relevante mappingstimeout op het pad. Test daarna elk verlopen bewust door één waarde te verkorten, te kijken wat de client meldt en die waarde te herstellen. Bevestig wat de gebruiker bij elke grens moet doen, want elk uur een volledige aanmelding eisen is een beleidsbeslissing die iemand bewust had moeten nemen.

Een verbreking die helemaal zonder authenticatiegebeurtenis komt, hoort bij het pad of bij de inactiviteitstimer, en dat is een ander onderzoek met ander bewijs.