OpenVPN deixa caure una sessió OTP més tard: què necessita la reautenticació

Des del costat del client sembla una desconnexió aleatòria al cap d'una hora d'una sessió que funciona. La icona de la safata desapareix, el túnel es reconstrueix i el registre mostra un error d'autenticació en lloc d'un error de xarxa. El que va passar realment és que la sessió va renegociar i la segona negociació necessitava credencials de les quals el client ja no tenia una còpia vàlida. Un codi d'un sol ús que va funcionar en iniciar sessió no pot funcionar una altra vegada, així que la renovació de clau falla exactament tal com estava dissenyada.

La solució és una decisió sobre què ha de presentar la segona negociació, no un temporitzador de reintent més llarg.

Seguiu l'intercanvi des del punt de vista del client

En iniciar sessió, el client envia el nom d'usuari, la contrasenya i un codi del dispositiu de testimoni, i el servidor accepta la combinació. Després la sessió funciona fins que s'activa un disparador de renegociació, que inicia una negociació TLS nova dins del túnel existent. Aquesta negociació torna a demanar autenticació. Si el camí d'autenticació del servidor espera una contrasenya més un codi d'un sol ús vigent, el client no té cap codi nou per oferir tret que l'usuari sigui present per escriure'l.

La majoria de clients no obren cap sol·licitud a mig camí de la sessió, així que la negociació caduca i el túnel cau. L'usuari veu una reconnexió, no una sol·licitud d'autenticació, i per això el primer informe sol culpar la xarxa.

auth-gen-token canvia qui respon la segona pregunta

auth-gen-token és l'opció que permet al servidor emetre un testimoni després d'una sessió iniciada correctament, i les renegociacions posteriors presenten aquest testimoni en lloc de repetir la contrasenya i el codi. El manual documenta la seva vida útil i el seu comportament de renovació, i el testimoni s'ha de tractar com una credencial amb la seva pròpia caducitat. En el camí per defecte, el servidor valida el testimoni ell mateix en lloc de tornar a cridar l'autenticador de contrasenya extern.

Amb una integració d'autenticació externa, aquesta divisió canvia. El connector ha d'entendre l'estat del testimoni i aplicar les seves pròpies comprovacions, perquè el servidor ja no és l'únic component que decideix si la sessió continua. Tractar el testimoni com un altre codi numèric d'un sol ús no és una implementació de la funció.

Decidiu què passa amb l'estat del compte

Un testimoni que sobreviu a l'accés d'un compte és un forat de política. Decidiu com un compte desactivat, una pertinença a grup eliminada o un dispositiu revocat entren en vigor mentre el testimoni encara és vàlid. Vides útils curtes del testimoni fan la finestra més petita; un camí de revocació explícit la fa intencionada. Escriviu la resposta abans d'activar l'opció, perquè el camí per defecte no consulta l'autenticador extern a cada renegociació.

En un desplegament amb diversos servidors, el secret de signatura dels testimonis ha de ser compartit, o el client pot ser enviat a un node que no pot validar el seu testimoni.

Proveu la caducitat i la reconnexió, no només l'inici de sessió

Baixeu l'interval de renegociació en un perfil de prova perquè la segona negociació passi mentre mireu, i després seguiu tots dos registres. Confirmeu que el testimoni s'emet en iniciar sessió, es presenta en renovar la clau i es refresca o es torna a emetre segons la vida útil configurada. Després forceu una caducitat del testimoni i una reconnexió completa, perquè un client que es reconnecta net pot fallar igualment en el camí de renovació de clau.

Proveu l'eliminació del compte al final. Aquest cas us diu si la política que heu escrit s'aplica o només està documentada.

No ho arregleu desactivant la renovació

Posar l'interval de renegociació a zero en tots dos extrems elimina el símptoma i la rotació de claus amb ell. Això amaga un problema de reutilització de credencials darrere d'un canvi de política que ningú no ha revisat. Manteniu la renovació i trieu entre un testimoni emès pel servidor i un repte interactiu nou segons si hi ha un usuari present.

Un temporitzador de reintent més llarg no fa que un codi gastat torni a ser vàlid. Només endarrereix la desconnexió i fa el registre més difícil de llegir.