Середовище виконання VPN у RAM нічого не каже про журнали

VPN-сервер, який завантажується з образу лише для читання і тримає робочий стан у tmpfs, — реальний і корисний дизайн. Його також легко описати як «без журналів», чого дизайн не доводить. Місце зберігання визначає, де живе копія; збирання й збереження визначають, чи існує запис узагалі, а перезавантаження впливає лише на перше. Розділення цих двох і є весь огляд.

Почніть із переліку кожного процесу, який може писати стан: демон, служба автентифікації, журнал, будь-який агент моніторингу та інструменти керування.

Зберігання і збирання — різні питання

Кожен записувач має своє призначення і свою політику. Демон VPN пише файли стану, бекенд автентифікації пише події облікового запису, журнал збирає вивід служб, а агент моніторингу надсилає метрики зовсім в інше місце. Дизайн, який змушує одне з цього зникнути під час перезавантаження, нічого не сказав про решту трьох. Простежте кожного записувача до його призначення і зазначте, чи це призначення взагалі на машині.

Файли, специфічні для застосунку, завантажена діагностика і зовнішні служби потребують того самого підходу. Відсутність знайомого локального журналу не доводить, що записів про з'єднання чи облікові записи ніде немає; вона доводить, що ви ще не знайшли, куди вони потрапляють.

tmpfs — не гарантія

Linux tmpfs — не фізичний RAM-диск. Документація ядра прямо зазначає, що сторінки можна записувати в swap, якщо монтування це дозволяє, тож файл tmpfs може потрапити на диск, навіть якщо застосунок жодного разу його туди не копіював. mount показує, чи задіяно tmpfs із підтримкою swap, а інші файлові системи в пам'яті поводяться інакше. Читайте фактичні параметри монтування, а не припускайте, що шлях під /run означає енергонезалежність.

Потім складіть перелік того, що переживає перезавантаження способами, про які люди забувають: постійний верхній шар, під'єднане сховище, образи гібернації, дампи збоїв та інфраструктурні знімки всієї VM. Кожне з цього — можливе призначення для стану, який ви вважали ефемерним. Цей список треба перевіряти, а не стверджувати, що кожен хост має все.

У Journald два призначення і пересилач

Journald наочно показує цей поділ. Енергозалежне сховище тримає записи в /run/log/journal, постійне — в /var/log/journal, а автоматичний режим вибирає між ними; чинний режим береться з робочої системи, а не з опису образу. Перехід на енергозалежне не видаляє те, що вже записано постійно. Пересилання — теж окремий канал: навіть налаштування сховища, яке нічого не тримає локально, може передати повідомлення іншій цілі.

Прочитайте чинний режим із самого журналу або його файлу конфігурації, потім окремо перевірте цілі пересилання, бо одне налаштування не керує іншим.

Що має пережити перезавантаження

Середовище без стану підтримує повторювану заміну, і йому потрібні усвідомлені джерела для конфігурації, авторизації та матеріалу відновлення, які служба не може вигадати. Втратити єдиний робочий стан реєстрації чи відкликання, щоб локальні записи зникли, — погана угода, і часта. Вирішіть, що має навмисно зберегтися, і переконайтеся, що це так.

Ті самі міркування стосуються операційних записів. Вирішіть, які події справді потрібні безпеці та керуванню службами, з обґрунтованим обсягом і збереженням, а решту зведіть до мінімуму. Мінімізація — не те саме, що вимкнення всієї діагностики.

Порівняйте чинну конфігурацію зберігання й пересилання з кількома нешкідливими подіями, потім перезавантажте або замініть машину і знову перевірте, що залишилося і звідки служба відновила свій стан.