Образец задания

Образец задания для демонстрационного экзамена по комплекту

оценочной документации.

Описание задания
Модуль 1
Вариант 1-0 (публичный)

Виртуальные машины и коммутация.

Необходимо выполнить создание и базовую конфигурацию

виртуальных машин.
● На основе предоставленных ВМ или шаблонов ВМ создайте
отсутствующие виртуальные машины в соответствии со схемой.
o Характеристики ВМ установите в соответствии с Таблицей 1;
o Коммутацию (если таковая не выполнена) выполните в
соответствии со схемой сети.
● Имена хостов в созданных ВМ должны быть установлены в
соответствии со схемой.
● Адресация должна быть выполнена в соответствии с Таблицей 1;

● Обеспечьте ВМ дополнительными дисками, если таковое необходимо в

соответствии с Таблицей 1;

(Если изначально доступна работа из под пользователя с обычными

привилегиями, то повышение привилегий, то есть работа из под root,
выполняется через команду sudo -i).
На текущем этапе, пока что выполняется настройка имён хостов и IP-
адресации.

МОНТИРОВАНИЕ ОБРАЗОВ И УСТАНОВКА ПАКЕТОВ

На демо-экзамене предоставляются ISO-образы с дополнительным

ПО. Установка пакетов через них. Выход в реальный интернет не
предоставляется.
К примеру, на виртуальной машине RTR-L нужно установить
необходимые по заданию пакеты. Для этого необходимо
вмонтировать в VM один из ISO-образов и добавить его в [Link]
(необязательно все, только самый первый).
сщ

Одновременно с добавлением образа в [Link], производится

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

А далее снова apt-cdrom add.

Добавляем автомонтирование образа с ПО при перезагрузке

виртуальной машины.

(в nano сохранение изменений на CTRL+S, выход — CTRL+X)

Очень полезные сочетания клавиш в nano:
Alt + 6 — копировать одну или несколько строк.
Ctrl + U — вставить строку или строки.
Ctrl + K — вырезать (удалить) строку.
Alt + T — удалить ВСЁ ниже курсора.
Ctrl + S — сохранить изменения.
Ctrl + X — выход.
Длинные пробелы ставятся при нажатии на TAB.

Далее нужно настроить статическую IP-адресацию на каждой машине.

Адресация представлена в конце комплекта оценочной документации.
Для сопоставления MAC-адресов с IP-адресами на каждой машине,
нужно проделать следующее:
На proxmox, при выборе виртуальной машины и просмотре списка его
оборудования, нужно обратить внимание на MAC-адрес и имя моста
(bridge). У другой машины, присоединённой к текущей (пример ISP),
имя моста будет идентичным.

По одинаковому названию моста можно увидеть связность конкретных

машин. По их MAC-адресам — связь с IP-адресами.
ПЕРВЫЙ ВАРИАНТ НАСТРОЙКИ IP-адресов каждой машины (кроме
CLI). Каждый интерфейс настраивается через nmcli одной длинной
командой:

ISP
Названия интерфейсов можно посмотреть и через nmcli connection.
Если наименования не содержат Wired connection и они имеют
красный цвет, то нужно ввести команду systemctl restart
NetworkManager и заново ввести nmcli connection.

Элементы команд полностью не нужно вписывать (кроме имён и

цифр). Достаточно вбить начало команды (пример: [Link]), как в
терминале Cisco, и через нажатие на TAB произойдёт
автодописывание ([Link]).
Пример соответствует самой первой введёной строке: nmc(TAB)
co(TAB) mod(TAB) Wi(TAB) 1 ipv4.a(TAB) [Link]/24 [Link](TAB)
m(TAB) au(TAB) y(TAB) con-n(TAB) ISP-RTRR.

RTR-R

RTR-L
WEB-L

SRV

WEB-R

CLI
На виртуальной машине CLI, по заданию, операционная система
Windows 10. Порядок изменения имени хоста и IP-адреса там другой:
Жмём на OK, заходим в PowerShell и пингуем шлюз по умолчанию
(ISP). Далее меняем имя хоста:
Запрос о перезагрузке подтверждаем.
ВТОРОЙ ВАРИАНТ НАСТРОЙКИ (короткие команды в nmcli):

ISP
RTR-R

RTR-L
WEB-L

SRV
 WEB-R

После настройки IP-адресации, проверяем доступность соседних

устройств с помощью команды ping.

Для отправки файлов с помощью scp (или для соединения по ssh),

нужно отредактировать sshd_config на начальной (откуда), конечной
(куда отправляем файл) и промежуточной виртуальной машине (через
какую машину проходит файл). Допустим, нужно отправить файл test с
RTR-L на RTR-R. После установки пакетов, включая ssh, на RTR-L,
RTR-R и ISP между ними редактируется строка с разрешением на
аутентификацию из под root.
 Сетевая связность.

В рамках данного модуля требуется обеспечить сетевую связность

между регионами работы приложения, а также обеспечить выход ВМ в
имитируемую сеть “Интернет”.
● Сети, подключенные к ISP, считаются внешними:
o Запрещено прямое попадание трафика из внутренних сетей во
внешние и наоборот;

Сперва, нужно разрешить пересылку пакетов через устройства,

осуществляющих маршрутизацию (RTR-L, ISP и RTR-R).

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

необходимо установить firewalld на RTR-L и RTR-R. Интерфейсы на
них, смотрящие во внешние сети, определить в зону external. В зоне
external разрешён не весь, а только определённый вручную тип
трафика, а также выполняется трансляция трафика, идущего из
внутренних сетей во внешние.

Выявляем интерфейсы, которые смотрят во «внешние» сети.

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

Условия выполнены примерами выше.

● Между платформами должен быть установлен защищенный туннель,

позволяющий осуществлять связь между регионами с применением
внутренних адресов.
o Трафик, проходящий по данному туннелю, должен быть
защищен:
▪ Платформа ISP не должна иметь возможности
просматривать содержимое пакетов, идущих из одной
внутренней сети в другую.
o Туннель должен позволять защищенное взаимодействие между
платформами управления трафиком по их внутренним адресам
▪ Взаимодействие по внешним адресам должно происходит
без применения туннеля и шифрования.
o Трафик, идущий по туннелю между регионами по внутренним
адресам, не должен транслироваться.
На RTR-L и RTR-R устанавливаем libreswan для работы IPsec
(создание защищённого туннеля). Для его установки потребуется
использовать два образа с ПО, монтируя и извлекая их поочерёдно,
когда потребует этого установщик в debian.

Сначала выполняется создание GRE-туннеля между RTR-L и RTR-R.

После — настройка файрволла на ISP. Поверх туннеля — настройка
IPsec.
 IPsec

Создаём файлы конфигурации и ключа.

Для большего удобства, лучше скопировать [Link] и
[Link] с RTR-L на RTR-R через scp, в аналогичную
директорию.
Дополнительная проверка работы IPsec. Запуск tcpdump на ISP, при
оправке ICMP-запросов с RTR-R на RTR-L. На скрине ниже видно, что
ICMP-запросы и ответы именуются иначе.
Для организации подключения виртуальных машин, имеющих адреса
во внутренних сетях, к новосозданному туннелю и для связи стороны
Left со стороной Right, нужно настроить один из протоколов
маршрутизации (EIGRP или OSPF) с помощью frr.
● Платформа управления трафиком RTR-L выполняет контроль
входящего трафика согласно следующим правилам:
o Разрешаются подключения к портам DNS, HTTP и HTTPS для
всех клиентов;
▪ Порты необходимы для работы настраиваемых служб
 o Разрешается работа выбранного протокола организации
защищенной связи;
▪ Разрешение портов должно быть выполнено по принципу
“необходимо и достаточно”
o Разрешается работа протоколов ICMP;
o Разрешается работа протокола SSH;
o Прочие подключения запрещены;
o Для обращений к платформам со стороны хостов, находящихся
внутри регионов, ограничений быть не должно;

● Платформа управления трафиком RTR-R выполняет контроль

входящего трафика согласно следующим правилам:
o Разрешаются подключения к портам HTTP и HTTPS для всех
клиентов;
▪ Порты необходимо для работы настраиваемых служб
o Разрешается работа выбранного протокола организации
защищенной связи;
▪ Разрешение портов должно быть выполнено по принципу
“необходимо и достаточно”
o Разрешается работа протоколов ICMP;
o Разрешается работа протокола SSH;
o Прочие подключения запрещены;
 o Для обращений в платформам со стороны хостов, находящихся
внутри регионов, ограничений быть не должно;

● Обеспечьте настройку служб SSH региона Left:

o Подключения со стороны внешних сетей по протоколу к
платформе управления трафиком RTR-L на порт 2222 должны
быть перенаправлены на ВМ Web-L;
o Подключения со стороны внешних сетей по протоколу к
платформе управления трафиком RTR-R на порт 2244 должны
быть перенаправлены на ВМ Web-R;

(На WEB-L и WEB-R также необходимо настроить ssh на приём

соединений из под root).
Проверка подключения по ssh. Если на CLI имя пользователя не
«root», то к команде ssh дописывается -l root (английская л):

Инфраструктурные службы.
 В рамках данного модуля необходимо настроить основные
инфраструктурные службы и настроить представленные ВМ на применение
этих служб для всех основных функций.
● Выполните настройку первого уровня DNS-системы стенда:
o Используется ВМ ISP;
o Обслуживается зона [Link].
▪ Наполнение зоны должно быть реализовано в соответствии
с Таблицей 2;
o Сервер делегирует зону [Link] на SRV;
▪ Поскольку SRV находится во внутренней сети западного
региона, делегирование происходит на внешний адрес
маршрутизатора данного региона.
▪ Маршрутизатор региона должен транслировать
соответствующие порты DNS-службы в порты сервера
SRV.
o Внешний клиент CLI должен использова ть DNS-службу,
развернутую на ISP, по умолчанию;
(Делегирование зоны — это не то же самое, что и создание slave-
сервера! В нашем случае создаются два master-сервера).
● Выполните настройку второго уровня DNS-системы стенда;
o Используется ВМ SRV;
o Обслуживается зона [Link];
▪ Наполнение зоны должно быть реализовано в соответствии
с Таблицей 2;
o Обслуживаются обратные зоны для внутренних адресов регионов
▪ Имена для разрешения обратных записей следует брать из
Таблицы 2;
o Сервер принимает рекурсивные запросы, исходящие от адресов
внутренних регионов;
▪ Обслуживание клиентов(внешних и внутренних),
обращающихся к зоне [Link], должно производится
без каких либо ограничений по адресу источника;
o Внутренние хосты регионов (равно как и платформы управления
трафиком) должны использовать данную DNS-службу для
разрешения всех запросов имен;
На SRV выполняются аналогичные шаги, вплоть до настройки
apparmor. После apparmor — уже с дополнительными коррективами:
● Выполните настройку первого уровня системы синхронизации
времени:
o Используется сервер ISP.
o Сервер считает собственный источник времени верным,
stratum=4;
o Сервер допускает подключение только через внешний адрес
соответствующей платформы управления трафиком;
 ▪ Подразумевается обращение SRV для синхронизации
времени;
o Клиент CLI должен использовать службу времени ISP;

Далее нужно зайти на CLI и синхронизировать время с ISP. Для

начала, нужно любыми способами зайти в Панель Управления и
выбрать «Дата и Время».
Дополнительно, нужно включить автоматическую синхронизацию
времени и даты. Делается это так же через Control Panel (Панель
управления) -> Administrative Tools -> Services -> Windows Time. С
ручного управления переключаем на автоматическое, запускаем
сервис и применяем изменения.
Примерно так должен выглядеть правильно настроенный сервис.
● Выполните конфигурацию службы второго уровня времени на SRV.
o Сервер синхронизирует время с хостом ISP;
▪ Синхронизация с другими источникам запрещена;
o Сервер должен допускать обращения внутренних хостов
регионов, в том числе и платформ управления трафиком, для
синхронизации времени;
o Все внутренние хосты (в том числе и платформы управления
трафиком) должны синхронизировать свое время с SRV;
 ● ВАРИАНТ 1: Реализуйте файловый SMB-сервер на базе SRV
o Сервер должен предоставлять доступ для обмена файлами
серверам WEB-L и WEB-R;
o Сервер, в зависимости от ОС, использует следующие каталоги
для хранения файлов:
▪ /mnt/storage для система на базе Linux;

▪ Диск R:\ для систем на базе Windows;

o Хранение файлов осуществляется на диске (смонтированном по
указанным выше адресам), реализованном по технологии RAID
типа “Зеркало”;
● Сервера WEB-L и WEB-R должны использовать службу, настроенную
на SRV, для обмена файлами между собой:
o Служба файлового обмена должна позволять монтирование в
виде стандартного каталога Linux;
▪ Разделяемый каталог должен быть смонтирован по
адресу /opt/share;
o Каталог должен позволять удалять и создавать файлы в нем для
всех пользователей;

На SRV сначала нужно реализовать программно RAID 1 (Зеркало) на

двух накопителях по 2 ГБ. Сами накопители уже имеются на SRV.
Наличие и наименования накопителей проверяются командами fdisk -l
или lsblk.
Далее перезагружаем SRV командой reboot. После перезагрузки и
входа из под root, перепроверяем наименование RAID-массива. Оно
должно измениться.
Все последующие операции выполняются одинаково на WEB-L и
WEB-R!
После выполнения тех же действий на WEB-L, в качестве итоговой
проверки следует создать нового пользователя (желательно на WEB-L
и WEB-R), зайти из под него и попробовать создать, отредактировать
и удалить файлы по пути /opt/share. Ограничений в действиях быть не
должно.
 ● ВАРИАНТ 2: Реализуйте файловый сервер на базе SRV
o Сервер должен предоставлять доступ для обмена файлами
серверам WEB-L и WEB-R;
o Сервер, в зависимости от ОС, использует следующие каталоги
для хранения файлов:
▪ /mnt/storage для система на базе Linux;

▪ Диск R:\ для систем на базе Windows;

o Все созданные файлы в рамках обмена должны принадлежать
одному специальному пользователю;
● Сервера WEB-L и WEB-R должны использовать службу, настроенную
на SRV, для обмена файлами между собой:
o Служба файлового обмена должна позволять монтирование в
виде стандартного каталога Linux;
▪ Разделяемый каталог должен быть смонтирован по
адресу /opt/share;
o Каталог должен позволять удалять и создавать файлы в нем для
всех пользователей;

Именно в этом варианте условия задания кардинально отличаются от

тех, что вариантом выше:
1. Нет необходимости создавать RAID 1.
2. Не указано, что необходимо реализовывать именно файловый
SMB-сервер, то есть, можно любой другой.
3. Условие «Все созданные файлы в рамках обмена должны
принадлежать одному специальному пользователю» следует
понимать так: создаваемые файлы в /mnt/storage (SRV) и /opt/share
 (WEB-L и WEB-R), при проверке через ls -l, должны показывать
свою принадлежность конкретному пользователю, допустим,
tester, а не root и nobody.
4. Условие с принадлежностью файлов конкретному пользователю
ставит под сомнение возможность использования Samba, так как
там это крайне трудно реализовать.
Поэтому в этом примере файловый сервер будет реализовываться
помощью NFS.

Теперь необходимо внести изменения в конфигурационный файл

/etc/exports, позволяющие осуществить монтирование каталогов с
помощью NFS. Параметры первой добавленной строки позволят
создавать файлы на SRV из под пользователя tester. Следующие
четыре строки дают доступ хостам к каталогу /mnt/storage и также
выполняют функции первой строки.
Если ВДРУГ потребуется перезагрузить SRV, то скорее всего, после
ввода команды reboot, появится такое сообщение. Ничего страшного в
нём нет, потребуется только подождать 1-2 минуты до завершения
перезагрузки.

Проверка создания и доступа к файлам, из под других пользователей,

аналогична первому варианту.

(Одна из возможных полных альтернатив настройке файлового сервера).

● Выполните конфигурацию служб SSH на WEB-L и WEB-R:
o SSH-сервер должен использовать порт 1022;
o Подключение с аккаунтом root разрешено только в связках WEB-
L → WEB-R и WEB-R → WEB-L;
o Внешние подключения к WEB-L возможны только для
специально созданного аккаунта sshuser;
o Подключения из внутренних сетей к WEB-L и WEB-R возможны
для любых аккаунтов, кроме root;

Все необходимые настройки вносятся в конфигурационный файл

/etc/ssh/sshd_config, на WEB-L и WEB-R. И так как в этом задании
изменён порт ssh, то позже нужно будет изменить правила в
файрволлах на RTR-L и RTR-R, для обеспечения корректного доступа
с внешних сетей.

В конфигурационных файлах ниже используются специальные

символы для сокращения количества записей:
? (вопрос) - означает абсолютно любой один символ, один знак или
одну цифру.
* (звезда) - означает абсолютно любое количество символов, знаков
или цифр.
То есть, запись root@192.168.100.* включает в себя связку из аккаунта
root и диапазона адресов внутренней сети [Link] -
[Link].
Запись sshuser@?.?.?.* включает в себя связку из аккаунта sshuser и
диапазонов адресов, которым соответствуют внешние сети в задании:
[Link] - [Link], [Link] - [Link], [Link] - [Link].
Запись *@192.168.100.* включает в себя связку из любых аккаунтов и
диапазона адресов внутренней сети [Link] - [Link].

Две части конфигурационного файла на WEB-L:

Две части конфигурационного файла на WEB-R:
Далее необходимо сгенерировать приватные и публичные ключи на
WEB-L и WEB-R, а после — отправить друг другу только публичные
ключи. Предполагается, что по беспарольной аутентификации, с
использованием ключей, WEB-L и WEB-R будут взаимодействовать
только между собой. А с остальными ПК и не-root аккаунтами — по
паролям.
Такие действия необходимы для соблюдения условий задания о
запрете на вход из под root со стороны внутренних сетей, а
конкретнее, с адресов GRE-туннеля. Через DenyUsers в
/etc/ssh/sshd_config не получится просто запретить связку
root@10.5.5.*, в противном случае соединение по ssh между WEB-L и
WEB-R не будет устанавливаться.
Редактирование правил на файрволлах RTR-L и RTR-R, которые
касаются именно перенаправления подключений по ssh.
Теперь, для проверки соблюдения всех заданных условий,
необходимо создать какого-нибудь пользователя и пользователя
sshuser на WEB-L и WEB-R. Затем, в различных вариациях пробовать
подключаться по ssh к WEB-L и WEB-R.
● Выполните настройку центра сертификации на базе SRV:
o В случае применения решения на базе Linux используется центр
сертификации типа OpenSSL и располагается по адресу /var/ca;
o Выдаваемые сертификаты должны иметь срок жизни не менее
500 дней;
o Параметры выдаваемых сертификатов:
▪ Страна RU;

▪ Организация [Link];

▪ Прочие поля (за исключением CN) должны быть пусты;

По пути /var/ca/ теперь расположен наш локальный корневой центр
сертификации, со всеми необходимыми для него файлами.

Инфраструктура веб-приложения.
Данный блок подразумевает установку и настройку доступа к веб-
приложению, выполненному в формате контейнера Docker.
● Образ Docker (содержащий веб-приложение) расположен на ISO-образе
дополнительных материалов;
o Выполните установку приложения AppDocker0;
● Пакеты для установки Docker расположены на дополнительном ISO-
образе;
● Инструкция по работе с приложением расположена на дополнительном
ISO-образе;
Если файл имеет расширение просто tar, то распаковывать его не
нужно! Добавляем образ с расширением tar так же, в локальный
docker-репозиторий по инструкции ниже.

Порт сервера может быть другим, 80 например. На этом моменте

нужно заострить внимание, иначе веб-страница на CLI не откроется!
 ● Необходимо реализовать следующую инфраструктуру приложения.
o Клиентом приложения является CLI (браузер Edge);
o Хостинг приложения осуществляется на ВМ WEB-L и WEB-R;
o Доступ к приложению осуществляется по DNS-имени
[Link];
▪ Имя должно разрешаться во “внешние” адреса ВМ
управления трафиком в обоих регионах;
▪ При необходимости, для доступа к приложению
допускается реализовать реверс-прокси или трансляцию
портов;

Инструкция ([Link]) по работе с приложением в docker-

контейнере написана на русском языке. Имеющееся ПО в Debian для
просмотра и редактирования текстовых файлов не распознаёт
кириллицу, поэтому целесообразнее перенести или отобразить этот
файл в CLI, на Windows 10. Один из способов — отобразить
содержимое инструкции через веб-страницу, при доступе к WEB-L с
CLI.

По указанному пути должна быть доступна инструкция. Особое

внимание на используемый порт приложением.
Второй способ — скопировать инструкцию [Link] с WEB-L на CLI,
через scp с использованием настроенного ранее порта 2222.
 o Доступ к приложению должен быть защищен с применением
технологии TLS;
▪ Необходимо обеспечить корректное доверие
сертификату сайта, без применения “исключений” и
подобных механизмов;
o Незащищенное соединение должно переводится на защищенный
канал автоматически;
● Необходимо обеспечить отказоустойчивость приложения;
o Сайт должен продолжать обслуживание (с задержкой не более 25
секунд) в следующих сценариях:
▪ Отказ одной из ВМ Web

▪ Отказ одной из ВМ управления трафиком.

Ситуация с обеспечением «доверия» к сертификату сайта здесь

особая. Можно применить минимум усилий по настройке
сертификации (облегчённый вариант), но тогда этот единственный
подпункт задания не будет выполнен и по нему не засчитают 0,5
баллов (лол). Или же, при проведении более сложной настройки
сертификации (усложнённый вариант, нужно зубрить), задание будет
выполнено в полном объёме.

Облегчённый вариант.
Усложнённый вариант.
Копируем файлы в общедоступное хранилище на SRV, куда также
имеют доступ WEB-L и WEB-R.
Не перепутайте! crt - расширения сертификатов. csr - расширение
запросов на подпись сертификатов.
Теперь в браузере при вводе адреса [Link] должно
осуществляться корректное отображение содержимого веб-страницы,
без внесения сайта в исключения и т.п.

При желании, можно поэкспериментировать с вызовом функций из

файла [Link] или попробовать отключать по очереди веб-сервера
(WEB-L и WEB-R) и/или маршрутизаторы (RTR-L и RTR-R). Вызовы
функций должны без проблем работать, как и балансировка трафика
(включается в работу другой веб-сервер взамен выключенного).
P.S. По факту, пункты задания с «обеспечением отказоустойчивости
приложения» не являются выполненными. Вместо отказоустойчивости,
была реализована балансировка (в файле конфигурации default, в
nginx). Разница в том, что реализованный функционал балансировки
предназначен для равномерного распределения клиентских
подключений между WEB-L и WEB-R и не способен обеспечить
стабильный доступ к веб-сайту, если отключается один из
маршрутизаторов (RTR-L или RTR-R). Время простоя, в случае
отключения одного из маршрутизаторов — 35-60 секунд (больше
лимита в 25 секунд по заданию). Время простоя, в случае отключения
WEB-L или WEB-R — 15-20 секунд (меньше лимита; именно так и
нужно).
Реализованную балансировку на демо-экзамене вполне могут
засчитать как отказоустойчивость, если квалификация проверяющих
не очень высокая или если они готовы пойти на уступки. В остальном,
имеется риск потерять 1,2 балла.

P.P.S. К сожалению, пока отсутствуют варианты с реализацией

именно отказоустойчивости и именно в рамках задания. Если глубоко
разбираться с этим вопросом, то стоит, для начала, рассмотреть
работу ПО keepalived и traefik…