Um runtime VPN em RAM não diz nada sobre registos

Um servidor VPN arrancado de uma imagem só de leitura com o seu estado de execução em tmpfs é um desenho real e útil. Também é fácil descrevê-lo como sem registos, o que o desenho não estabelece. A localização do armazenamento determina onde vive uma cópia; a recolha e a retenção determinam se existe um registo, e um reinício só afeta a primeira. Separar as duas coisas é toda a revisão.

Comece por listar cada processo que possa escrever estado: o daemon, o serviço de autenticação, o journal, qualquer agente de monitorização e as ferramentas de gestão.

Armazenamento e recolha são perguntas diferentes

Cada escritor tem o seu destino e a sua política. O daemon VPN escreve ficheiros de estado, o backend de autenticação escreve eventos de conta, o journal recolhe a saída dos serviços e um agente de monitorização envia métricas para um lugar completamente diferente. Um desenho que faz desaparecer um destes no reinício não disse nada sobre os outros três. Siga cada escritor até ao seu destino e anote se esse destino está sequer na máquina.

Ficheiros específicos da aplicação, diagnósticos carregados e serviços externos precisam do mesmo tratamento. A ausência de um registo local conhecido não prova que não existam registos de ligação ou de conta em lado nenhum; prova que ainda não descobriu para onde vão.

tmpfs não é uma garantia

Linux tmpfs não é um disco RAM físico. A documentação do kernel é explícita ao dizer que as páginas podem ser escritas no swap quando a montagem o permite, pelo que um ficheiro tmpfs pode chegar a um disco sem que a aplicação alguma vez o copie para lá. mount mostra se está em jogo um tmpfs suportado por swap, e outros sistemas de ficheiros em memória comportam-se de forma diferente. Leia as opções de montagem reais em vez de assumir que um caminho sob /run implica volatilidade.

Depois inventarie as coisas que sobrevivem a um reinício de formas que as pessoas esquecem: uma camada superior persistente, armazenamento ligado, imagens de hibernação, dump de falhas e instantâneos de infraestrutura de toda a VM. Cada uma é um destino candidato para estado que julgava efémero. Essa lista é algo a verificar, não a afirmação de que cada host as tem todas.

O Journald tem dois destinos e um reencaminhador

O Journald ilustra bem a divisão. O armazenamento volátil guarda entradas em /run/log/journal, o persistente em /var/log/journal, e o modo automático escolhe entre ambos; o modo em vigor vem do sistema em execução e não da descrição da imagem. Mudar para volátil não apaga o que já foi escrito de forma persistente. O reencaminhamento também é um canal separado: mesmo uma configuração de armazenamento que não guarda nada localmente pode entregar mensagens a outro destino.

Leia o modo efetivo no próprio journal ou no seu ficheiro de configuração e, em seguida, verifique os destinos de reencaminhamento em separado, porque uma definição não controla a outra.

O que tem de sobreviver a um reinício

Um runtime sem estado suporta a substituição repetível e precisa de fontes deliberadas para a configuração, a autorização e o material de recuperação que o serviço não consegue inventar. Perder o único estado de inscrição ou revogação que funciona para fazer desaparecer as escritas locais é um mau negócio, e comum. Decida o que deve sobreviver de propósito e depois verifique que sobrevive.

O mesmo raciocínio aplica-se aos registos operacionais. Decida que eventos a segurança e a gestão do serviço exigem realmente, com um âmbito e uma retenção justificados, e minimize o resto. Minimizar não é o mesmo que desativar todos os diagnósticos.

Compare a configuração efetiva de armazenamento e reencaminhamento com alguns eventos inofensivos, reinicie ou substitua a máquina e verifique de novo o que ficou e de onde o serviço recuperou o seu estado.