Среда выполнения VPN в RAM ничего не говорит о журналах

VPN-сервер, загружаемый из образа только для чтения и держащий рабочее состояние в tmpfs, — реальный и полезный дизайн. Его также легко описать как «без журналов», чего дизайн не доказывает. Место хранения определяет, где живёт копия; сбор и хранение определяют, существует ли запись вообще, а перезагрузка влияет только на первое. Разделение этих двух вещей и есть весь обзор.

Начните с перечисления каждого процесса, который может писать состояние: демон, служба аутентификации, журнал, любой агент мониторинга и инструменты управления.

Хранение и сбор — разные вопросы

У каждого писателя своё назначение и своя политика. Демон VPN пишет файлы состояния, бэкенд аутентификации пишет события учётной записи, журнал собирает вывод служб, а агент мониторинга отправляет метрики совсем в другое место. Дизайн, который заставляет одно из этого исчезнуть при перезагрузке, ничего не сказал об остальных трёх. Проследите каждого писателя до его назначения и отметьте, находится ли это назначение вообще на машине.

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

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

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

Затем составьте перечень того, что переживает перезагрузку способами, о которых люди забывают: постоянный верхний слой, подключённое хранилище, образы гибернации, дампы сбоев и инфраструктурные снимки всей VM. Каждое из этого — возможное назначение для состояния, которое вы считали эфемерным. Этот список нужно проверять, а не утверждать, что у каждого хоста есть всё.

У Journald два назначения и пересыльщик

Journald наглядно показывает это разделение. Энергозависимое хранилище держит записи в /run/log/journal, постоянное — в /var/log/journal, а автоматический режим выбирает между ними; действующий режим берётся из работающей системы, а не из описания образа. Переход на энергозависимое не удаляет то, что уже записано постоянно. Пересылка — тоже отдельный канал: даже настройка хранилища, которая ничего не держит локально, может передать сообщения другой цели.

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

Что должно пережить перезагрузку

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

Те же рассуждения применимы к операционным записям. Решите, какие события действительно нужны безопасности и управлению службами, с обоснованными объёмом и сроком хранения, а остальное сведите к минимуму. Минимизация — не то же самое, что отключение всей диагностики.

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