OpenVPN auth-nocache: què passa al següent inici de sessió

Activeu auth-nocache i l’avís de memòria cau de contrasenya desapareix, juntament amb la còpia de les credencials que OpenVPN guardava per a la propera renegociació. Que això es converteixi en una petició, un reintent silenciós o un túnel tallat depèn d’on vinguin les credencials el segon cop. Per tant, això és una comparació entre formes de desplegament i no un veredicte sobre l’opció. Llegiu la forma que realment executeu abans d’editar qualsevol perfil.

D’on ha de venir el segon conjunt de credencials

OpenVPN aplica auth-nocache als secrets recollits per auth-user-pass i askpass: un cop usats, el procés els descarta en lloc de guardar-los per al proper handshake. La renegociació arriba per temporitzador, un cop per hora per defecte, de manera que la segona petició arriba molt després que la persona que va escriure la contrasenya se n’hagi anat. Aquest buit és tota la història. Amb la memòria cau activada, el client reprodueix la còpia desada sense preguntar ningú; amb la memòria cau desactivada, ha de trobar el secret en un altre lloc o fallar.

Per tant, llisteu tots els llocs d’on podria venir el secret en aquell moment i sigueu honest sobre quins existeixen a l’amfitrió. Una persona davant d’un terminal, un fitxer que auth-user-pass o askpass puguin llegir, o un testimoni de sessió emès pel servidor són els tres que importen aquí. Si cap no està disponible, la renegociació falla una hora després del canvi i no en el moment en què el vau fer.

Tres formes, tres punts de fallada

Un client d’escriptori amb una persona al davant és el cas lleu: la petició torna, algú torna a escriure la contrasenya i el cost és atenció. Un servei, contenidor o encaminador que executa OpenVPN sense terminal és el cas dur, perquè no hi ha ningú per respondre i la reconnexió que abans era silenciosa ara acaba el túnel. Un híbrid se situa entre tots dos i es comporta com el cas d’escriptori fins que desapareix la sessió que podia respondre la petició. El que els separa no és si hi ha una GUI instal·lada, sinó si existeix una font de credencials en el moment de la renegociació.

Assigneu el vostre desplegament a una d’aquestes tres formes abans de canviar res, perquè el consell que trobeu en línia està gairebé sempre escrit per a la primera. Aplicar la resposta d’escriptori a un servei sense terminal és com un túnel que ha funcionat durant mesos comença a caure cada hora.

Directiva o indicador: trieu-ne un i sapigueu quin heu fet servir

Dins d’un perfil, auth-nocache és una línia pròpia; en una invocació que anomena explícitament un perfil, és un indicador en aquesta línia d’ordres, i el manual d’OpenVPN llista les dues formes. Totes dues fan el mateix amb la retenció de credencials i cap no toca el tipus d’interfície ni arregla un avís no relacionat que hi hagi al mateix registre. La diferència és la persistència: l’indicador només cobreix aquella execució, així que un servei reiniciat des d’un fitxer d’unitat o un script embolcall no el tindrà tret que l’embolcall també el passi.

auth-nocache
openvpn --config /path/client.ovpn --auth-nocache

Decidiu quin artefacte posseeix el paràmetre, canvieu-lo allà i enlloc més. Un perfil editat en un portàtil més una unitat systemd que el sobreescriu amb un indicador és la parella que produeix un comportament contradictori després d’un reinici.

Un fitxer de credencials trasllada el secret en lloc d’esborrar-lo

Apuntar auth-user-pass a un fitxer dóna una font a cada renegociació posterior i també posa la contrasenya en un lloc que sobreviu als reinicis. Pregunteu qui pot llegir aquest fitxer, si el dimoni encara el pot llegir després de renunciar als privilegis i què passa quan el sistema de fitxers es munta només de lectura o una vista de contenidor amaga el camí. Un secret al disc i un secret en memòria són problemes diferents, i resoldre’n un deixa l’altre al seu lloc. La rotació és el pas que es descuida: una contrasenya canviada al servidor però no al fitxer produeix una fallada que es llegeix com un error de xarxa.

Manteniu el fitxer en propietat del compte que executa el dimoni, llegible per ningú més i fora de les còpies de seguretat que surten de l’amfitrió. L’opció auth-gen-token del costat servidor d’OpenVPN dóna al client un testimoni de sessió després d’un inici de sessió correcte, que és una cosa més petita per deixar abandonada que la contrasenya del compte. Escriviu el pas de rotació al costat del fitxer en qualsevol cas, perquè el fitxer normalment sobreviu a la persona que el va crear.

Allargar la renegociació mou el cost, no l’elimina

L’altra suggerència és apujar reneg-sec fins que la petició sigui prou rara per ignorar-la. Això reescriu el calendari de rotació de claus de la sessió i empeny el mateix problema de credencials a un moment posterior i menys previsible; no crea cap font de credencials. Una política que renova claus segons un calendari per algun motiu no s’hauria de relaxar només per evitar escriure una contrasenya.

Proveu la reconnexió i no la sessió en què esteu asseguts, perquè la sessió viva no demostra res. Deixeu caure el túnel des del costat del servidor, o reinicieu el servei del client, i observeu què fa la propera renegociació sense ningú al teclat. Si es reconnecta, anomeneu el mecanisme que va proporcionar el secret; si no, heu trobat el cost real de l’opció en aquest amfitrió. Qualsevol dels dos resultats us dóna una resposta que aguanta durant una avaria en lloc d’una que va aguantar durant les proves.

En una flota gestionada, qui posseeix el desplegament hauria de saber anomenar tres coses: d’on vénen les credencials, on es guarden i qui les rota. Si alguna d’aquestes respostes és la persona que va configurar l’amfitrió, l’opció encara no és segura allà.