De VPN-sesjetimer en it autentikaasjetoken ferrinne apart

In VPN-ferbining kin ôfbrekke om redenen dy't fan de klant ôf itselde lykje en ûnder de oerflakte neat mienskiplik hawwe: de tunnelsesje einige, in idle-timer sprong oan, of in bewiis dat de klant werbrûkte waard ferâldere. Elk hat in oare eigner en in oare oplossing. Krekt de floutsekwinsje op it momint fan de ôfbrek is wat se skiedt, en dy is meastentiids ien rigel.

Trije klokken rinne tsjin ien tunnel, en mar ien fan har is de tunnel.

Trije ferskillende klokken op ien tunnel

De sesjeklok heart by de gateway: in maksimale ferbiningsdoer, in idle-timeout of beide, en dy beëiniget de tunnel as ien fan beide berikt wurdt. De tokenklok heart by it autentikaasjesysteem, en dy beslút hoe lang in bewiis sûnder minske wer oanbean wurde kin. De paadklok heart by hokker NAT of firewall dan ek tusken klant en gateway sit, en dy lit de mappings ferrinne foar streamen dy't er as ôfrûn beskôget. Alle trije jouwe in ôfbrek, en net ien fan har jout deselde logrigel.

Allinnich de earste is in VPN-begryp. De oare twa binne liend út identiteit en netwurk, en se wurde der geregeld mei betize.

Hoe't it token eins werbrûkt wurdt

OpenVPN-tsjinners kinne nei de earste oanmelding in autentikaasjetoken útjaan, sadat in werûnderhanneling fan it kontrôlekanaal de brûker net wer om bewiis freget. De klant bliuwt dat token oanbieden en de tsjinner beslút hoe lang it akseptabel bliuwt. As de libbensdoer fan it token koarter is as it werûnderhannelingsinterval, mislearret de folgjende werûnderhanneling en de klant rapportearret in autentikaasjeflater yn plak fan in timeout. Dêrom wurket itselde profyl in oere en mislearret it dan op in fêst punt.

It werûnderhannelingsinterval is in aparte ynstelling. It feroarjen dêrfan ferskoot wannear't it token oanbean wurdt, net hoe lang it libbet.

Hoe't elke ferrin der fan de klant ôf útsjocht

In sesje-timeout komt meastentiids as in skjinne ôfbrek mei in reden fan 'e tsjinner, faak nei in foarsisbere doer en sûnder autentikaasjeflater. In idle-timeout liket op stilte: de tunnel hâldt op mei ferkear te dragen, dan jout de keepalive it op. In tokenferrin komt as AUTH_FAILED midden yn in sesje dy't in sekonde earder noch wurke.

Lês de rigel, en sjoch dan op 'e klok. In doer dy't by in ynstelde wearde past, is gjin tafal.

Wêrom't in bewarre wachtwurd net helpt

In cachet wachtwurd beantwurdet in útdaging foar in wachtwurd. It ferlingt gjin tokenlibben en it foldocht net oan in útdaging foar in twadde faktor of in kontrôle fan 'e tastân fan it apparaat. Faker op 'e nij besykje, koartere ferbiningstimeouts of it profyl op 'e nij ymportearje feroaret neat oan hoe lang it identiteitssysteem it bewiis akseptearret.

De duorsume oplossings binne it juste libben op it juste objekt, of in klantstream dy't de fereaske útdaging sûnder minske ôfmeitsje kin.

Wat te dokumintearjen en te testen

Skriuw alle trije wearden op: de sesje- en idle-limiten fan de gateway, it libben fan it token en de koartste relevante mappingstimeout op it paad. Test dan elke ferrin bewust troch ien wearde te ferkoartsjen, te sjen wat de klant rapportearret, en dy te werstellen. Befêstigje wat de brûker by elke grins dwaan moat, want in folsleine oanmelding elke oere easkje is in beliedsbeslissing dy't immen bewust nimme moatten hie.

In ôfbrek dy't hielendal sûnder autentikaasjebarring komt, heart by it paad of de idle-timer, en dat is in oar ûndersyk mei oar bewiis.