Unha contorna de execución VPN na RAM non di nada sobre os rexistros

Un servidor VPN arrincado desde unha imaxe de só lectura co seu estado de execución en tmpfs é un deseño real e útil. Tamén é fácil de describir como sen rexistros, o que o deseño non demostra. A localización do almacenamento determina onde vive unha copia; a recollida e a retención determinan se existe un rexistro, e un reinicio só afecta a primeira. Separar as dúas cousas é toda a revisión.

Comezade enumerando cada proceso que poida escribir estado: o daemon, o servizo de autenticación, o rexistro, calquera axente de monitorización e as ferramentas de xestión.

Almacenamento e recollida son preguntas distintas

Cada escritor ten o seu propio destino e a súa propia política. O daemon VPN escribe ficheiros de estado, o backend de autenticación escribe eventos de conta, o rexistro recolle a saída dos servizos e un axente de monitorización envía métricas a un lugar completamente distinto. Un deseño que fai desaparecer un deles ao reiniciar non dixo nada sobre os outros tres. Seguide cada escritor ata o seu destino e anotade se ese destino está sequera na máquina.

Os ficheiros específicos da aplicación, os diagnósticos subidos e os servizos externos necesitan o mesmo trato. A ausencia dun rexistro local coñecido non demostra que non existan rexistros de conexión ou de conta en ningures; demostra que aínda non atopastes onde van.

tmpfs non é unha garantía

Linux tmpfs non é un disco RAM físico. A documentación do núcleo é explícita en que as páxinas poden escribirse no swap cando a montaxe o permite, así que un ficheiro tmpfs pode chegar a un disco sen que a aplicación o copie nunca alí. mount mostra se hai un tmpfs apoiado en swap en xogo, e outros sistemas de ficheiros en memoria compórtanse doutro xeito. Lede as opcións reais de montaxe en lugar de supoñer que unha ruta baixo /run implica volatilidade.

Despois facede inventario das cousas que sobreviven a un reinicio de maneiras que a xente esquece: unha capa superior persistente, almacenamento conectado, imaxes de hibernación, volcados de fallos e instantáneas de infraestrutura de toda a VM. Cada unha é un destino candidato para estado que creades efémero. Esa lista é algo que comprobar, non unha afirmación de que cada host as teña todas.

Journald ten dous destinos e un reenviador

Journald ilustra ben a división. O almacenamento volátil garda entradas en /run/log/journal, o persistente en /var/log/journal, e o modo automático escolle entre ambos; o modo vixente provén do sistema en execución, non da descrición da imaxe. Cambiar a volátil non borra o que xa se escribiu de forma persistente. O reenvío tamén é unha canle aparte: mesmo unha configuración de almacenamento que non garda nada localmente pode entregar mensaxes a outro destino.

Lede o modo efectivo do propio rexistro ou do seu ficheiro de configuración e despois comprobade os destinos de reenvío por separado, porque un axuste non controla o outro.

Que debe sobrevivir a un reinicio

Unha contorna sen estado admite a substitución repetible, e necesita fontes deliberadas para a configuración, a autorización e o material de recuperación que o servizo non pode inventar. Perder o único estado de inscrición ou revocación que funciona para que as escrituras locais desaparezan é un mal negocio, e habitual. Decidide que debe sobrevivir a propósito e despois verificade que o fai.

O mesmo razoamento aplícase aos rexistros operativos. Decidide que eventos requiren de verdade a seguridade e a xestión do servizo, cun alcance e unha retención xustificados, e minimizade o resto. Minimizar non é o mesmo que desactivar todos os diagnósticos.

Comparade a configuración efectiva de almacenamento e reenvío con algúns eventos inofensivos, reiniciade ou substituíde a máquina e volvede comprobar que quedou e de onde recuperou o servizo o seu estado.