Un entorno de ejecución VPN en RAM no dice nada sobre los registros

Un servidor VPN arrancado desde una imagen de solo lectura con su estado de ejecución en tmpfs es un diseño real y útil. También es fácil describirlo como sin registros, cosa que el diseño no demuestra. La ubicación del almacenamiento determina dónde vive una copia; la recolección y la retención determinan si existe un registro, y un reinicio solo afecta a la primera. Separar ambas cosas es toda la revisión.

Empiece por enumerar cada proceso que pueda escribir estado: el demonio, el servicio de autenticación, el journal, cualquier agente de monitorización y las herramientas de gestión.

Almacenamiento y recolección son preguntas distintas

Cada escritor tiene su propio destino y su propia política. El demonio VPN escribe archivos de estado, el backend de autenticación escribe eventos de cuenta, el journal recoge la salida de los servicios y un agente de monitorización envía métricas a un lugar completamente distinto. Un diseño que hace desaparecer uno de ellos al reiniciar no ha dicho nada sobre los otros tres. Siga cada escritor hasta su destino y anote si ese destino está siquiera en la máquina.

Los archivos específicos de la aplicación, los diagnósticos subidos y los servicios externos necesitan el mismo trato. La ausencia de un registro local conocido no demuestra que no existan registros de conexión o de cuenta en ninguna parte; demuestra que todavía no ha encontrado adónde van.

tmpfs no es una garantía

Linux tmpfs no es un disco RAM físico. La documentación del kernel es explícita en que las páginas pueden escribirse en el swap cuando el montaje lo permite, así que un archivo tmpfs puede llegar a un disco sin que la aplicación lo copie nunca allí. mount muestra si hay un tmpfs respaldado por swap en juego, y otros sistemas de archivos en memoria se comportan de forma distinta. Lea las opciones reales de montaje en lugar de suponer que una ruta bajo /run implica volatilidad.

Después haga inventario de las cosas que sobreviven a un reinicio de formas que la gente olvida: una capa superior persistente, almacenamiento conectado, imágenes de hibernación, volcados de fallos y capturas de infraestructura de toda la VM. Cada una es un destino candidato para estado que usted creía efímero. Esa lista es algo que comprobar, no una afirmación de que todo host las tenga todas.

Journald tiene dos destinos y un reenviador

Journald ilustra bien la división. El almacenamiento volátil guarda entradas en /run/log/journal, el persistente en /var/log/journal, y el modo automático elige entre ambos; el modo vigente proviene del sistema en ejecución, no de la descripción de la imagen. Cambiar a volátil no borra lo que ya se escribió de forma persistente. El reenvío también es un canal aparte: incluso una configuración de almacenamiento que no guarda nada localmente puede entregar mensajes a otro destino.

Lea el modo efectivo del propio journal o de su archivo de configuración y luego compruebe los destinos de reenvío por separado, porque un ajuste no controla el otro.

Qué debe sobrevivir a un reinicio

Un entorno sin estado admite la sustitución repetible, y necesita fuentes deliberadas para la configuración, la autorización y el material de recuperación que el servicio no puede inventar. Perder el único estado de inscripción o revocación que funciona para que las escrituras locales desaparezcan es un mal negocio, y común. Decida qué debe sobrevivir a propósito y luego verifique que lo hace.

El mismo razonamiento se aplica a los registros operativos. Decida qué eventos requieren de verdad la seguridad y la gestión del servicio, con un alcance y una retención justificados, y minimice el resto. Minimizar no es lo mismo que desactivar todos los diagnósticos.

Compare la configuración efectiva de almacenamiento y reenvío con unos cuantos eventos inofensivos, reinicie o sustituya la máquina y vuelva a comprobar qué quedó y de dónde recuperó el servicio su estado.