Runtime VPN v RAM nehovorí nič o logoch

Server VPN zavedený z obrazu iba na čítanie so stavom runtime na tmpfs je skutočný a užitočný návrh. Ľahko sa tiež opíše ako bez logov, čo návrh nedokazuje. Umiestnenie úložiska určuje, kde kópia žije; zber a uchovávanie určujú, či záznam vôbec existuje, a reštart ovplyvní len prvé. Rozdeliť tieto dve veci je celá revízia.

Začnite výpočtom všetkých procesov, ktoré môžu zapisovať stav: démon, autentifikačná služba, žurnál, akýkoľvek monitorovací agent a nástroje správy.

Úložisko a zber sú odlišné otázky

Každý zapisovateľ má svoje cieľové miesto a svoju politiku. Démon VPN zapisuje stavové súbory, autentifikačný backend zapisuje udalosti účtu, žurnál zhromažďuje výstup služieb a monitorovací agent posiela metriky úplne inam. Návrh, ktorý nechá jednu z tých vecí pri reštarte zmiznúť, nepovedal nič o ostatných troch. Sledujte každého zapisovateľa k jeho cieľu a poznamenajte, či je ten cieľ vôbec na stroji.

Súbory špecifické pre aplikáciu, nahratá diagnostika a externé služby potrebujú rovnaký prístup. Neprítomnosť známeho lokálneho logu nedokazuje, že záznamy o pripojeniach alebo účtoch nikde neexistujú; dokazuje, že ste ešte nenašli, kam idú.

tmpfs nie je záruka

Linux tmpfs nie je fyzický diskový RAM disk. Dokumentácia jadra výslovne uvádza, že stránky možno zapísať do swapu, keď to pripojenie umožňuje, takže súbor na tmpfs sa môže dostať na disk bez toho, aby ho aplikácia kedy naň skopírovala. mount ukazuje, či je v hre tmpfs podporovaný swapom, a iné pamäťové súborové systémy sa správajú zase inak. Čítajte skutočné možnosti pripojenia namiesto toho, aby ste predpokladali, že cesta pod /run znamená nestálosť.

Potom si urobte inventár vecí, ktoré prežijú reštart spôsobmi, na ktoré ľudia zabúdajú: trvalá prekrývajúca vrstva, pripojené úložisko, obrazy hibernácie, výpisy zlyhaní a infraštruktúrne snímky celého VM. Každá z nich je kandidátom na cieľ stavu, ktorý ste považovali za efemérny. Ten zoznam je niečo na kontrolu, nie tvrdenie, že ho má každý hostiteľ.

Journald má dve cieľové miesta a preposielač

Journald to rozdelenie pekne ilustruje. Nestále úložisko drží záznamy pod /run/log/journal, trvalé pod /var/log/journal a automatický režim volí medzi nimi; platný režim pochádza z bežiaceho systému, nie z popisu obrazu. Prepnutie na nestále nezmaže to, čo už bolo zapísané trvalo. Preposielanie je tiež samostatný kanál: aj nastavenie úložiska, ktoré lokálne nič nedrží, môže odovzdávať správy inému cieľu.

Prečítajte si platný režim zo samotného žurnálu alebo z jeho konfiguračného súboru, potom zvlášť skontrolujte ciele preposielania, pretože jedno nastavenie neovláda druhé.

Čo musí prežiť reštart

Runtime bez stavu podporuje opakovateľnú výmenu a potrebuje zámerné zdroje pre konfiguráciu, autorizáciu a obnovovací materiál, ktorý si služba nedokáže vymyslieť. Strata jediného funkčného stavu zápisu alebo odvolania len preto, aby zmizli lokálne zápisy, je zlý obchod a častý. Rozhodnite, čo má zámerne prežiť, a potom overte, že prežíva.

Rovnaká úvaha platí pre prevádzkové záznamy. Rozhodnite, ktoré udalosti bezpečnosť a správa služieb skutočne vyžadujú, s odôvodneným rozsahom a uchovávaním, a ostatné minimalizujte. Minimalizácia nie je to isté ako vypnutie všetkej diagnostiky.

Porovnajte platnú konfiguráciu úložiska a preposielania s niekoľkými neškodnými udalosťami, potom reštartujte alebo vymeňte stroj a znova skontrolujte, čo zostalo a odkiaľ služba obnovila svoj stav.