Runtime VPN v RAM nic nevypovídá o logech

Server VPN zavedený z obrazu pouze pro čtení se stavem runtime na tmpfs je skutečný a užitečný návrh. Snadno se také popíše jako bez logů, což návrh nedokazuje. Umístění úložiště určuje, kde kopie žije; sběr a uchovávání určují, zda záznam vůbec existuje, a restart ovlivní jen první z toho. Rozdělit tyto dvě věci je celá revize.

Začněte výčtem všech procesů, které mohou zapisovat stav: démon, autentizační služba, žurnál, případný monitorovací agent a nástroje správy.

Úložiště a sběr jsou odlišné otázky

Každý zapisovatel má své cílové místo a svou politiku. Démon VPN zapisuje stavové soubory, autentizační backend zapisuje události účtu, žurnál shromažďuje výstup služeb a monitorovací agent posílá metriky zcela jinam. Návrh, který nechá jednu z těch věcí při restartu zmizet, neřekl nic o ostatních třech. Sledujte každého zapisovatele k jeho cíli a poznamenejte, zda je ten cíl vůbec na stroji.

Soubory specifické pro aplikaci, nahraná diagnostika a externí služby potřebují stejný přístup. Nepřítomnost známého lokálního logu nedokazuje, že záznamy o připojeních nebo účtech nikde neexistují; dokazuje, že jste ještě nenašli, kam jdou.

tmpfs není záruka

Linux tmpfs není fyzický diskový RAM disk. Dokumentace jádra výslovně uvádí, že stránky lze zapsat do swapu, když to připojení umožňuje, takže soubor na tmpfs se může dostat na disk, aniž by jej aplikace kdy na něj zkopírovala. mount ukazuje, zda je ve hře tmpfs podporovaný swapem, a jiné paměťové souborové systémy se chovají zase jinak. Čtěte skutečné možnosti připojení, místo abyste předpokládali, že cesta pod /run znamená nestálost.

Potom si udělejte inventuru věcí, které přežijí restart způsoby, na které lidé zapomínají: trvalá překryvná vrstva, připojené úložiště, obrazy hibernace, výpisy pádů a infrastrukturní snímky celého VM. Každá z nich je kandidátem na cíl stavu, který jste považovali za efemérní. Ten seznam je něco ke kontrole, ne tvrzení, že jej má každý hostitel.

Journald má dvě cílová místa a přeposílač

Journald to rozdělení pěkně ilustruje. Nestálé úložiště drží záznamy pod /run/log/journal, trvalé pod /var/log/journal a automatický režim volí mezi nimi; platný režim pochází z běžícího systému, ne z popisu obrazu. Přepnutí na nestálé nesmaže to, co už bylo zapsáno trvale. Přeposílání je také samostatný kanál: i nastavení úložiště, které místně nic nedrží, může předávat zprávy jinému cíli.

Přečtěte si platný režim ze samotného žurnálu nebo z jeho konfiguračního souboru, potom zvlášť zkontrolujte cíle přeposílání, protože jedno nastavení neovládá druhé.

Co musí přežít restart

Runtime bez stavu podporuje opakovatelnou výměnu a potřebuje záměrné zdroje pro konfiguraci, autorizaci a obnovovací materiál, který si služba nedokáže vymyslet. Ztratit jediný funkční stav zápisu nebo odvolání jen proto, aby zmizely lokální zápisy, je špatný obchod a častý. Rozhodněte, co má záměrně přežít, a poté ověřte, že přežívá.

Stejná úvaha platí pro provozní záznamy. Rozhodněte, které události bezpečnost a správa služeb skutečně vyžadují, s odůvodněným rozsahem a uchováváním, a ostatní minimalizujte. Minimalizace není totéž jako vypnutí veškeré diagnostiky.

Porovnejte platnou konfiguraci úložiště a přeposílání s několika neškodnými událostmi, poté restartujte nebo vyměňte stroj a znovu zkontrolujte, co zůstalo a odkud služba obnovila svůj stav.