Демонстрационный экзамен компьютерные сети

DEMO2022-2023-linux-only

(Свободный проект альтруистов) 100% выполненное задание (публичный вариант) к демонстрационному экзамену по сетевому и системному администрированию. Полностью и только на Debian. Основано на первоисточнике: https://github.com/storm39mad/DEMO2022/tree/main/azure

В формате docx: Very Easy Linux.docx

Таблица 1. Характеристики ВМ

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

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

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

#(Если изначально доступна работа из под пользователя с обычными привилегиями, то повышение привилегий, то есть работа из под root, выполняется через команду sudo -i).

#На текущем этапе, пока что выполняется настройка имён хостов и IP-адресации.

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

#На демо-экзамене предоставляются ISO-образы с дополнительным ПО. Установка пакетов через них. Выход в реальный интернет не предоставляется.

#К примеру, на виртуальной машине RTR-L нужно установить необходимые по заданию пакеты. Для этого необходимо вмонтировать в VM один из ISO-образов и добавить его в source.list (необязательно все, только самый первый).

#Одновременно с добавлением образа в source.list, производится обновление списка доступных пакетов от каждого смонтированного образа.

#Если требуется установить ПО, связанные с которым пакеты находятся на нескольких образах, то в 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.

#Элементы команд полностью не нужно вписывать (кроме имён и цифр). Достаточно вбить начало команды (пример: ipv4.ad), как в терминале Cisco, и через нажатие на TAB произойдёт автодописывание (ipv4.addresses).

#Пример соответствует самой первой введёной строке:

nmc(TAB) co(TAB) mod(TAB) Wi(TAB) 1 ipv4.a(TAB) 5.5.5.1/24 ipv4.me(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.

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

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

1. Сети, подключенные к ISP, считаются внешними:
   • Запрещено прямое попадание трафика из внутренних сетей во внешние и наоборот;

#Сперва, нужно разрешить пересылку пакетов через устройства, осуществляющих маршрутизацию (RTR-L, ISP и RTR-R).

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

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

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

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

1. Между платформами должен быть установлен защищенный туннель, позволяющий осуществлять связь между регионами с применением внутренних адресов.
   • Трафик, проходящий по данному туннелю, должен быть защищен:
     • Платформа ISP не должна иметь возможности просматривать содержимое пакетов, идущих из одной внутренней сети в другую.
   • Туннель должен позволять защищенное взаимодействие между платформами управления трафиком по их внутренним адресам
     • Взаимодействие по внешним адресам должно происходит без применения туннеля и шифрования
   • Трафик, идущий по туннелю между регионами по внутренним адресам, не должен транслироваться.

#На RTR-L и RTR-R устанавливаем libreswan для работы IPsec (создание защищённого туннеля). Для его установки потребуется использовать два образа с ПО, монтируя и извлекая их поочерёдно, когда потребует этого установщик в debian.

#Сначала выполняется создание GRE-туннеля между RTR-L и RTR-R. После — настройка файрволла на ISP. Поверх туннеля — настройка IPsec.

IPsec

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

#Для большего удобства, лучше скопировать mytunnel.conf и mytunnel.secrets с RTR-L на RTR-R через scp, в аналогичную директорию.

#Дополнительная проверка работы IPsec. Запуск tcpdump на ISP, при оправке ICMP-запросов с RTR-R на RTR-L. На скрине ниже видно, что ICMP-запросы и ответы именуются иначе.

EIGRP или OSPF

#Для организации подключения виртуальных машин, имеющих адреса во внутренних сетях, к новосозданному туннелю и для связи стороны Left со стороной Right, нужно настроить один из протоколов маршрутизации (EIGRP или OSPF) с помощью frr.

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

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

1. Обеспечьте настройку служб SSH региона Left и Right:
   • Подключения со стороны внешних сетей по протоколу к платформе управления трафиком RTR-L на порт 2222 должны быть перенаправлены на ВМ Web-L;
   • Подключения со стороны внешних сетей по протоколу к платформе управления трафиком RTR-R на порт 2244 должны быть перенаправлены на ВМ Web-R;

#На WEB-L и WEB-R также необходимо настроить ssh на приём соединений из под root.

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

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

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

1. Выполните настройку первого уровня DNS-системы стенда:
   • Используется ВМ ISP;
   • Обслуживается зона demo.wsr
     • Наполнение зоны должно быть реализовано в соответствии с Таблицей 2;
   • Сервер делегирует зону int.demo.wsr на SRV;
     • Поскольку SRV находится во внутренней сети западного региона, делегирование происходит на внешний адрес маршрутизатора данного региона.
     • Маршрутизатор региона должен транслировать соответствующие порты DNS-службы в порты сервера SRV
   • Внешний клиент CLI должен использовать DNS-службу, развернутую на ISP, по умолчанию;

(Делегирование зоны — это не то же самое, что и создание slave-сервера! В нашем случае создаются два master-сервера!).

Таблица 2. DNS-записи зон (demo.wsr)

1. Выполните настройку второго уровня DNS-системы стенда;
   • Используется ВМ SRV;
   • Обслуживается зона int.demo.wsr;
     • Наполнение зоны должно быть реализовано в соответствии с Таблицей 2;
   • Обслуживаются обратные зоны для внутренних адресов регионов
     • Имена для разрешения обратных записей следует брать из Таблицы 2;
   • Сервер принимает рекурсивные запросы, исходящие от адресов внутренних регионов;
     • Обслуживание клиентов(внешних и внутренних), обращающихся к к зоне int.demo.wsr, должно производится без каких либо ограничений по адресу источника;
   • Внутренние хосты регионов (равно как и платформы управления трафиком) должны использовать данную DNS-службу для разрешения всех запросов имен;

Таблица 3. DNS-записи зон (int.demo.wsr)

#На SRV выполняются аналогичные шаги, вплоть до настройки apparmor. После apparmor — уже с дополнительными коррективами:

1. Выполните настройку первого уровня системы синхронизации времени:
   • Используется сервер ISP.
   • Сервер считает собственный источник времени верным, stratum=4;
   • Сервер допускает подключение только через внешний адрес соответствующей платформы управления трафиком;
     • Подразумевается обращение SRV для синхронизации времени;
   • Клиент CLI должен использовать службу времени ISP;

#Далее нужно зайти на CLI и синхронизировать время с ISP. Для начала, нужно любыми способами зайти в Панель Управления и выбрать «Дата и Время».

#Дополнительно, нужно включить автоматическую синхронизацию времени и даты. Делается это так же через Control Panel (Панель управления) -> Administrative Tools -> Services -> Windows Time. С ручного управления переключаем на автоматическое, запускаем сервис и применяем изменения.

#Примерно так должен выглядеть правильно настроенный сервис.

1. Выполните конфигурацию службы второго уровня времени на SRV
   • Сервер синхронизирует время с хостом ISP;
     • Синхронизация с другими источникам запрещена;
   • Сервер должен допускать обращения внутренних хостов регионов, в том числе и платформ управления трафиком, для синхронизации времени;
   • Все внутренние хосты(в том числе и платформы управления трафиком) должны синхронизировать свое время с SRV;

1. Реализуйте файловый SMB-сервер на базе SRV
   • Сервер должен предоставлять доступ для обмена файлами серверам WEB-L и WEB-R;
   • Сервер, в зависимости от ОС, использует следующие каталоги для хранения файлов:
     • /mnt/storage для система на базе Linux;
     • Диск R: для систем на базе Windows;
   • Хранение файлов осуществляется на диске (смонтированном по указанным выше адресам), реализованном по технологии RAID типа “Зеркало”;
2. Сервера WEB-L и WEB-R должны использовать службу, настроенную на SRV, для обмена файлами между собой:
   • Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux
     • Разделяемый каталог должен быть смонтирован по адресу /opt/share;
   • Каталог должен позволять удалять и создавать файлы в нем для всех пользователей;

#На SRV сначала нужно реализовать программно RAID 1 (Зеркало) на двух накопителях по 2 ГБ. Сами накопители уже имеются на SRV. Наличие и наименования накопителей проверяются командами fdisk -l или lsblk.

#Далее перезагружаем SRV командой reboot. После перезагрузки и входа из под root, перепроверяем наименование RAID-массива. Оно должно измениться.

Все последующие операции выполняются одинаково на WEB-L и WEB-R!

#После выполнения тех же действий на WEB-L, в качестве итоговой проверки следует создать нового пользователя (желательно на WEB-L и WEB-R), зайти из под него и попробовать создать, отредактировать и удалить файлы по пути /opt/share. Ограничений в действиях быть не должно.

1. (Один из возможных вариантов) Реализуйте файловый сервер на базе SRV
   • Сервер должен предоставлять доступ для обмена файлами серверам WEB-L и WEB-R;
   • Сервер, в зависимости от ОС, использует следующие каталоги для хранения файлов:
     • /mnt/storage для система на базе Linux;
     • Диск R: для систем на базе Windows;
   • Все созданные файлы в рамках обмена должны принадлежать одному специальному пользователю;
2. Сервера WEB-L и WEB-R должны использовать службу, настроенную на SRV, для обмена файлами между собой:
   • Служба файлового обмена должна позволять монтирование в виде стандартного каталога Linux;
     • Разделяемый каталог должен быть смонтирован по адресу /opt/share;
   • Каталог должен позволять удалять и создавать файлы в нем для всех пользователей;

#Именно в этом варианте условия задания кардинально отличаются от тех, что вариантом выше:

#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 минуты до завершения перезагрузки.

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

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

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

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

? (вопрос) — означает абсолютно любой один символ, один знак или одну цифру.

* (звезда) — означает абсолютно любое количество символов, знаков или цифр.

#То есть, запись root@192.168.100. * включает в себя связку из аккаунта root и диапазона адресов внутренней сети 192.168.100.0 — 192.168.100.255.

#Запись sshuser@?.?.?. * включает в себя связку из аккаунта sshuser и диапазонов адресов, которым соответствуют внешние сети в задании: 3.3.3.0 — 3.3.3.255, 4.4.4.0 — 4.4.4.255, 5.5.5.0 — 5.5.5.255.

#Запись * @192.168.100. * включает в себя связку из любых аккаунтов и диапазона адресов внутренней сети 192.168.100.0 — 192.168.100.255.

#Две части конфигурационного файла на 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.

1. Выполните настройку центра сертификации на базе SRV:
   • В случае применения решения на базе Linux используется центр сертификации типа OpenSSL и располагается по адресу /var/ca
   • Выдаваемые сертификаты должны иметь срок жизни не менее 500 дней;
   • Параметры выдаваемых сертификатов:
     • Страна RU;
     • Организация DEMO.WSR;
     • Прочие поля (за исключением CN) должны быть пусты;

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

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

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

1. Образ Docker (содержащий веб-приложение) расположен на ISO-образе дополнительных материалов;
   • Выполните установку приложения AppDocker0;
2. Пакеты для установки Docker расположены на дополнительном ISO-образе;
3. Инструкция по работе с приложением расположена на дополнительном ISO-образе;

#Если файл имеет расширение просто tar, то распаковывать его не нужно! Добавляем образ с расширением tar так же, в локальный docker-репозиторий по инструкции ниже.

#Порт сервера может быть другим, 80 например. На этом моменте нужно заострить внимание, иначе веб-страница на CLI не откроется!

1. Необходимо реализовать следующую инфраструктуру приложения.
   • Клиентом приложения является CLI (браузер Edge);
   • Хостинг приложения осуществляется на ВМ WEB-L и WEB-R;
   • Доступ к приложению осуществляется по DNS-имени www.demo.wsr;
     • Имя должно разрешаться во “внешние” адреса ВМ управления трафиком в обоих регионах;
     • При необходимости, для доступа к к приложению допускается реализовать реверс-прокси или трансляцию портов;

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

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

#Второй способ — скопировать инструкцию Readme.txt с WEB-L на CLI, через scp с использованием настроенного ранее порта 2222.

• Доступ к приложению должен быть защищен с применением технологии TLS;
  • Необходимо обеспечить корректное доверие сертификату сайта, без применения “исключений” и подобных механизмов;
• Незащищенное соединение должно переводится на защищенный канал автоматически;

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

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

Облегчённый вариант.

Усложнённый вариант.

#Копируем файлы в общедоступное хранилище на SRV, куда также имеют доступ WEB-L и WEB-R.

#Не перепутайте!

#crt — расширения сертификатов. csr — расширение запросов на подпись сертификатов.

#Теперь в браузере при вводе адреса https://www.demo.wsr должно осуществляться корректное отображение содержимого веб-страницы, без внесения сайта в исключения и т.п.

#При желании, можно поэкспериментировать с вызовом функций из файла Readme.txt или попробовать отключать по очереди веб-сервера (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. К сожалению, пока отсутствуют варианты с реализацией именно отказоустойчивости и именно в рамках задания.