OpenVPN auth-nocache: que pasa no seguinte inicio de sesión

Active auth-nocache e o aviso de caché de contrasinal desaparece, xunto coa copia das credenciais que OpenVPN gardaba para a seguinte renegociación. Que isto se converta nunha petición, nun reintento silencioso ou nun túnel caído depende de onde veñan as credenciais a segunda vez. Iso fai que isto sexa unha comparación entre formas de despregamento e non un veredicto sobre a opción. Lea a forma que realmente executa antes de editar calquera perfil.

De onde ten que vir o segundo conxunto de credenciais

OpenVPN aplica auth-nocache aos segredos que recollen auth-user-pass e askpass: unha vez usados, o proceso descártaos en lugar de gardalos para o seguinte handshake. A renegociación chega por temporizador, unha vez por hora por defecto, así que a segunda petición chega moito despois de que a persoa que escribiu o contrasinal se fora. Ese oco é toda a historia. Coa caché activada, o cliente reproduce a copia gardada sen preguntar a ninguén; coa caché desactivada, ten que atopar o segredo noutro sitio ou fallar.

Así que enumere todos os lugares de onde podería vir o segredo nese momento e sexa honesto sobre cales existen no host. Unha persoa nun terminal, un ficheiro que auth-user-pass ou askpass poidan ler, ou un token de sesión emitido polo servidor son os tres que importan aquí. Se ningún está dispoñible, a renegociación falla unha hora despois do cambio e non no momento en que o fixo.

Tres formas, tres puntos de fallo

Un cliente de escritorio cunha persoa diante é o caso leve: a petición volve, alguén escribe o contrasinal outra vez e o custo é atención. Un servizo, contedor ou router que executa OpenVPN sen terminal é o caso duro, porque non hai ninguén para responder e a reconexión que antes era silenciosa agora remata o túnel. Un híbrido sitúase entre ambos e compórtase como o caso de escritorio ata que desaparece a sesión que podía responder á petición. O que os separa non é se hai unha GUI instalada, senón se existe unha fonte de credenciais no momento da renegociación.

Asigne o seu despregamento a unha desas tres formas antes de cambiar nada, porque o consello que atope en liña case sempre está escrito para a primeira. Aplicar a resposta de escritorio a un servizo sen terminal é como un túnel que funcionou durante meses comeza a caer cada hora.

Directiva ou indicador: escolla un e saiba cal usou

Dentro dun perfil, auth-nocache é unha liña propia; nunha invocación que nomea un perfil explicitamente, é un indicador nesa liña de comandos, e o manual de OpenVPN enumera ambas formas. Ambas fan o mesmo coa retención de credenciais e ningunha toca o tipo de interface nin repara un aviso non relacionado no mesmo rexistro. A diferenza é a persistencia: o indicador só cobre esa execución, así que un servizo reiniciado desde un ficheiro unit ou un script envoltorio non o terá salvo que o envoltorio tamén o pase.

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

Decida que artefacto posúe o axuste, cámbieo alí e en ningún outro sitio. Un perfil editado nun portátil máis unha unit de systemd que o anula cun indicador é a parella que produce un comportamento contradictorio tras un reinicio.

Un ficheiro de credenciais traslada o segredo en lugar de borralo

Apuntar auth-user-pass a un ficheiro dá unha fonte a cada renegociación posterior e ademais pon o contrasinal nun sitio que sobrevive aos reinicios. Pregunte quen pode ler ese ficheiro, se o demonio aínda pode lelo tras renunciar a privilexios e que pasa cando o sistema de ficheiros se monta en só lectura ou unha vista de contedor oculta a ruta. Un segredo no disco e un segredo en memoria son problemas distintos, e resolver un deixa o outro no seu sitio. A rotación é o paso que se omite: un contrasinal cambiado no servidor pero non no ficheiro produce un fallo que se le como un erro de rede.

Manteña o ficheiro en propiedade da conta que executa o demonio, lexible por ninguén máis e fóra das copias de seguridade que saen do host. A opción auth-gen-token do lado servidor de OpenVPN entrega ao cliente un token de sesión tras un inicio de sesión correcto, que é algo máis pequeno que deixar tirado que o contrasinal da conta. Escriba o paso de rotación xunto ao ficheiro de todos os xeitos, porque o ficheiro adoita sobrevivir á persoa que o creou.

Estirar a renegociación move o custo, non o elimina

A outra suxestión é subir reneg-sec ata que a petición sexa o bastante rara como para ignoralo. Iso reescribe o calendario de rotación de claves da sesión e empurra o mesmo problema de credenciais a un momento posterior e menos predicible; non crea unha fonte de credenciais. Unha política que renova claves segundo un calendario por algún motivo non debería relaxarse só para evitar escribir un contrasinal.

Probe a reconexión en lugar da sesión na que está sentado, porque a sesión viva non demostra nada. Deixe caer o túnel desde o lado do servidor, ou reinicie o servizo do cliente, e observe que fai a seguinte renegociación sen ninguén ao teclado. Se se reconecta, nomee o mecanismo que proporcionou o segredo; se non, atopou o custo real da opción neste host. Calquera dos dous resultados dáselle unha resposta que aguanta durante unha avaría en lugar dunha que aguantou durante as probas.

Nunha flota xestionada, quen posúe o despregamento debería saber nomear tres cousas: de onde veñen as credenciais, onde se gardan e quen as rota. Se algunha desas respostas é a persoa que configurou o host, a opción aínda non é segura alí.