Een VPN-runtime in RAM zegt niets over logboeken

Een VPN-server die opstart van een alleen-lezen image en zijn runtime-status op tmpfs houdt, is een echt en nuttig ontwerp. Het is ook gemakkelijk om het als zonder logboeken te beschrijven, wat het ontwerp niet aantoont. De opslaglocatie bepaalt waar een kopie leeft; verzameling en bewaring bepalen of een record überhaupt bestaat, en een herstart beïnvloedt alleen het eerste. Die twee gescheiden houden is de hele beoordeling.

Begin met het opsommen van elk proces dat status kan schrijven: de daemon, de authenticatiedienst, het journaal, elke monitoring-agent en de beheertooling.

Opslag en verzameling zijn verschillende vragen

Elke schrijver heeft zijn eigen bestemming en zijn eigen beleid. De VPN-daemon schrijft statusbestanden, de authenticatie-backend schrijft accountgebeurtenissen, het journaal verzamelt service-uitvoer, en een monitoring-agent stuurt statistieken heel ergens anders heen. Een ontwerp dat één daarvan bij herstart laat verdwijnen, heeft niets over de andere drie gezegd. Volg elke schrijver naar zijn bestemming en noteer of die bestemming überhaupt op de machine staat.

Applicatiespecifieke bestanden, geüploade diagnostiek en externe diensten vragen dezelfde behandeling. Het ontbreken van een bekend lokaal logboek bewijst niet dat verbindings- of accountrecords nergens bestaan; het bewijst dat u nog niet hebt gevonden waar ze heen gaan.

tmpfs is geen garantie

Linux tmpfs is geen fysieke RAM-schijf. De kerneldocumentatie is expliciet dat pagina's naar swap kunnen worden geschreven wanneer de mount dat toestaat, dus een tmpfs-bestand kan een schijf bereiken zonder dat de applicatie het ooit daarheen kopieert. mount toont of een door swap ondersteunde tmpfs in het spel is, en andere geheugenbestandssystemen gedragen zich weer anders. Lees de werkelijke mount-opties in plaats van aan te nemen dat een pad onder /run vluchtigheid betekent.

Inventariseer vervolgens de dingen die een herstart overleven op manieren die mensen vergeten: een persistente bovenlaag, aangesloten opslag, hibernatie-images, crashdumps en infrastructuursnapshots van de hele VM. Elk daarvan is een kandidaatbestemming voor status die u als efemeer beschouwde. Die lijst is iets om te controleren, niet de bewering dat elke host ze allemaal heeft.

Journald heeft twee bestemmingen en een doorstuurder

Journald illustreert de splitsing netjes. Vluchtige opslag houdt vermeldingen onder /run/log/journal, persistente opslag onder /var/log/journal, en de automatische modus kiest daartussen; de geldende modus komt van het draaiende systeem en niet uit de beschrijving van het image. Overschakelen naar vluchtig wist niet wat al persistent is geschreven. Doorsturen is ook een apart kanaal: zelfs een opslaginstelling die lokaal niets houdt, kan berichten aan een ander doel afleveren.

Lees de effectieve modus uit het journaal zelf of het configuratiebestand ervan, en controleer daarna de doorstuurdoelen apart, omdat de ene instelling de andere niet bestuurt.

Wat een herstart moet overleven

Een stateless runtime ondersteunt herhaalbare vervanging, en heeft bewuste bronnen nodig voor de configuratie, autorisatie en het herstelmateriaal dat de dienst niet kan verzinnen. De enige werkende inschrijvings- of intrekkingsstatus verliezen om lokale schrijfacties te laten verdwijnen is een slechte ruil, en een veelvoorkomende. Bepaal wat bewust moet overleven en verifieer dan dat het dat doet.

Dezelfde redenering geldt voor operationele registratie. Bepaal welke gebeurtenissen beveiliging en dienstbeheer werkelijk vereisen, met een gerechtvaardigde reikwijdte en bewaring, en minimaliseer de rest. Minimaliseren is niet hetzelfde als alle diagnostiek uitschakelen.

Vergelijk de effectieve opslag- en doorsturingsconfiguratie met enkele onschadelijke gebeurtenissen, herstart of vervang daarna de machine en controleer opnieuw wat bleef en waar de dienst zijn status herstelde.