Клонирование образа VPN-сервера без клонирования его идентичности

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

Ответ определяют три условия, и это три корзины материала, которые может нести образ. Разложите их до сборки образа, а не после того, как он был развёрнут дважды.

Сначала решите, какую из двух операций вы выполняете

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

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

Поэтому первое решение — это фраза, записанная до того, как образ покинет сборочный хост: эта копия восстанавливает шлюз A или эта копия становится шлюзом B. Всё дальнейшее — учёт относительно этой фразы. Если никто не может её написать, копия не готова к сборке.

Многоразовые входные данные, идентичность и полномочия, состояние развёртывания

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

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

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

Что должен получить новый узел и от кого

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

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

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

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

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

Что копия образа тихо несёт с собой

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

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

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

Проверки допуска перед производством

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

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

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

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