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

10

ПРЕДИСЛОВИЕ

Данные методические рекомендации созданы с целью проработки демонстрационного экзамена на базе примерного (образцового) задания по КОД 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-записи зон

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

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

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

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

Начнём с настройки DNS на ВМ ISP. Однако прежде, чем выполнять какие-либо действия, убедитесь, что у Вас подключен DVD-диск к ВМ ISP.

Убедились, что диск подключен. Теперь устанавливаем модули, которые нам понадобятся: bind9, dnsutils, bind9utils и chrony. Делается это командой «apt install bind9 dnsutils bind9utils chrony -y».

Касаемо установленных нами утилит:

• bind9 – это полнофункциональный открытый DNS-сервер, имеющий широкое распространение. Подробнее читайте здесь, здесь и здесь;

• dnsutils – это пакет, который относится к bind9;

• bind9utils – набор утилит, применяемый при настройке bind9;

• chrony – это гибкая реализация протокола сетевого времени Network Time Protocol (NTP). Используется для синхронизации системных часов с различных NTP-серверов, эталонных часов или с помощью ручного ввода. Подробнее читайте здесь и здесь.

После установки необходимо убедиться, что сервис BIND работает. Делается это командой «systemctl status named».

Выйти из просмотра можно комбинацией клавиш «Ctrl+Z».

Начнём с настройки сервиса BIND. Открываем конфигурационный файл «named.conf.options» по пути «/etc/bind/» в редакторе nano.

И видим следующее.

Выполняем конфигурацию.

Итак, у нас присутствуют следующие параметры:

• listen-on в значении «any» означает, что наш DNS-сервер будет слушать все интерфейсы;

• recursion в значении «no» означает, что у нас не будет рекурсивных запросов;

Представьте ситуацию: у Вас есть DNS-сервер, к которому пришёл запрос на некоторый URL-адрес, которого у него нет в таблице записей DNS. Не найдя данный адрес у себя в таблице, он посылает к другому (корневому) DNS-серверу рекурсивный запрос, на который корневой DNS-сервер вернёт ответ типа «Обратись к DNS-серверу 1.1.1.1 – он знает». И тот DNS-сервер, который отправил рекурсивный запрос, обращается к 1.1.1.1, на что тот [1.1.1.1] возвращает IP-адрес, соответствующий искомому URL-адресу. Если непонятно, можете подробнее почитать об этом здесь.

• allow-query в значении «any» означает, что все устройства имеют возможность отправлять запросы нашему DNS-серверу;

• dnssec-validation в значении «no» означает, что не будет проверяться корректность предоставляемой DNS информации;

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

• listen-on-v6 в значении «no» означает, что прослушивание IPv6 не будет выполняться на всех интерфейсах.

Далее займёмся файлом конфигурации, который позволит указать зоны, которые у нас будут сформированы. Расположен по пути «/etc/bind/named.conf.local».

После открытия, видим следующее.

Формируем DNS-зону «demo.wsr».

Внутри зоны «demo.wsr» присутствуют 3 параметра:

• type в значении «master» означает, что наш DNS-сервер, установленный на ВМ ISP будет корневым;

• allow-transfer в значении «какой-нибудь IP-адрес» означает, что от нашего DNS-сервера информация о зоне «demo.wsr» будет передана тому IP-адресу(-ам), которые указаны в данном параметре;

• file в значении «путь к файлу зоны» указывает, где лежит файл с настройками для данной зоны «demo.wsr».

Теперь непосредственно создадим директорию для хранения файлов конфигурации зон – в нашем случае, зоны «demo.wsr» с помощью команды «mkdir /opt/dns».

После – скопируем в только что созданную директорию файл-шаблон конфигурации командой «cp /etc/bind/db.local /opt/dns/demo.wsr.zone». Также дадим права на чтения данного файла зоны командой «chmod 665 /opt/dns/demo.wsr.zone».

Но, помимо этого, также необходимо добавить право в apparmor, которое позволит читать файл зоны приложениями. Про apparmor можно почитать здесь.

Правило добавляем в файл конфигурации «usr.sbin.named» по пути «/etc/apparmor.d/» через редактор nano.

Видим следующее.

Большое количество пунктов. Здесь необходимо добавить пункт-разрешение для конкретного пути с конкретными правами.

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

Перезапускаем сервис apparmor.

Переходим к редактированию файла зоны «demo.wsr».

Видим шаблон.

В этом шаблоне выполняем конфигурацию. Конфигурация выполняется в соответствии с таблицей 2.

Рассмотрим каждый из пунктов, который присутствует в файле зоны:

• serial – это серийный номер зоны, при каждом изменении данных мы должны увеличивать серийный номер, по его изменению вторичные сервера понимают, что произошли изменения и начинают синхронизацию;

• refresh – это период обновления данных вторичными серверами, по истечении данного времени они повторно запрашивают у основного сервера SOA-запись и анализируют серийный номер;

• retry – периодичность повторного обращения к основному серверу, если предыдущая попытка завершилась неудачей;

• expire – максимальное время жизни зоны на вторичных серверах при отсутствии синхронизации с основным, по истечении этого времени вторичный сервер перестает обслуживать запросы;

• negative cache TTL – время жизни негативного кэша или минимальное время жизни записи. Применяется для кеширования неудачного результата запроса со стороны клиента, например, обращение к несуществующему доменному имени.

Все значения каждого из пунктов остаётся таким же, каким оно и было в шаблоне!

После сохранения файла зоны обязательно необходимо проверить корректность того, что мы вписали. Сделать это можно с помощью команды «named-checkconf -z».

Если у Вас выглядит результат вывода примерно так же, как и у меня, значит, синтаксических ошибок выявлено не было. Теперь перезапустим службу BIND («systemctl restart named») и посмотрим состояния после перезагрузки («systemctl status named»).

Проверим работу доменных имён командами:

• host www.demo.wsr;

• host internet.demo.wsr;

• host isp.demo.wsr.

Также проверим со стороны клиента (ВМ CLI) работоспособность DNS-сервера. Заходим на виртуальную машину CLI, открываем командную строку и вводим команду «nslookup www.demo.wsr».

Как видно, всё работает. Основной DNS-сервер на ISP у нас настроен. Осталось настроить внутренний (internal) DNS-сервер на SRV-Win.

Заходим на SRV-Win и открываем вкладку инструментов «DNS».

У нас откроется окно «DNS Manager», внутри которого необходимо зайти на SRV / Forward Lookup Zones / int.demo.wsr.

Нам необходимо создать обратную зону. Про обратные зоны можно почитать здесь.

Нажимаем правой кнопкой мыши на Reverse Lookup Zones и выбираем пункт «New Zone…».

У нас откроется окно «New Zone Wizard».

Нажимаем «Next».

Нажимаем «Next».

Нажимаем «Next».

Нажимаем «Next».

Первая обратная зона у нас будет 192.168.100.

Нажимаем «Next».

Нажимаем «Next» и, наконец, «Finish».

По аналогии с 1-й зоной создаём 2-ю. Только обратной зоной у нас будет не 192.168.100, а зона – 172.16.100. По итогу получится следующее.

Обратные зоны созданы. Теперь займёмся наполнением зоны «int.demo.wsr».

Правой кнопкой мыши нажимаем во вкладке «int.demo.wsr» и создаём новую запись.

Добавляем запись об WEB-L.

Добавляем запись об WEB-R.

Добавляем запись об RTR-L.

Добавляем запись об RTR-R.

Осталось добавить CNAME-ы.

Добавляем запись CNAME для NTP. FQDN добавляется через кнопку «Browse…»: SRV / Forward Lookup Zones / int.demo.wsr / srv.

Добавляем запись CNAME для DNS.

По итогу получится такой перечень записей.

Следующим действием необходимо указать, у кого мы будем запрашивать информацию о зоне «demo.wsr».

Правой кнопкой в окне «DNS Manager» нажимаем на SRV и выбираем пункт «Properties».

Далее выбираем вкладку «Forwarders» и нажимаем кнопку «Edit».

В окне «Edit Forwarders» Вы увидите 3 записи. Удалите их с помощью кнопки «Delete», поочерёдно нажав на каждую из записей. Затем – добавьте запись 3.3.3.1.

И нажмите «ОК».

Нажимаем «Apply» и «ОК».

На всякий случай перезапустим DNS-сервис.

Теперь необходимо проверить работоспособность нашего DNS-сервера. Зайдём на WEB-L и пропишем следующие команды:

• host www.demo.wsr;

• host srv.int.demo.wsr;

• host web-l.int.demo.wsr;

• host web-r.int.demo.wsr.

То же самое сделаем и со стороны WEB-R:

• host www.demo.wsr;

• host srv.int.demo.wsr;

• host web-l.int.demo.wsr;

• host web-r.int.demo.wsr.

Настройка DNS-серверов на этом завершена.

Переходим к настройке NTP-сервера. Заходим на ВМ ISP. Помните о том, что chrony уже была установлена. Убедиться в том, что это действительно так и сервис работает, можно командой «systemctl status chrony».

Займёмся файлом конфигурации chrony. Файл называется «chrony.conf» и лежит по пути «/etc/chrony/». Как обычно, открываем через nano.

И видим следующий результат.

Часто строчек закомментируем (выделены красным), а у одной из них убираем комментарий (подчёркнуто синим).

Дописываем в конфиг настройки.

И листам ниже с помощью стрелочки вниз на клавиатуре. Ниже необходимо закомментировать пару строчек (выделено красным) и изменить значения у свойства «makestep» (подчёркнуто синим), которое отвечает за количество времени в секундах (10) и количество попыток, выполняемых за это количество времени (30).

После внесения изменений сохраняем файл конфигурации комбинацией клавиш «Ctrl+X», нажимаем «Y» и «Enter».

А дальше, как обычно, перезапускаем сервис [так как мы внесли изменения] и проверим состояние командами «systemctl restart chrony» и «systemctl status chrony».

Теперь выставим на ВМ ISP время по Москве:

• командой «date» смотрим текущее время;

• командой «timedatectl set-timezone Europe/Moscow» выставляем в качестве часового пояса Москву;

• и повторно смотрим текущее время командой «date».

Как видно, время поменялось.

Теперь зайдём на ВМ CLI и выполним синхронизацию с нашим сервером времени, установленном на ВМ ISP.

Открываем параметры времени.

Во вкладке «Date & time» листаем вниз и нажимаем на пункт «Date, time & regional formatting».

Далее листаем в самый низ и нажимаем «Additional date, time & regional settings».

В открывшемся окне «Clock and Region» нажимаем «Set the time and date».

В открывшемся окне заходим на вкладку «Internet Time» и нажимаем кнопку «Change settings…».

Указываем, что мы будем синхронизироваться с 3.3.3.1 и нажимаем кнопку «Update now».

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

Нажимаем «ОК» и ещё раз «ОК».

Теперь можно зайти на ВМ ISP и посмотреть, появился ли у нас клиент. Вписываем команду «chronyc clients».

И видим, что, действительно, у нас появился клиент 3.3.3.10.

Теперь необходимо настроить синхронизацию SRV-Win с ISP для того, чтобы SRV-Win имел возможность всем остальным раздавать время.

Настройка NTP в Windows Server будет выполнена через групповые политики.

В открывшемся окне заходим в Forest: int.demo.wsr / Domains / int.demo.wsr / Group Policy Objects / Default Domain Controllers Policy.

Нажимаем право кнопкой мыши на «Default Domain Controllers Policy» и выбираем пункт «Edit».

В новом окне заходим во вкладку Policies / Administrative Templates / System и скролим в самый низ вкладки «System».

Там находим папку «Windows Time Service» и вложенную папку «Time Providers», внутри которой находится 3 настройки.

Включим Windows NTP Server. Для этого кликаем дважды по настройке «Enable Windows NTP Server» и в окне выбираем пункт «Enable», после чего нажимаем «Apply» и «ОК».

Также включаем настройку «Enable Windows NTP Client».

Осталось 3-е правило – «Configure Windows NTP Client». Дважды кликаем на него, включаем пунктом «Enable».

После этого возвращаемся в окно Group Policy Management и применяем нашу политику.

Затем открываем командную строку и вписываем команду «gpupdate /force» и нажимаем клавишу «Enter».

Проверим сервис времени «Windows Time» для того, чтобы он запускался вместе с операционной системой.

В списке сервисов ищем «Windows Time».

Дважды кликаем на него и проверяем, что он автоматически запускается «Startup type: Automatic» и что сервис запущен «Service status: Running».

Теперь можно проверить, появился ли новый клиент у ISP командой «chronyc clients».

Появился 4.4.4.100. Теперь займёмся настройкой WEB-L в качестве клиента.

Устанавливаем chrony на WEB-L.

Заходим в конфиг chrony.

И видим знакомый нам конфиг.

Редактируем конфиг как на рисунке ниже.

Теперь непосредственно выполняем конфигурацию WEB-L как клиента.

Здесь мы указываем, что в качестве сервера у нас выступает «srv.int.demo.wsr». Можно указать и IP-адрес, но, поскольку у нас DNS функционирует, мы воспользуемся доменным именем. Слово «prefer» указывает на то, что данный сервер является предпочитаемым, поскольку у нас может быть несколько NTP-серверов; слово «iburst», в свою очередь, говорит о том, что необходимо отправить несколько пакетов. Это повышает точность.

Сохраняем конфиг с помощью клавиш «Ctrl+Z», нажимаем «Y» и «Enter».

После выполненной конфигурации перезагружаем службу chrony («systemctl restart chrony») и проверяем состояние («systemctl status chrony»).

Также можно посмотреть ресурсы, от которых мы получаем время командой «chronyc sources».

Если возле IP-адреса звёздочка «*», это означает, что синхронизация выполнена. Если же вместо звёздочки восклицательный знак «!», то синхронизация не была выполнена. Вероятно, допущена ошибка в конфигурации или проблемы на стороне NTP-сервера.

Не забываем также изменить временную зону командой «timedatectl set-timezone Europe/Moscow».

Можно посмотреть на время у ISP и WEB-L и увидеть, что они идентичны.

Настройка WEB-L как клиента завершена.

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

Получение данных от NTP-сервера к RTR-L-Deb.

Временная зона была переведена. Проверяем время.

Настройка RTR-L-Deb как клиента завершена.

Теперь займёмся настройкой WEB-R в качестве клиента. Опять-таки, настройка идентична той, которую мы выполняли для WEB-L и RTR-L-Deb.

Получение данных от NTP-сервера к RTR-R-Deb.

Временная зона была переведена. Проверяем время.

Настройка RTR-R-Deb как клиента завершена.

Теперь займёмся настройкой WEB-R в качестве клиента.

Получение данных от NTP-сервера к WEB-R.

Временная зона была переведена. Проверяем время.

Настройка WEB-R как клиента завершена.

Теперь займёмся общедоступными ресурсами. На SRV-Win необходимо организовать сетевой ресурс, который будет доступен как WEB-L, так и WEB-R. Взаимодействие будет организовано с помощью пакета CIFS. По требованию (заданию) в качестве общего сетевого ресурса должны выступать два диска по 2 ГБ, объединённых в RAID 1.

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

О технологии RAID и её уровнях можно почитать здесь.

Прежде, чем выполнять какие-либо действия в SRV-Win, убедитесь, что два диска по 2 ГБ добавлены к вашей виртуальной машине.

Если таковых нет, то необходимо зайти в настройки виртуальной машины в гипервизоре.

И непосредственно добавить диски во вкладке «Add hark disk».

После того, как Вы убедились, что диски добавлены, необходимо в SRV-Win создать RAID 1. Для этого необходимо зайти в «Disk Management».

В поисковой строке вписываем «create» и выбираем «Create and format hard disk partitions».

Или через командную строку запускаем оснастку «diskmgmt.msc».

Откроется окно «Disk Management», в котором Вы должны увидеть две неразмеченной области.

Далее необходимо каждый из дисков перевести в режим «Online». Нажимаем правой кнопкой на любой из дисков и выбираем пункт «Online».

После этой операции наши диски перешли в неинициализированное состояние. Это необходимо поправить и всё так же нажать правой кнопкой на любой из дисков и выбрать пункт «Initialize Disk».

Появится окно, в котором будет выбраны неинициализированные диски. Ничего менять не нужно и просто нажимаем «ОК».

Теперь необходимо их объединить в RAID 1. Опять кликаем на любой из дисков правой кнопкой мыши и выбираем пункт «New Mirrored Volume».

Откроется окно, в котором нажимаем «Next».

На следующем этапе необходимо добавить 2-й диск: отмечаем диск в левой области и нажимаем кнопку «Add».

Получится так.

Нажимаем «Next» и видим, что нам необходимо выбрать букву для диска. Букву выбираем в соответствии с тем, что сказано в самом задание! В моём случае это буква «R».

Нажимаем «Next» и удаляем оставляем пустым поле «Volume label».

Нажимаем «Next» и «Finish». После этого выскочит окно:

Нажимаем «Yes».

Через небольшой промежуток времени мы увидим в окне «Disk Management» такой результат.

Открываем проводник на SRV-Win и видим, что диск действительно появился.

Заходим на него и создаём папку с наименованием «Share». После создания папки необходимо предоставить удалённый доступ к данной папке.

Добавляем «Administrator», если такового нет. И даём возможность как, читать, так и удалять файлы. И нажимаем «Share».

В новом окне нажимаем «Done».

Заходим в Server Manager / File and Storage Services / Shares и видим, что наша папка появилась в списке общих ресурсов.

С SRV-Win закончили. Перейдём к настройке WEB-L.

Начать необходимо с установки пакета CIFS командой «apt install cifs-utils».

Создадим папку «share» в директории «/opt/» командой «mkdir /opt/share» и перейдём в созданную папку «cd /opt/share».

Выполним монтирование сетевого ресурса в созданную папку командой «mount.cifs //srv.int.demo.wsr/share /opt/share -o user=Administrator,password=P@ssw0rd».

Необходимо проверить, что монтирование выполнено успешно. Для этого в папке «share» создадим какой-нибудь текстовый файл командой «touch test.txt».

Переходим на SRV-Win, чтобы убедиться в том, что файл появился в директории «share».

Как видно, файл действительно появился. Тем не менее, нам ещё необходимо отредактировать файл «fstab» в директории «/etc/», который содержит информацию о подключенных дисках и прочем.

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

Открываем конфигурационный файл fstab.

Видим следующее.

Дописываем конфиг.

Сохраняем конфиг комбинацией «Ctrl+X», нажимаем «Y» и «Enter».

И выполняем монтирование командой «mount -a».

Чтобы убедиться, что всё корректно отрабатывает, можно перезапустить WEB-L командой «reboot». После перезагрузки, выполнить команду «ls -l /opt/share» и убедиться, что созданный нами файл на месте. То есть монтирование выполняется.

Теперь выполняем ровно те же действия на WEB-R.

В конечном результате у Вас должно выйти то же самое. После выполнения проверяем на наличие файла – и действительно, всё есть.

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

Отображение на WEB-L.

И на SRV-Win.

Как видно, всё успешно работает. На этом вторая часть завершена.