OpenVPN auth-nocache: qué ocurre en el siguiente inicio de sesión

Active auth-nocache y el aviso de caché de contraseña desaparece, junto con la copia de las credenciales que OpenVPN guardaba para la siguiente renegociación. Que eso se convierta en una petición, un reintento silencioso o un túnel caído depende de dónde vengan las credenciales la segunda vez. Eso convierte esto en una comparación entre formas de despliegue y no en un veredicto sobre la opción. Lea la forma que realmente ejecuta antes de editar cualquier perfil.

De dónde tiene que venir el segundo conjunto de credenciales

OpenVPN aplica auth-nocache a los secretos que recogen auth-user-pass y askpass: una vez usados, el proceso los descarta en lugar de guardarlos para el siguiente handshake. La renegociación llega por temporizador, una vez por hora por defecto, así que la segunda petición llega mucho después de que la persona que escribió la contraseña se haya ido. Ese hueco es toda la historia. Con la caché activada, el cliente reproduce la copia guardada sin preguntar a nadie; con la caché desactivada, tiene que encontrar el secreto en otro sitio o fallar.

Así que enumere todos los lugares de los que podría venir el secreto en ese momento y sea honesto sobre cuáles existen en el host. Una persona en un terminal, un archivo que auth-user-pass o askpass puedan leer, o un token de sesión emitido por el servidor son los tres que importan aquí. Si ninguno está disponible, la renegociación falla una hora después del cambio y no en el momento en que lo hizo.

Tres formas, tres puntos de fallo

Un cliente de escritorio con una persona delante es el caso leve: la petición vuelve, alguien escribe la contraseña otra vez y el coste es atención. Un servicio, contenedor o router que ejecuta OpenVPN sin terminal es el caso duro, porque no hay nadie para responder y la reconexión que antes era silenciosa ahora termina el túnel. Un híbrido se sitúa entre ambos y se comporta como el caso de escritorio hasta que desaparece la sesión que podía responder a la petición. Lo que los separa no es si hay una GUI instalada, sino si existe una fuente de credenciales en el momento de la renegociación.

Asigne su despliegue a una de esas tres formas antes de cambiar nada, porque el consejo que encuentre en línea casi siempre está escrito para la primera. Aplicar la respuesta de escritorio a un servicio sin terminal es como un túnel que funcionó durante meses empieza a caer cada hora.

Directiva o indicador: elija uno y sepa cuál usó

Dentro de un perfil, auth-nocache es una línea propia; en una invocación que nombra un perfil explícitamente, es un indicador en esa línea de comandos, y el manual de OpenVPN enumera ambas formas. Ambas hacen lo mismo con la retención de credenciales y ninguna toca el tipo de interfaz ni repara un aviso no relacionado en el mismo registro. La diferencia es la persistencia: el indicador solo cubre esa ejecución, así que un servicio reiniciado desde un archivo unit o un script envoltorio no lo tendrá salvo que el envoltorio también lo pase.

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

Decida qué artefacto posee el ajuste, cámbielo allí y en ningún otro sitio. Un perfil editado en un portátil más una unit de systemd que lo anula con un indicador es la pareja que produce un comportamiento contradictorio tras un reinicio.

Un archivo de credenciales traslada el secreto en lugar de borrarlo

Apuntar auth-user-pass a un archivo da una fuente a cada renegociación posterior y además pone la contraseña en un sitio que sobrevive a los reinicios. Pregunte quién puede leer ese archivo, si el demonio aún puede leerlo tras renunciar a privilegios y qué pasa cuando el sistema de archivos se monta en solo lectura o una vista de contenedor oculta la ruta. Un secreto en disco y un secreto en memoria son problemas distintos, y resolver uno deja el otro en su sitio. La rotación es el paso que se omite: una contraseña cambiada en el servidor pero no en el archivo produce un fallo que se lee como un error de red.

Mantenga el archivo en propiedad de la cuenta que ejecuta el demonio, legible por nadie más y fuera de las copias de seguridad que salen del host. La opción auth-gen-token del lado servidor de OpenVPN entrega al cliente un token de sesión tras un inicio de sesión correcto, que es algo más pequeño que dejar tirado que la contraseña de la cuenta. Escriba el paso de rotación junto al archivo de todos modos, porque el archivo suele sobrevivir a la persona que lo creó.

Estirar la renegociación mueve el coste, no lo elimina

La otra sugerencia es subir reneg-sec hasta que la petición sea lo bastante rara como para ignorarla. Eso reescribe el calendario de rotación de claves de la sesión y empuja el mismo problema de credenciales a un momento posterior y menos predecible; no crea una fuente de credenciales. Una política que renueva claves según un calendario por algún motivo no debería relajarse solo para evitar escribir una contraseña.

Pruebe la reconexión en lugar de la sesión en la que está sentado, porque la sesión viva no demuestra nada. Deje caer el túnel desde el lado del servidor, o reinicie el servicio del cliente, y observe qué hace la siguiente renegociación sin nadie al teclado. Si se reconecta, nombre el mecanismo que proporcionó el secreto; si no, ha encontrado el coste real de la opción en este host. Cualquiera de los dos resultados le da una respuesta que aguanta durante una avería en lugar de una que aguantó durante las pruebas.

En una flota gestionada, quien posee el despliegue debería saber nombrar tres cosas: de dónde vienen las credenciales, dónde se guardan y quién las rota. Si alguna de esas respuestas es la persona que configuró el host, la opción aún no es segura allí.