VPN-sessionens timer och autentiseringstokenet löper ut var för sig

Ett VPN-avbrott kan inträffa av skäl som ser identiska ut från klienten och inte har något gemensamt under ytan: tunnelsessionen tog slut, en inaktivitetstimer slog till, eller ett bevis som klienten återanvände blev inaktuellt. Var och en har en annan ägare och en annan åtgärd. Det är just felsekvensen i ögonblicket för avbrottet som skiljer dem, och den är oftast en enda rad.

Tre klockor går mot en enda tunnel, och bara en av dem är tunneln.

Tre olika klockor på en enda tunnel

Sessionsklockan tillhör gatewayen: en maximal anslutningstid, en inaktivitets-timeout eller båda, och den avslutar tunneln när någon av dem nås. Tokenklockan tillhör autentiseringssystemet, och den avgör hur länge ett bevis kan läggas fram igen utan en människa. Vägklockan tillhör vilken NAT eller brandvägg som helst mellan klient och gateway, och den låter mappningarna löpa ut för flöden som den anser avslutade. Alla tre ger en frånkoppling, och ingen av dem ger samma loggrada.

Bara den första är ett VPN-begrepp. De andra två är lånade från identitet och nätverk, och de förväxlas rutinmässigt med det.

Hur tokenet faktiskt återanvänds

OpenVPN-servrar kan utfärda ett autentiseringstoken efter den första inloggningen, så att en ny förhandling av kontrollkanalen inte ber användaren om bevis igen. Klienten fortsätter att lägga fram tokenet, och servern avgör hur länge det förblir godtagbart. När tokenets livslängd är kortare än intervallet för ny förhandling misslyckas nästa förhandling, och klienten rapporterar ett autentiseringsfel i stället för en timeout. Därför fungerar samma profil i en timme och misslyckas sedan vid en fast punkt.

Intervallet för ny förhandling är en egen inställning. Att ändra det flyttar när tokenet läggs fram, inte hur länge det lever.

Hur varje utgång ser ut från klienten

En sessionstimeout kommer vanligtvis som en ren frånkoppling med ett skäl från serversidan, ofta efter en förutsägbar tid och utan något autentiseringsfel. En inaktivitets-timeout ser ut som tystnad: tunneln slutar bära trafik, sedan ger keepalive upp. En tokenutgång kommer som AUTH_FAILED mitt i en session som fungerade en sekund tidigare.

Läs raden och titta sedan på klockan. En varaktighet som stämmer med ett konfigurerat värde är ingen slump.

Varför ett sparat lösenord inte hjälper

Ett cachelagrat lösenord besvarar en utmaning för ett lösenord. Det förlänger inte ett tokens livslängd och det uppfyller inte en utmaning för en andra faktor eller en kontroll av enhetens tillstånd. Tätare nya försök, kortare anslutningstimeouts eller ny import av profilen ändrar ingenting i hur länge identitetssystemet godtar beviset.

De hållbara åtgärderna är rätt livslängd på rätt objekt, eller ett klientflöde som kan slutföra den krävda utmaningen utan en människa.

Vad som ska dokumenteras och testas

Skriv ner alla tre värdena: gatewayens sessions- och inaktivitetsgränser, tokenets livslängd och den kortaste relevanta mappningstimeouten på vägen. Testa sedan varje utgång medvetet genom att förkorta ett värde, se vad klienten rapporterar och återställa det. Bekräfta vad användaren måste göra vid varje gräns, eftersom att kräva full inloggning varje timme är ett policybeslut som någon borde ha fattat medvetet.

Ett avbrott som kommer helt utan någon autentiseringshändelse tillhör vägen eller inaktivitetstimern, och det är en annan utredning med andra bevis.