Пересоберите VPN-устройство на Raspberry Pi, не копируя его ключ

Однократная загрузка с образа не превращает Pi в устройство, которое можно пересобрать. Нужен небольшой набор входов, которые можно применить заново: поддерживаемая база, объявленная конфигурация, постоянные данные приложения и идентичность устройства, принадлежащая только этой плате. Пропустите последний — и каждая замена станет клоном учётных данных.

Шаги ниже — это порядок работы, а не рекомендация инструмента. Подойдёт любая система конфигурации, способная их выразить.

Сначала перечислите четыре вида входов

Базовый образ и его пакеты определяют операционную систему, архитектуру и источник обновлений, а сборщик образов помогает только если называемый им инструмент всё ещё поддерживается для вашего выпуска. Объявленная конфигурация — это часть, которую проверяет человек: сетевые роли, настройки служб и действия жизненного цикла, нужные каждой службе. Постоянные данные приложения — всё, что служба не может воссоздать, а их расположение и способ резервного копирования принадлежат этому приложению, а не образу. Идентичности устройств и секреты — четвёртый вход, и именно о них забывают, клонируя рабочую карту.

Напишите четыре списка, прежде чем что-либо пересобирать. Список с пустой строкой — это решение, которое вы ещё не приняли.

Держите секреты вне репозитория и скажите, где они живут

Репозиторий — хороший дом для проверенных шаблонов и несекретной конфигурации и плохой дом для приватных ключей VPN, многоразовых администраторских учётных данных и диагностических архивов. Если секрет должен существовать на устройстве, запишите, откуда он берётся, кто может его читать и как он ротируется. Ключ, живущий только на одной SD-карте, — единая точка отказа, а ключ, скопированный на каждую плату, — учётные данные всего парка без владельца. Ни то, ни другое не является планом восстановления.

Проверка проста: если репозиторий завтра утечёт, что получит злоумышленник? Шаблоны и заметки о топологии переживут утечку. Рабочая идентичность — нет.

Пусть автоматизация владеет тем, что может перезапустить

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

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

Восстанавливайте данные и идентичность осознанно

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

Что касается идентичности, решите, восстанавливаете вы то же устройство или регистрируете замену, потому что это разные операции с разной очисткой.

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

Загрузочный образ — один вход из четырёх, и его проще всего воспроизвести.