El temporitzador de la sessió VPN i el token d'autenticació caduquen per separat

Una caiguda de la VPN pot passar per motius que des del client semblen idèntics i que no comparteixen res per sota: la sessió del túnel s'ha acabat, ha saltat un temporitzador d'inactivitat o una credencial que el client reutilitzava s'ha quedat obsoleta. Cadascun té un propietari diferent i una solució diferent. La seqüència d'errors en el moment de la caiguda és el que els separa, i normalment és una sola línia.

Tres rellotges corren contra un sol túnel, i només un d'ells és el túnel.

Tres rellotges diferents en un sol túnel

El rellotge de la sessió pertany al passarel·la: una durada màxima de connexió, un temps d'espera d'inactivitat o tots dos, i tanca el túnel quan s'assoleix qualsevol dels dos. El rellotge del token pertany al sistema d'autenticació i decideix quant de temps es pot tornar a presentar una credencial sense cap persona. El rellotge del camí pertany al NAT o tallafoc que hi hagi entre el client i el passarel·la, i fa caducar les assignacions dels fluxos que considera acabats. Tots tres produeixen una desconnexió, i cap d'ells produeix la mateixa línia de registre.

Només el primer és un concepte de la VPN. Els altres dos es prenen de la identitat i de les xarxes, i sovint es confonen amb ell.

Com es reutilitza realment el token

Els servidors OpenVPN poden emetre un token d'autenticació després de l'inici de sessió inicial, de manera que una renegociació del canal de control no torna a demanar credencials a l'usuari. El client continua presentant aquest token i el servidor decideix quant de temps segueix sent acceptable. Quan la vida del token és més curta que l'interval de renegociació, la renegociació següent falla i el client informa d'un error d'autenticació en lloc d'un temps d'espera. Per això el mateix perfil funciona durant una hora i després falla en un punt fix.

L'interval de renegociació és un paràmetre a part. Canviar-lo mou quan es presenta el token, no quant de temps viu.

Com es veu cada caducitat des del client

Un temps d'espera de sessió normalment arriba com una desconnexió neta amb un motiu del servidor, sovint després d'una durada previsible i sense cap error d'autenticació adjunt. Un temps d'espera d'inactivitat sembla silenci: el túnel deixa de portar trànsit i llavors el keepalive es rendeix. Una caducitat de token arriba com AUTH_FAILED al mig d'una sessió que funcionava un segon abans.

Llegiu la línia i després mireu el rellotge. Una durada que coincideix amb un valor configurat no és casualitat.

Per què una contrasenya desada no ajuda

Una contrasenya en memòria cau respon a un repte per una contrasenya. No allarga la vida d'un token ni satisfà un repte per un segon factor o una comprovació de l'estat del dispositiu. Augmentar la freqüència de reintents, reduir els temps d'espera de connexió o tornar a importar el perfil no canvia res sobre quant de temps el sistema d'identitat acceptarà la credencial.

Les solucions duradores són la vida correcta sobre l'objecte correcte, o un flux de client que pugui completar el repte necessari sense cap persona.

Què cal documentar i provar

Anoteu els tres valors: els límits de sessió i d'inactivitat del passarel·la, la vida del token i el temps d'espera d'assignació rellevant més curt del camí. Després proveu cada caducitat a propòsit escurçant un valor, observant què informa el client i restaurant-lo. Confirmeu què ha de fer l'usuari a cada frontera, perquè exigir un inici de sessió complet cada hora és una decisió de política que algú hauria d'haver pres a propòsit.

Una caiguda que arriba sense cap esdeveniment d'autenticació pertany al camí o al temporitzador d'inactivitat, que és una investigació diferent amb proves diferents.