Методические рекомендации по выполнению демонстрационного экзамена (компетенция "Сетевое и системное администрирование")

ПРЕДИСЛОВИЕ

Данные методические рекомендации созданы с целью проработки демонстрационного экзамена на базе примерного (образцового) задания по КОД 1.1 компетенции «Сетевое и системное администрирование».

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

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

ОБРАЗЕЦ ЗАДАНИЯ

Топология

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

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

● на основе предоставленных ВМ или шаблонов ВМ создайте отсутствующие виртуальные машины в соответствии со схемой:

– характеристики ВМ установите в соответствии с Таблицей 1;

– коммутацию (если таковая не выполнена) выполните в соответствии со схемой сети.

● имена хостов в созданных ВМ должны быть установлены в соответствии со схемой;

● адресация должна быть выполнена в соответствии с Таблицей 1;

● обеспечьте ВМ дополнительными дисками, если таковое необходимо в соответствии с Таблицей 1.

Сетевая связность

В рамках данного модуля требуется обеспечить сетевую связность между регионами работы приложения, а также обеспечить выход ВМ в имитируемую сеть «Интернет»:

● сети, подключенные к ISP, считаются внешними:

– запрещено прямое попадание трафика из внутренних сетей во внешние и наоборот;

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

– трансляция исходящих адресов производится в адрес платформы, расположенный во внешней сети.

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

– трафик, проходящий по данному туннелю, должен быть защищен: платформа ISP не должна иметь возможности просматривать содержимое пакетов, идущих из одной внутренней сети в другую;

– туннель должен позволять защищенное взаимодействие между платформами управления трафиком по их внутренним адресам: взаимодействие по внешним адресам должно происходит без применения туннеля и шифрования;

– трафик, идущий по туннелю между регионами по внутренним адресам, не должен транслироваться.

● платформа управления трафиком RTR-L выполняет контроль входящего трафика согласно следующим правилам:

– разрешаются подключения к портам DNS, HTTP и HTTPS для всех клиентов: порты необходимо для работы настраиваемых служб;

– разрешается работа выбранного протокола организации защищенной связи: разрешение портов должно быть выполнено по принципу «необходимо и достаточно»;

– разрешается работа протоколов ICMP;

– разрешается работа протокола SSH;

– прочие подключения запрещены;

– для обращений к платформам со стороны хостов, находящихся внутри регионов, ограничений быть не должно.

● платформа управления трафиком RTR-R выполняет контроль входящего трафика согласно следующим правилам:

– разрешаются подключения к портам HTTP и HTTPS для всех клиентов: порты необходимо для работы настраиваемых служб;

– разрешается работа выбранного протокола организации защищенной связи: разрешение портов должно быть выполнено по принципу «необходимо и достаточно»;

– разрешается работа протоколов ICMP;

– разрешается работа протокола SSH;

– прочие подключения запрещены;

– для обращений к платформам со стороны хостов, находящихся внутри регионов, ограничений быть не должно.

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

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

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

Инфраструктурные службы

В рамках данного модуля необходимо настроить основные инфраструктурные службы и настроить представленные ВМ на применение этих служб для всех основных функций:

● выполните настройку первого уровня DNS-системы стенда:

– используется ВМ ISP;

– обслуживается зона demo.wsr: наполнение зоны должно быть реализовано в соответствии с Таблицей 2;

– сервер делегирует зону int.demo.wsr на SRV: поскольку SRV находится во внутренней сети западного региона, делегирование происходит на внешний адрес маршрутизатора данного региона. Маршрутизатор региона должен транслировать соответствующие порты DNS-службы в порты сервера SRV;

– внешний клиент CLI должен использовать DNS-службу, развернутую на ISP, по умолчанию.

● выполните настройку второго уровня DNS-системы стенда:

– используется ВМ SRV;

– обслуживается зона int.demo.wsr: наполнение зоны должно быть реализовано в соответствии с Таблицей 2;

– обслуживаются обратные зоны для внутренних адресов регионов: имена для разрешения обратных записей следует брать из Таблицы 2;

– сервер принимает рекурсивные запросы, исходящие от адресов внутренних регионов: обслуживание клиентов (внешних и внутренних), обращающихся к зоне int.demo.wsr, должно производиться без каких-либо ограничений по адресу источника;

– внутренние хосты регионов (равно как и платформы управления трафиком) должны использовать данную DNS-службу для разрешения всех запросов имен.

● выполните настройку первого уровня системы синхронизации времени:

– используется сервер ISP;

– сервер считает собственный источник времени верным, stratum=4;

– сервер допускает подключение только через внешний адрес соответствующей платформы управления трафиком: подразумевается обращение SRV для синхронизации времени;

– клиент CLI должен использовать службу времени ISP.

● выполните конфигурацию службы второго уровня времени на SRV:

– сервер синхронизирует время с хостом ISP: синхронизация с другими источникам запрещена.

– сервер должен допускать обращения внутренних хостов регионов, в том числе и платформ управления трафиком, для синхронизации времени;

– все внутренние хосты (в том числе и платформы управления трафиком) должны синхронизировать свое время с SRV;

● реализуйте файловый SMB-сервер на базе SRV:

– сервер должен предоставлять доступ для обмена файлами серверам WEB-L и WEB-R;

– сервер, в зависимости от ОС, использует следующие каталоги для хранения файлов: /mnt/storage для системы на базе Linux. Диск R:\ для систем на базе Windows;

– хранение файлов осуществляется на диске (смонтированном по указанным выше адресам), реализованном по технологии RAID типа «Зеркало».

● сервера WEB-L и WEB-R должны использовать службу, настроенную на SRV, для обмена файлами между собой:

– служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux: каталог должен быть смонтирован по адресу /opt/share;

– каталог должен позволять удалять и создавать файлы в нем для всех пользователей.

● выполните настройку центра сертификации на базе SRV:

– в случае применения решения на базе Linux используется центр сертификации типа OpenSSL и располагается по адресу /var/ca;

– выдаваемые сертификаты должны иметь срок жизни не менее 500 дней;

– параметры выдаваемых сертификатов: страна RU. Организация DEMO.WSR. Прочие поля (за исключением CN) должны быть пусты.

Инфраструктура веб-приложения

Данный блок подразумевает установку и настройку доступа к веб-приложению, выполненному в формате контейнера Docker.

● образ docker (содержащий веб-приложение) расположен на iso-образе дополнительных материалов:

– выполните установку приложения AppDocker0.

● пакеты для установки Docker расположены на дополнительном ISO-образе;

● инструкция по работе с приложением расположена на дополнительном ISO-образе;

● необходимо реализовать следующую инфраструктуру приложения:

– клиентом приложения является CLI (браузер Edge);

–  хостинг приложения осуществляется на ВМ WEB-L и WEB-R;

– доступ к приложению осуществляется по DNS-имени www.demo.wsr: имя должно разрешаться во «внешние» адреса ВМ управления трафиком в обоих регионах. При необходимости, для доступа к к приложению допускается реализовать реверс-прокси или трансляцию портов;

– доступ к приложению должен быть защищен с применением технологии TLS: необходимо обеспечить корректное доверие сертификату сайта, без применения «исключений» и подобных механизмов;

– незащищенное соединение должно переводиться на защищенный канал автоматически.

● необходимо обеспечить отказоустойчивость приложения:

– сайт должен продолжать обслуживание (с задержкой не более 25 секунд) в следующих сценариях: отказ одной из ВМ Web. Отказ одной из ВМ управления трафиком.

Таблица 1: характеристики ВМ

Таблица 2: DNS-записи зон

ПРАКТИЧЕСКАЯ ЧАСТЬ

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

Думаю, не стоит дополнительно упоминать о том, что не стоит приступать к выполнению 3-й части методических рекомендаций без завершения 1- и 2-й части!

Запустите виртуальный стенд в VMware Workstation.

В данной части нам необходимо будет взаимодействовать с ПО Docker. Это программное обеспечение, предназначенное для виртуализации.

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

Подробнее можно прочитать здесь.

Первое, что необходимо сделать, после включения стенда, это зайти на WEB-L и установить сервер для балансировки нагрузки «nginx» и консольный браузер «lynx» с помощью команды «apt install ngnix lynx -y».

После установки необходимо убедиться, что nginx корректно установился и запустился. Вводим команду «systemctl status nginx».

Важной командой nginx является проверка конфигурации. Чтобы проверить правильность конфигурации, выполняем команду «nginx -t» и видим:

Как видно, с конфигурацией всё в порядке.

Теперь необходимо подключить другой BD-диск с Docker.

Для этого выключаем виртуальную машину WEB-L и нажимаем во вкладке «Hardware Configuration» на кнопку «Select disc image».

Откроется окно, в котором выбираем файл «docker_inst.iso» по пути «Database / ISO /». После – нажимаем кнопку «Select».

В настройках виртуальной машины WEB-L также необходимо убедиться, что выбранный нами диск подключен и на него поступает питание.

Диск подключен. Виртуальную машину WEB-L можно включить.

Теперь займёмся созданием директории, где будет храниться информация о Docker.

Заходим в виртуальную машину WEB-L и создаём директорию командой «mkdir /opt/docker». Также «примонтируем» диск, который мы только что подключили, по пути «mount /dev/cdrom /mnt/».

Можно посмотреть содержимое подключенного диска командой
«ls -l /mnt/».

Содержимое диска необходимо скопировать в ту папку, которую мы создали с вами выше. Делается это командой «cp /mnt/* /opt/docker/».

Копирование займёт некоторое время. По завершению можно убедиться, что всё было скопировано командой перехода в папку «cd /opt/docker» и выводом содержимого директории «ls».

На всякий случай «размантируем» диск командой «umount /mnt».

И займёмся установкой Docker-а с помощью пакетного менеджера «dpkg». Команда для установки: «dpkg -i containerd*».

Ту же процедуру повторяем для файлов с наименованием «docker-» с помощью команды «dpkg -i docker-*».

Убедимся в том, что Docker установился командой «docker info».

Как видно, Docker установлен и работает. Последующей задачей у нас станет последовательное выполнение команд для загрузки контейнера.

Выполняем следующие команды:

• «docker image load -i appdocker0.zip»;

• «docker image ls» позволяет нам убедиться, что наш контейнер был загружен;

• «docker run -d appdocker» и «docker ps» – данные команды позволяют запустить контейнер и посмотреть список запущенных контейнеров.

Теперь необходимо посмотреть, на каком IP-адресе запущен наш котейнер. Делается это командой «docker container inspect musing_ride».

Особое внимание обратите на наименование, которое идёт после слова «inspect». Данное наименование выбирается случайным образом для каждого контейнера. Поэтому ориентируйтесь на то имя, которое выводится у вас после выполнения команды «docker ps».

Для того, чтобы проверить, что наш контейнер взаимодействует с внешней средой, воспользуемся консольным браузером «lynx». Выполним следующую команду «lynx http://172.17.0.2:5000».

На что мне в командной строке высвечивается следующее сообщение:

То есть наш контейнер доступен и веб-сервер отрабатывает. Чтобы выйти со страницы в консоли, нажимаем «Ctrl+C».

Займёмся настройкой «nginx». Но прежде давайте посмотрим, что будет, если попытаться открыть «www.demo.wsr» в браузере на CLI без настройки.

Как и ожидалось, при попытке зайти на «www.demo.wsr» сервер «nginx» ответил нам страницей-заглушкой. Как минимум это означает, что сервер «nginx» работает и обрабатывает пользовательские запросы.

Для того, чтобы наш контейнер мог отвечать на пользовательские запросы, необходимо с помощью «nginx» связать данное доменное имя [«www.demo.wsr»] с IP-адресом контейнера.

Чтобы упростить конфигурирование файла «nginx», можно взять за основу стандартный и на его базе сделать то, что нам необходимо. Стандартный файл с конфигурацией лежит по пути «/etc/nginx/sites-enabled/».

Переименуем наш стандартный конфигурационный файл в «webapp.conf» с помощью команды «mv».

Открываем конфигурационный файл в редакторе «nano».

Видим следующую картину.

Вносим изменения.

Сохраняем конфигурационный файл. Не забываем проверить файл конфигурации на предмет ошибок командой «nginx -t».

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

Давайте убедимся, что контейнер доступен локально через localhost. Вводим команду «lynx http://localhost» и видим следующий результат.

Всё работает.

С WEB-L заканчиваем работать.

Переходим к настройке WEB-R. Фактически нам необходимо повторить те же самые действия, что и для WEB-L. В конфигурационном файле вписывается то же самое, что и для WEB-L.

После того, как вы закончите настройку WEB-R, можно будет зайти обратно на ПК CLI и заново зайти по URL «www.demo.wsr» и увидим уже несколько отличную картину, нежели мы видели до этого.

Также давайте проверим, что работает отказоустойчивость и в случае, если у нас выйдет один остров из строя, второй продолжит функционировать и приложение всё так же будет доступно. Чтобы это сделать, необходимо зайти на RTR-L-Deb и выключить интерфейс, который идёт к ISP.

Заходим на RTR-L-Deb и переходим в «nmtui».

Заходим во вкладку «Active a connection» и выключаем интерфейс к ISP.

После нажатия у вас исчезнет звёздочка. Заходите обратно на ПК CLI и смотрите, открывается ли сайт. Через небольшой промежуток времени сайт должен всё так же открываться. Если это действительно так, значит, отказоустойчивость сформирована на уровне DNS.

На этом выполнение 3-й части завершено.