VPN-øktstimeren og autentiseringstokenet utløper hver for seg

Et VPN-brudd kan skje av grunner som ser identiske ut fra klienten og ikke har noe felles under overflaten: økten i tunnelen ble avsluttet, en inaktivitets timer slo til, eller et bevis klienten brukte på nytt ble utdatert. Hver har en annen eier og en annen retting. Nettopp feilsekvensen i øyeblikket bruddet skjer, er det som skiller dem, og den er som regel én linje.

Tre klokker går mot én tunnel, og bare én av dem er tunnelen.

Tre forskjellige klokker på én tunnel

Øktsklokken tilhører gatewayen: en maksimal tilkoblingsvarighet, en inaktivitets timeout eller begge, og den avslutter tunnelen når en av dem nås. Tokenklokken tilhører autentiseringssystemet, og den avgjør hvor lenge et bevis kan legges fram igjen uten et menneske. Baneklokken tilhører enhver NAT eller brannmur mellom klient og gateway, og den lar mappingene utløpe for strømmer den anser som avsluttet. Alle tre gir en frakobling, og ingen av dem gir samme logglinje.

Bare den første er et VPN-begrep. De to andre er lånt fra identitet og nettverk, og de forveksles rutinemessig med det.

Hvordan tokenet faktisk gjenbrukes

OpenVPN-servere kan utstede et autentiseringstoken etter den første innloggingen, slik at en ny forhandling av kontrollkanalen ikke ber brukeren om bevis igjen. Klienten fortsetter å legge fram tokenet, og serveren avgjør hvor lenge det forblir akseptabelt. Når tokenets levetid er kortere enn nyforhandlingsintervallet, mislykkes den neste nyforhandlingen, og klienten rapporterer en autentiseringsfeil i stedet for en timeout. Derfor virker samme profil i en time og feiler deretter på et fast punkt.

Nyforhandlingsintervallet er en egen innstilling. Å endre det flytter når tokenet legges fram, ikke hvor lenge det lever.

Hvordan hver utløp ser ut fra klienten

En øktstimeout kommer vanligvis som en ren frakobling med en grunn fra serversiden, ofte etter en forutsigbar varighet og uten noen autentiseringsfeil. En inaktivitets timeout ser ut som stillhet: tunnelen slutter å bære trafikk, og så gir keepalive opp. Et tokenutløp kommer som AUTH_FAILED midt i en økt som virket et sekund tidligere.

Les linjen, og se så på klokken. En varighet som passer med en konfigurert verdi er ikke en tilfeldighet.

Hvorfor et lagret passord ikke hjelper

Et bufret passord besvarer en utfordring for et passord. Det forlenger ikke et tokens levetid, og det oppfyller ikke en utfordring for en annen faktor eller en kontroll av enhetens tilstand. Hyppigere nye forsøk, kortere tilkoblingstimeouts eller ny import av profilen endrer ingenting på hvor lenge identitetssystemet godtar beviset.

De varige rettelsene er riktig levetid på riktig objekt, eller en klientflyt som kan fullføre den påkrevde utfordringen uten et menneske.

Hva som skal dokumenteres og testes

Skriv ned alle tre verdiene: gatewayens økts- og inaktivitetsgrenser, tokenets levetid og den korteste relevante mappingstimeouten på banen. Test deretter hvert utløp bevisst ved å forkorte én verdi, se hva klienten rapporterer, og gjenopprette den. Bekreft hva brukeren må gjøre ved hver grense, fordi å kreve full innlogging hver time er en policybeslutning noen burde ha tatt med vilje.

Et brudd som kommer helt uten noen autentiseringshendelse, tilhører banen eller inaktivitets timeren, og det er en annen undersøkelse med andre bevis.