Перейти к содержанию

Подготовка и обслуживание стенда преподавателем

Назначение комплектов

  • 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 по заданию используются два.

Воспроизведение подготовки

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

  1. scripts/prepare-host.sh выполняется на Proxmox: создаёт мосты, NAT и вышестоящий DHCP. Конфигурация управления рассчитана на ens192, 10.12.21.1/24, шлюз 10.12.21.254.
  2. Скачать образы, сверить SHA256. scripts/download-assets.py загружает минимальный образ Альт и Additional.iso; рабочая станция загружается из того же официального каталога с отдельной сверкой SHA256.
  3. scripts/create-base.sh: импорт минимальной ОС, первый запуск с cloud-init.
  4. В ВМ 9000 выполнить scripts/bootstrap-base.sh, затем scripts/clean-base.sh.
  5. scripts/create-workstation-base.sh: импорт рабочей станции. В 9001 выполнить scripts/bootstrap-workstation.sh, затем scripts/clean-base.sh.
  6. Остановить базовые ВМ, отсоединить 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.

  1. Выполнить scripts/create-lab.py на гипервизоре. Можно отдельно --kind server и --kind client.
  2. При подготовке каждого клона выполнить 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 защита СУБД.

Итоги и границы проверки: приёмка, состояние.