Подготовка и обслуживание стенда преподавателем¶
Назначение комплектов¶
- 101–106 (
m1-*): выполнение модуля 1 студентом с исходного состояния ОС. - 201–206 (
m23-*): отдельный комплект с проверенной сетью для модулей 2–3. - 9000, 9001: базовые образы для связанных клонов. Они являются зависимостями дисков учебных ВМ.
Работа со связанными клонами и снимками экономит физическое место. Сумма виртуальных размеров LVM может превышать физический пул; фактическую загрузку проверяют через pvesm status и lvs -o lv_name,lv_size,data_percent.
Выбранные ресурсы на один комплект¶
| ВМ | vCPU | ОЗУ | Системный диск |
|---|---|---|---|
| ISP | 1 | 1 ГиБ | 12 ГиБ |
| HQ-RTR | 1 | 1,5 ГиБ | 12 ГиБ |
| BR-RTR | 1 | 1,5 ГиБ | 12 ГиБ |
| HQ-SRV | 2 | 6 ГиБ | 32 ГиБ |
| BR-SRV | 2 | 4 ГиБ | 32 ГиБ |
| HQ-CLI | 2 | 6 ГиБ | 40 ГиБ |
Учебные ресурсы увеличены относительно минимальной таблицы задания для комфортной работы GUI и прикладных служб. У HQ-SRV комплекта 2–3 дополнительно три диска по 1 ГиБ; для RAID 0 по заданию используются два.
Воспроизведение подготовки¶
Скрипты выполняются последовательно; команды ниже относятся к новому пустому узлу с такими же именами интерфейса и хранилищ. Фактически используемые настройки узла зафиксированы в топологии.
scripts/prepare-host.shвыполняется на Proxmox: создаёт мосты, NAT и вышестоящий DHCP. Конфигурация управления рассчитана наens192,10.12.21.1/24, шлюз10.12.21.254.- Скачать образы, сверить SHA256.
scripts/download-assets.pyзагружает минимальный образ Альт иAdditional.iso; рабочая станция загружается из того же официального каталога с отдельной сверкой SHA256. scripts/create-base.sh: импорт минимальной ОС, первый запуск с cloud-init.- В ВМ 9000 выполнить
scripts/bootstrap-base.sh, затемscripts/clean-base.sh. scripts/create-workstation-base.sh: импорт рабочей станции. В 9001 выполнитьscripts/bootstrap-workstation.sh, затемscripts/clean-base.sh.- Остановить базовые ВМ, отсоединить cloud-init и преобразовать их в шаблоны:
qm shutdown 9000 --timeout 60
qm set 9000 --delete ide2,cicustom,ipconfig0
qm template 9000
Повторить для 9001. Дождаться завершения преобразования: в qm config системный диск должен ссылаться на base-9000-disk-0 / base-9001-disk-0.
- Выполнить
scripts/create-lab.pyна гипервизоре. Можно отдельно--kind serverи--kind client. - При подготовке каждого клона выполнить
scripts/prepare-guest.sh, проверитьeth0/eth1/eth2, уникальный machine-id и размер корневой ФС. После штатного выключения сохранить согласованное начальное состояниеos-installed.
Особенности этих образов:
- В Альт
grub-mkconfigчитает/etc/sysconfig/grub2. Изменение только/etc/default/grubне добавляетnet.ifnames=0в загрузку. - Старый
/etc/netplan/50-cloud-init.yamlможет принудительно переименовывать адаптеры по MAC. Подготовка удаляет этот сгенерированный файл и маскирует службы cloud-init. - При добавлении SCSI-дисков имя системного диска может стать
/dev/sdd, а не/dev/sda. Определяйте корневой раздел черезfindmnt -n -o SOURCE /, родительский диск — черезlsblk; дополнительные диски HQ-SRV снабжены серийными номерамиHQ-RAID1–HQ-RAID3.
Локальный запуск подготовленного скрипта внутри гостя:
python3 scripts/guest.py 204 --script scripts/prepare-guest.sh
QEMU Guest Agent работает через виртуальный последовательный канал и доступен даже при ненастроенной сети. Он используется для подготовки эталона; студент может выполнять те же команды через консоль Proxmox.
Восстановление исходного состояния¶
os-installed — установленные ОС без решения задания. module2-start содержит выполненную сеть модуля 1, module3-start — выполненный модуль 2. Итоговый module3-complete сохраняется после повторной приёмки всего комплекта.
Восстанавливайте весь комплект, чтобы конфигурации маршрутизаторов, DNS и домена соответствовали одному этапу. Пример для начального состояния модуля 1, на Proxmox:
for id in 101 102 103 104 105 106; do
qm stop "$id"
done
for id in 101 102 103 104 105 106; do
qm rollback "$id" os-installed
qm start "$id"
done
Перед переходом к модулям 2–3 остановите 101–106 и запустите 201–206. Студент получает преднастроенную сеть независимо от результата своего модуля 1.
Итоговая приёмка и сохранение¶
На новом HQ-CLI предварительно перенесите scripts/setup-browser-tools.sh и scripts/module3-domain-browser.sh в /root, затем под root:
bash /root/setup-browser-tools.sh
bash /root/module3-domain-browser.sh
Это только инструменты преподавательской проверки. На текущем эталоне они уже подготовлены. Playwright 1.63.0 использует установленный Яндекс Браузер; отдельный Chromium скачивать не нужно. Студенту для ручной проверки достаточно графического сеанса браузера с КриптоПро.
На рабочем компьютере из корня проекта:
Полный проверочный проход одной командой: python3 scripts/verify-all.py. Протоколы каждого этапа и общий JSON сохраняются в evidence/final/. Fail2ban использует временный адрес HQ-CLI 192.168.200.8, удаляя его по завершении. При повторении раньше истечения findtime=600 выберите другой свободный адрес: --fail2ban-source 192.168.200.7; не сбрасывайте реальные баны ради теста.
python3 scripts/checkpoint.py --reboot-only
python3 scripts/verify-module1.py --base 200
python3 scripts/verify-module2.py --module3
python3 scripts/verify-module3.py
python3 scripts/verify-fail2ban.py
python3 scripts/browser.py scripts/browser-admin-login.py
python3 scripts/browser.py scripts/browser-cyber18-verify.py
python3 scripts/browser.py scripts/browser-gost-verify.py --headed
python3 scripts/browser.py scripts/browser-run-backups18.py
python3 scripts/verify-backup18.py
--module3 проверяет публикацию по ГОСТ HTTPS вместо старого HTTP. Проверка КриптоПро curl явно пропускает только отзыв сертификатов: учебный УЦ не публикует CRL; браузерная проверка проводится отдельно, без игнорирования TLS-ошибок. Проверочный браузер требует установленные Playwright и Xvfb на HQ-CLI, а module3-domain-browser.sh подготавливает запуск браузера от hquser1. Приватный контекст Playwright не подходит для данного ГОСТ-сценария.
Не запускайте в рабочем стенде повторно provision домена, создание RAID/ФС или выпуск ключей УЦ. Это команды начального развёртывания, а не тесты идемпотентности. Для независимого повторения с нуля используйте изолированный комплект и согласованное начальное состояние; не откатывайте текущий эталон без сохранения его данных.
Перед снимком убедитесь, что задания Кибер Бэкап не выполняются. Затем:
python3 scripts/checkpoint.py module3-complete
Скрипт сначала разрывает обратную NFS-зависимость HQ-SRV → HQ-CLI (оставшуюся от теста нативного MySQL), выключает HQ-CLI, затем остальные ВМ. Снимки создаются на остановленных гостях, после чего весь комплект запускается и ожидается QEMU Agent/NTP. После сохранения повторите проверки: снимок сам по себе не доказывает работоспособность.
Перед новым экзаменом¶
- Проверьте свободное место thin pool и
/backup; суммы виртуальных размеров не равны реально занятому месту. Не удаляйте шаблоны 9000/9001: от них зависят связанные клоны. - Выпустите новые 30-дневные сертификаты, перенесите пары на ISP и новый публичный УЦ в системное хранилище HQ-CLI и
mRootКриптоПро. - Убедитесь в действии лицензий Кибер Бэкап 18 и CSP; снимок не продлевает сроки. Не используйте откат часов или снимков для обхода лицензирования.
- Версия 18.5 устанавливается с нуля. Не повторяйте исторический переход с пробной 17; не выбирайте неподтверждённый нативный MySQL-план вместо проверенного SQL-дампа.
- Учебные пароли опубликованы для изолированного стенда; не выставляйте консоль, базы и API в публичный Интернет.
- На ISP маскируется также старое имя SysV
cloud-init.service: одних новых cloud-init-main/network недостаточно. На HQ-CLI отключён аппаратный cpufreq для вложенной ВМ; rpc-svcgssd не используется, поскольку учебные NFS-ресурсы работают с sec=sys, не Kerberos. Проверяется отсутствие failed units на всех шести гостях. - Обсудите с экспертами логическое копирование
webdb: оно восстановлено и проверено, но не заявляется как нативная application-aware защита СУБД.