11
ПРЕДИСЛОВИЕ
Данные методические рекомендации созданы с целью проработки демонстрационного экзамена на базе примерного (образцового) задания по КОД 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-записи зон
ПОДГОТОВИТЕЛЬНЫЙ ЭТАП
Чтобы приступить к выполнению задания, необходимо выполнить предварительные приготовления. В предварительные приготовления входят как выделение ресурсов под виртуальный стенд, так и установка программного обеспечения, которое понадобится в ходе выполнения задания.
Во-первых, необходимо убедиться, что у Вас есть порядка 350 ГБ свободного пространства на накопителе в компьютере. Если нет, то необходимо освободить место: образ виртуального стенда весит 100 ГБ, установленный виртуальный стенд – 250 ГБ. Также у Вашего ПК должно быть на борту не менее 8 ГБ оперативной памяти и (обязательно) включён файл подкачки. Если да, то необходимо зайти на сайт http://39.s300v4.ru:8088/demo/index.html и поставить на скачивание образ (см. ниже).
Скачивание образа виртуального стенда занимает немало времени, поэтому настоятельно рекомендую сделать это заблаговременно.
Во-вторых, необходимо установить на компьютер ПО для работы с виртуальными машинами и образами – VMware Workstation (данное ПО прикладывается в комплекте вместе с данными методическими рекомендациями).
После того, как образ виртуального стенда будет скачан, необходимо открыть этот образ в VMware Workstation (см. ниже).
Откройте VMware Workstation и нажмите кнопку «Open a Virtual Machine».
Откройте место, куда был скачан образ виртуального стенда, и выберите файл «demo-v0.4.ova».
Когда Вы откроете файл, у Вас выскочит окно импортирования образа, внутри которого необходимо указать место, куда будет импортироваться виртуальный стенд и его наименование. Напоминаю, что место, куда Вы будет импортироваться виртуальный стенд, должно иметь свободного пространства порядка 250 ГБ.
Далее – нажмите кнопку «Import» и ожидайте. Импортирование виртуального стенда требует времени.
ПРАКТИЧЕСКАЯ ЧАСТЬ
Перед тем, как Вы приступите к практической части, убедитесь, что все действия, изложенные в подготовительном этапе, были успешно выполнены и образ установился.
Запустите виртуальный стенд в VMware Workstation. Загрузка стенда занимает около минуты. Когда стенд загрузится, Вы увидите следующее.
В окне Вас интересует строка с IP-адресом. Последующие действия будут выполняться в веб-браузере. В моём случае это – Yandex Browser, в вашем – это может быть любой удобный для Вас веб-браузер.
Откройте браузер и впишите в строке запроса [там, где указывается URL сайта] IP-адрес, который отображается у Вас в VMware Workstation.
Откроется среда в браузере, с помощью которой Вы будете выполнять настройку вашего стенда.
VMware ESXi – это программный гипервизор, который используется в качестве платформы для создания и управления виртуальными машинами. Именно на базе данной платформы реализован стенд демонстрационного экзамена.
Более подробно можно о VMware ESXi почитать здесь.
При работе в гипервизоре, необходимо авторизоваться. Логин: root. Пароль: P@ssw0rd.
После авторизации у Вас откроется стенд. Здесь Вас интересует вкладка «Virtual Machines».
В этой вкладке отображены все виртуальные машины, установленные в стенде. Однако не со всеми ними необходимо взаимодействовать.
Так, к примеру, виртуальные машины RTR-L-Csr и RTR-R-Csr не используются, если Вы выполняете настройку RTR-L и RTR-R на Debian. В противном случае, если Вы выполняете настройку RTR-L и RTR-R на Cisco, то как раз-таки виртуальные машины RTR-L-Csr и RTR-R-Csr будут использоваться.
Поскольку большинство виртуальных машин не имеют интерфейса, а лишь командную оболочку, то следует начинать настройку с самой медленной машины – SRV-Win.
Нажимаем на виртуальную машину SRV-Win и нажимаем на кнопку «Power on», чтобы запустить её.
Скорость загрузки той или иной виртуальной машины зависит исключительно от Вашего персонального компьютера. После загрузки Вы увидите, что SRV-Win «свеженькая», поскольку требует начальной настройки.
Изначально регион и язык по умолчанию выбраны как США/Английский. Регион и язык не играет роли в настройке, поэтому можете оставить по умолчанию или поменять на Россия/Русский.
Нажимайте «Next», после – принимайте лицензионное соглашения и необходимо будет указать пароль для учётной записи администратора. Пароль укажите: P@ssw0rd.
Нажимайте «Finish» и ждите, пока Windows инициализируется. После завершению инициализации у Вас выскочит экран блокировки.
Чтобы ввести пароль, необходимо воспользоваться комбинацией клавиш «Ctrl+Alt+Delete». Отправить её можно через вкладку Actions / Guest OS / Send keys / Ctrl-Alt-Delete.
Введите пароль P@ssw0rd и Вы попадёте внутрь виртуальной машины.
Прежде, чем выполнять какую-либо настройку SRV-Win, на всякий случай выполним сброску счётчика времени использования операционной системы.
Для этого запускаем командную строку с правами администратора.
В командной строке прописываем команду «slmgr -rearm» и нажимаем «Enter».
Команда была выполнена успешно.
Теперь зададим имя SRV-Win. Для этого в «Server Manager» и нажимаем на вкладку «Local Server» и видим поле «Computer name», справа от которого – текущее наименование компьютера. Нажимаем на текущее наименование.
Нажимаем кнопку «Change» и вписываем в поле «Computer name» наименованием «SRV». Подтверждаем с помощью кнопки «ОК».
Но перезагружать компьютер для применения изменений пока не нужно! Попутно настроим IP-адрес у машины. Правой кнопкой нажимаем на значок Интернет-соединения и выбираем пункт «Open Network & Internet settings». У нас откроется окно «Settings».
Во вкладке «Status» нажимаем на пункт «Change adapter options». У нас откроется ещё одно окно «Network Connections». Там будет сетевой адаптер «Ethernet0». Дважды кликаем на него, нажимаем кнопку «Properties».
В списке заходим строчку «Internet Protocol Version 4 (TCP/IPv4)» и, опять-таки, дважды кликаем. Вводим данные в соответствии с таблицей 1 (см. выше).
Я здесь намеренно упускаю информацию о том, какой именно IP-адрес и шлюз необходимо будет ввести. Так как задание демоэкзамена может поменяться, а вместе с ним и IP-адреса, которые необходимо ввести. Поэтому при назначении IP-адресов и шлюзов всегда ориентируйтесь на таблицы, которые будут Вам предоставлены!
После этого нажимаем «ОК» и ещё раз «ОК».
Теперь необходимо установить домен. Чтобы это сделать, открываем обратно «Server Manager» и во вкладке «Manage» выбираем пункт «Add Roles and Features Wizard».
В открывшемся окне нажимаем «Next» до тех пор, пока не попадём на этап «Server Roles». Здесь необходимо выбрать роли, которые будет реализовывать SRV-Win.
Выбираем «AD DS» и «DNS Server».
Узнать, что такое AD DS можно здесь и здесь.
Узнать, что такое DNS Server можно здесь.
Кликаем «Next» до этапа «Confirmation».
На данном этапе включаем пункт «Restart the destination server automatically if required» и нажимаем кнопку «Install».
Установка займёт некоторого время.
Когда всё установится, перезагрузите виртуальную машину SRV-Win.
После перезагрузки появится оповещение в «Server Manager», которое попросит SRV-Win повысить до уровня контроллера домена.
В «Server Manager» нажимаете на флажок, возле которого появился треугольник восклицательным знаком, и кликните по строке «Promote this server to a domain controller».
Если восклицательный знак не появляется, то подождите некоторое время или нажмите на кнопку обновить, которая находится слева от флажка.
После нажатия на строку, у нас откроется окно «Active Directory Domain Services Configuration Wizard». Там выбираем пункт «Add a new forest», то есть мы создаём новый лес, внутри которого у нас будет корневой домен. Домен называем: int.demo.wsr.
Нажимаем кнопку «Next».
Далее у нас попросят указать пароль: P@ssw0rd.
Нажимаем «Next». Потом ещё раз «Next».
На этапе «Additional Options» необходимо подождать некоторое время. Поле «The NetBIOS domain name» заполнится автоматически. Должно появится «INT».
Кликаем «Next» до тех пор, пока не попадём на вкладку «Installation». На ней мы нажимаем кнопку «Install». Установка займёт некоторое время, после чего виртуальная машина автоматически перезагрузится.
Пока идёт перезагрузки SRV-Win, можно запустить виртуальную машину CLI и выполнить начальную инициализацию.
Имя пользователя: User. Пароль: P@ssw0rd.
После инициализации у нас отобразится пустой рабочий стол. Нажимаем правой кнопкой на иконку «Пуск» и выбираем пункт «System». Откроется окно с настройками, в котором необходимо кликнуть по кнопку «Rename this PC».
Задаём в качестве имени «CLI» и нажимаем кнопку «Next».
Операционная система предложит перезапустить ПК, однако нажмите «Restart later», так как необходимо ещё настроить TCP/IP.
По аналогии с SRV-Win заходим в те же вкладки и указываем IP-адрес, маску, шлюз и DNS-сервер.
Нажимаем «ОК» и ещё раз «ОК».
Теперь CLI можно перезапустить.
Вернёмся на SRV-Win и посмотрим, что поменялось после перезагрузки. Когда Вы попытаетесь авторизоваться, то сразу увидите, что учётная запись администратора находится в домене. Так и должно быть.
Пока с настройкой SRV-Win закончили.
Займёмся SSH. Для начала включим виртуальные машины, на которых будет производиться настройка: RTR-L и RTR-R, WEB-L и WEB-R.
Выделили виртуальные машины и нажимаем кнопку «Power on».
Начнём с WEB-L. Для входа в учётную запись используется логин root и пароль toor. То же самое касается и всех остальных учётных записей на Debian.
После авторизации необходимо зайти в файл для конфигурации SSH. Это делается для того, чтобы дать разрешение на подключение по SSH.
С помощью редактора «nano» открываем файл «ssh_config» по пути «/etc/ssh/».
Выполнив команду, откроется конфигурационный файл, внутри которого необходимо найти строку «#PermitRootLogin».
И меняем её в соответствии с тем, как показано на рисунке выше.
Чтобы сохранить изменения в файле, необходимо воспользоваться комбинацией клавиш «Ctrl+X», после нажимаем «Y» и «Enter».
Выполняем перезапуск службы SSH для того, чтобы изменения, внесённые в конфиг, вступили в силу. Команда: systemctl restart ssh.
Чтобы убедиться в правильности выполнения действий, после перезагрузки службы SSH мы должны получить возможность подключаться по SSH сами к себе.
На изображении выше можно увидеть, что была выполнена команда «ssh root@localhost» – подключение по SSH к самому себе. Затем у меня спрашивает операционная система, хочу ли я продолжить подключение, на что я отвечаю «yes». После – ввожу пароль toor. Обратите внимание, что при написании пароля это никак не отображается.
Введя пароля, я увижу, что произошло подключение. Дополнительно в этом можно убедиться с помощью команды «w», где отобразятся активные пользователи. Удалённые пользователи отображаются в том числе.
Чтобы завершить SSH-сессию, можно написать «exit», либо нажать комбинацию клавиш «Ctrl+D».
Те же самые действия повторяются для WEB-R и RTR-R.
Для того, чтобы организовать связь между разными сегментами сети, необходимо включить маршрутизацию на маршрутизаторах, в качестве которых выступают ВМ RTR-L-Deb, RTR-R-Deb и ISP.
Заходим на RTR-L-Deb. Авторизуемся и вписываем команду «nano /etc/sysctl.conf».
У нас откроется конфиг, внутри которого необходимо будет раскомментировать строчку.
Сохраняем. Комбинация клавиш «Ctrl+X», нажимаем «Y» и «Enter».
Чтобы подтвердить изменения, прописываем команду «sysctl -p».
Те же действия повторяем на ВМ RTR-R-Deb и ISP.
Далее займёмся настройкой IP-адресов на виртуальных машинах. Чтобы иметь возможность настраивать IP-адреса, маску и шлюзы с помощью маломальского интерфейса, необходимо будет установить пакет «network-manager», который устанавливается с DVD-диска, который должен быть подключен к виртуальной машине.
Открываем виртуальную машину WEB-L и смотрим, подключен ли у нас DVD-диск или нет.
Как видно, подключенных DVD-дисков у нас нет, поэтому необходимо поправить данную ситуацию. Выключаем WEB-L и нажимаем на кнопку «Actions», внутри которой выбираем пункт «Edit settings».
У нас откроется окно, внутри которого мы получаем возможность редактировать виртуальную машину. Нас интересует вкладка «CD/DVD Drive».
В ней выбираем из выпадающего списка «Datastore ISO file». Откроется ещё одно окно с ISO-образами. Там заходим в папку ISO и выбираем первый DVD-диск.
После чего нажимаем кнопку «Select».
Не забудьте подключить данный диск «Connect» и предоставить ему питание «Connect at power on».
И нажимаем кнопку «Save».
Запускаем виртуальную машину WEB-L и вписываем команду
«apt-cdrom add».
Затем обновляем индекс с помощью команды «apt update».
Теперь можно установить «network-manager» c помощью команды «apt install network-manager -y».
После установки можно открыть «network-manager» для того, чтобы настроить IP-адрес и прочее.
Также о «nmtui» можно посмотреть здесь.
Вписываем команду «nmtui» и видим следующий интерфейс.
Нажимаем «Enter» на пункте «Edit a connection» и вписываем следующее.
Нажимаем «ОК».
Чтобы применить настройки, необходимо выйти из «Edit a connection» и зайти во вкладку «Active a connection» и там выбрать тот «Profile name», который мы только что отредактировали и дважды на нём нажать «Enter».
Тут внимательно: поскольку профиль один, то и дважды Enter можно спокойно нажать. Если бы здесь было несколько профилей, нужно было бы внимательно это делать, так как при включении/выключении позиция курсора сбрасывается на первый элемент.
Также задаём наименование в соответствии с таблицей 1.
Чтобы убедиться в том, что настройки были применены, можно выйти из «nmtui» и выполнить 2 команды: «hostname» (выводит имя пользователя) и «ip add» (выводит интерфейсы и настройки этих самых интерфейсов).
Для WEB-R выполняем такое же подключение DVD-диска и установку «network-manager», как и у WEB-L.
Однако заострим внимание на настройке TCP/IP.
Также не забудьте выключить и включить интерфейс, а также задать наименование машины – WEB-R.
Проверяем.
Для ISP выполняем такое же подключение DVD-диска и установку «network-manager», как и у WEB-L и WEB-R.
Заходим в «nmtui» и видим уже не один, как было у WEB-L и WEB-R, а целых три интерфейса, которые необходимо настроить.
Данный этап является крайне важным, поскольку, если перепутать интерфейсы, стенд работать не будет либо частично, либо полностью.
Чтобы разобраться в том, какой интерфейс куда смотрит, необходимо в гипервизоре открыть ВМ ISP и развернуть все вкладки «Network adapter» и открыть любой из интерфейсов в «nmtui».
Я открыл интерфейс с наименованием «Wired connection 3». В пункте «Device» я вижу номер интерфейса и его MAC-адрес. Смотря в гипервизоре во вкладке «Network Configuration» на поля «Network adapter», я могу определить, какой из адаптеров к чему подключен.
Для меня интерфейс «Wired connection 3» соответствует соединению от ISP к CLI. Соответственно, зная направленность соединения, я могу корректно назначить IP-адреса, маски подсети, шлюзы и DNS. Поэтому настоятельно рекомендую на данном этапе быть наиболее внимательными!
По итогу получается следующая картина и адресация.
От ISP к RIGHT:
От ISP к LEFT:
От ISP к CLI:
Не забудьте выключить и включить каждый из интерфейсов для того, чтобы настройки применились! А также не забудьте назначить наименование – ISP.
Теперь необходимо убедиться, что всё настроено корректно и маршрутизация для каждой из сетей отработала.
Делается это с помощью команды «ip route» на ВМ ISP.
Если у Вас вывод отличается: к примеру, количество путей меньше – внимательно перепроверьте вышеизложенные действия.
Переходим к настройке RTR-L-Deb. Как и прежде, подключаем DVD-диск и устанавливаем «network-manager».
После установки и открытия «nmtui», можно заметить, что у нас несколько интерфейсов. То есть процедуру идентификации направления необходимо повторить.
Открываю интерфейс «Wired connection 2» и вижу, что MAC-адрес идентичен тому, что и у «Network adapter 2», которые формирует соединение с ISP.
В соответствии с таблицей 1 настраиваем.
Также настраиваем от RTR-L-Deb к ISP.
Также проверяем настройку.
Вдобавок, дополнительно проверим наличие маршрутов с помощью команды «ip route».
Осталось настроить RTR-R-Deb. К нему, как и к предыдущим, необходимо подключить DVD-диск и установить «network-manager».
Также определяем, где какое соединение у нас установлено, чтобы в соответствии с таблицей 1 назначить правильные IP-адреса.
От RTR-R-Deb к ISP:
От RTR-R-Deb к RIGHT:
Проверяем.
Также давайте взглянем на маршруты.
Выполним команду «ping 4.4.4.100 -c 5», чтобы проверить сетевую связность.
Теперь необходимо установить и настроить firewalld.
Подробнее о firewalld можно почитать здесь.
Поскольку DVD-диск уже у нас подключен, то достаточно ввести команду для установки.
После установки можно взглянуть на статус firewalld. Делается это с помощью команды «systemctl status firewalld».
Помните о том, что по умолчанию firewalld пропускает только SSH и ping. Всё остальное будет попросту отбрасываться, так как все интерфейсы автоматически помещаются в зону «public». К зоне «public» всегда относятся самые строгие требования.
Посмотреть существующие зоны и интерфейсы, которые в них помещены, можно командой «firewall-cmd --get-active-zones».
Как и говорилось выше, интерфейсы помещены в зону «public». Необходимо интерфейсы удалить из этой зоны.
Командой «firewall-cmd --zone=public --remove-interface=ens…» удаляем оба интерфейса и зоны «public», после – повторно проверяем. Как видно, команда «firewall-cmd --get-active-zones» ничего не вернула. Это означает, что ни один из интерфейсов не находится в какой-либо зоне.
Как и говорилось выше по поводу распределения интерфейсов и назначения IP-адресов, здесь немаловажной составляющей является помещение интерфейса в конкретную зону. Если перепутать, работать, разумеется, не будет.
Прежде, чем добавлять интерфейс в какую-либо зону, необходимо посмотреть, под каким номер интерфейса располагается та или иная зона.
Смотрим интерфейсы командой «ip add».
Видим, что ens192 – 4.4.4.100/24, а ens224 – 192.168.100.254/24. Помните об этой информации. В зависимости от задания наименования интерфейсов и сеть может и, скорее всего, будет отличаться.
По умолчанию в firewalld есть стандартный набор зон, которые отличаются разностью правил, строгостью и прочими вещами. Чтобы посмотреть все доступные зоны с возможностью прокрутки, воспользуемся командой «firewall-cmd --list-all-zones | less».
Выйти из этого режима можно с помощью комбинации клавиш «Ctrl+Z».
Добавим внутренний интерфейс в зону «trusted» командой
«firewall-cmd --zone=trusted --add-interface=ens…».
Крайне внимательно смотрите на соответствие IP-адресов и номер интерфейсов, которым эти IP-адреса принадлежат.
Добавим внешний интерфейс в зону «external» командой
«firewall-cmd --zone=external --add-interface=ens…».
Проверим нахождения интерфейсов в зонах.
В зоне «external» необходимо по заданию разрешить работу следующих сервисов: HTTP, HTTPS, DNS и SSH. Но SSH по умолчанию и так разрешён.
Делается это командами:
«firewall-cmd --zone=external --add-service=http»;
«firewall-cmd --zone=external --add-service=https»;
«firewall-cmd --zone=external --add-service=dns»;
«firewall-cmd --zone=external --add-service=ssh».
Если у Вас, как и у меня, на правиле с SSH выскочила предупреждение, то это означает, что в зоне «external» уже разрешён SSH.
Также необходимо настроить пробрасывание портов.
По аналогии с протоколами делается это командами:
«firewall-cmd --zone=external \
--add-forward-port=port=2222:proto=tcp:toport=22:toaddr=192.168.100.100»;
«firewall-cmd --zone=external \
--add-forward-port=port=80:proto=tcp:toport=80:toaddr=192.168.100.100»;
«firewall-cmd --zone=external \
--add-forward-port=port=53:proto=udp:toport=53:toaddr=192.168.100.200».
Символ слеш «/» выступает в качестве переноса на новую строчку. При записи данного правила в консоли слеш удаляется!
На рисунке выше видно, что мы указали в firewalld, что если трафик приходит по SSH или по HTTP/HTTPS на RTR-L-Deb, то его необходимо отправлять на WEB-L – 192.168.100.100.
Если же трафик приходит по DHCP, то переотправляем его уже на SRV-Win – 192.168.100.200.
Наглядно синтаксис firewalld проброса портов можно посмотреть здесь.
Посмотрим, какие протоколы и пробрасывание портов у нас настроено для зоны «external» командой «firewall-cmd --zone=external --list-all».
Не забывайте о том, что между островами LEFT и RIGHT должен быть налажен VPN-туннель. Для этого необходимо указать порт, который будет использовать VPN-ом. В задании нет чётких требований, какой именно порт необходимо использовать для VPN-а, поэтому выберем произвольно – 12345.
Протокол – UDP, так как «wireguard» работает на данном протоколе.
После настройки firewalld необходимо обязательно сохранить конфигурацию командой «firewall-cmd --runtime-to-permanent».
Чтобы изменения вступили в силу, необходимо заново прочитать все правила. Повторное чтение выполняется с помощью команды
«firewall-cmd --reload».
Переходим к настройке RTR-R-Deb.
DVD-диск уже подключен. Поэтому, как и для RTR-L-Deb, устанавливаем firewalld.
После установки не забывайте о том, что все интерфейсы по умолчанию находятся в зоне «public», из которой нам необходимо удалить наши интерфейсы.
Делается это ровно так же, как и для RTR-L-Deb.
Также помните о правильности добавления интерфейсов в нужные зоны! Поэтому для начала просматриваем интерфейсы командой «ip add», а только после добавляем в определённые зоны интерфейсы.
Добавление интерфейсов в конкретную зону осуществляется командой «firewall-cmd --zone=trusted (или external) --add-interface=ens…».
В зону «trusted» добавляем внутренний интерфейс 172.16.100.254/24, а во внешнюю зону «external» – 5.5.5.100/24.
На всякий случай проверяем правильность добавление интерфейсов в нужные зоны.
Как видно на рисунке выше, синим цветом выделена внутренняя зона «trusted», а красным – внешняя зона «external».
Теперь необходимо настроить зону «external». В зоне «external» по аналогии с RTR-L-Deb необходимо разрешить работу следующих сервисов: HTTP, HTTPS, DNS и SSH.
Делается это командами:
«firewall-cmd --zone=external --add-service=http»;
«firewall-cmd --zone=external --add-service=https»;
«firewall-cmd --zone=external --add-service=dns»;
«firewall-cmd --zone=external --add-service=ssh».
Напоминаю, предупреждение выскакивает из-за того, что SSH уже добавлен в зону «external».
Добавим порт, который будет использоваться VPN-каналом.
Теперь займёмся пробрасыванием портов:
«firewall-cmd --zone=external \
--add-forward-port=port=2244:proto=tcp:toport=22:toaddr=172.16.100.100»;
«firewall-cmd --zone=external \
--add-forward-port=port=80:proto=tcp:toport=80:toaddr=172.16.100.100».
Символ слеш «/» выступает в качестве переноса на новую строчку. При записи данного правила в консоли слеш удаляется!
Давайте посмотрим настройку зоны «external» с помощью команды «firewall-cmd --zone=external --list-all».
Не забываем сохранить конфигурацию firewalld и заново прочитать список правил!
Теперь давайте проверим функционал нашего firewalld. Для этого попытаемся подключиться по SSH к 4.4.4.100 на порт 2222 и, если мы настроили всё правильно, подключение должно будет произведено не с RTR-L-Deb, а с WEB-L, поскольку мы сделали пробрасывание портов.
Как видно на рисунке, всё успешно отработало. Подключение осуществляется командой «ssh [email protected] -p 2222». Затем «yes», поскольку я хочу продолжить подключение. Ввожу пароль toor и вижу результат: я нахожусь под пользователем root на устройстве WEB-L.
Также проверим правильность настройки firewalld с обратной стороны. Заходим на устройство RTR-L-Deb и выполняем ту же самую последовательность действий, за исключением адреса и порта. Адрес – 5.5.5.100, порт – 2244.
Всё работает ровно так, как и настраивали. Осталось теперь только настроить VPN-канал на базе «wireguard».
Подробнее о wireguard можно почитать здесь и здесь.
Заходим на RTR-L-Deb. Устанавливаем «wireguard» командой «apt install wireguard-tools -y»
Поскольку VPN подразумевает под собой наличие защищённого канала связи, то необходимы ключи, на базе которых будет происходить шифрование. VPN на базе wireguard подразумевает, что нам необходимо на одном из устройств сформировать ключи и обменяться ими.
Для начала сформируем директорию для ключей и сами ключи:
создаём директорию keys в /etc/wireguard командой «mkdir /etc/wireguard/keys»;
перехожу в директорию keys командой «cd /etc/wireguard/keys/»;
генерирую публичный ключ на основе закрытого ключа командой «wg genkey | tee srv-sec.key | wg pubkey srv-pub.key»;
после этого проверяю, появились ли у меня ключи командой «ls».
Теперь мне необходимо сформировать клиентские ключи:
генерирую публичный ключ на основе закрытого ключа командой «wg genkey | tee cli-sec.key | wg pubkey cli-pub.key»;
после этого проверяю, появились ли у меня ключи командой «ls».
Теперь необходимо сформировать файл конфигурации, внутрь которых необходимо поместить ключи. У нас есть серверный открытый и закрытый ключ, а также клиентский открытый и закрытый ключ. Это обусловлено тем, что одно устройство у нас будет выступать в роли сервера и, соответственно, предоставлять серверный интерфейс для соединения, другое – будет выступать в роли клиента, который цепляется к серверу.
При формировании конфигурационного файла важно понимать, какие ключи необходимо использовать. RTR-L-Deb выступает в роли сервера, поэтому у него в файле конфигурации должен быть секретный ключ (srv-sec.key) и публичный ключ клиента (cli-pub.key). В свою очередь, у клиента будет секретный ключ клиента (cli-sec.key) и публичный ключ сервера (srv-pub.key).
Формируем конфигурационный файл:
«cat srv-sec.key cli-pub.key /etc/wireguard/wg0.conf»;
открываю созданный файл в редакторе nano командой «nano /etc/wireguard/wg0.conf».
И вижу следующее.
В файле присутствует пара строчек – это и есть наши ключи. Первая строка – закрытый серверный ключ, вторая – публичный ключ клиента.
Прописываем конфигурацию.
В блоке «Interface» мы формируем виртуальный интерфейс, который будет иметь IP-адрес 10.20.30.1 с префиксом сети 30. Прослушиваемый порт – 12345. И в качестве «PrivateKey» выступает у нас ключ, который мы сгенерировали, – srv-sec.key.
Также мы описываем нашего соседа (соединение) в блоке «Peer». В качестве публичного ключа у нас выступает cli-pub.key. Разрешённые (allowedIPs) сетями у нас являются 10.20.30.0/30 и 172.16.100.0/24.
Сохраняется конфигурация комбинацией клавиш «Ctrl+X», нажимаем «Y» и «Enter».
Важно убедиться, что ключи у нас правильно указаны! Для этого выполняем следующую цепочку действий:
выводим содержимое srv-sec.key в консоль командой «cat srv-sec.key»;
выводим содержимое cli-pub.key в консоль командой «cat cli-pub.key»;
выводим содержимое файла конфигурации wg0.conf в консоль командой «cat /etc/wireguard/wg0.conf».
После вывода этой информации необходимо сравнить, что закрытый серверный ключ соответствует «PrivateKey», а открытый клиентский ключ соответствует «PublicKey».
Теперь запустим сервис wireguard и проверим состояние нашего сервиса.
Включение сервиса осуществляется командой «systemctl enable --now wg-quick@wg0», а проверка состояния – «systemctl status wg-quick@wg0».
RTR-L-Deb настроен, пора заняться RTR-R-Deb.
Устанавливаем wireguard на RTR-R-Deb.
Так же создаём каталог keys.
Однако ключи мы не будем генерировать заново, так как они уже были сгенерированы на RTR-L-Deb. Сейчас необходимо ключи с RTR-L-Deb перебросить ключи на RTR-R-Deb по SSH.
Заходим в RTR-L-Deb. И воспользуемся командой «scp» для передачи файлов по SSH.
«scp cli-sec.key srv-pub.key 5.5.5.100:/etc/wireguard/keys» – передаём файл cli-sec.key и srv-pub.key на 5.5.5.100 в каталог /etc/wireguard/keys;
пишем «yes», так как хотим продолжить соединение;
и вводим пароль toor.
После выполнения действий Вы увидите, что файлы были переданы.
Заходим на RTR-R-Deb и проверяем, действительно ли передались файлы командой «cd /etc/wireguard/keys» и «ls».
Теперь необходимо сформировать файл конфигурации.
И открываем его в редакторе nano.
Видим следующий результат.
Формируем конфигурационный файл.
В блоке «Interface» мы формируем виртуальный интерфейс, который будет иметь IP-адрес 10.20.30.2 с префиксом сети 30. И в качестве «PrivateKey» выступает у нас ключ, который мы сгенерировали, – cli-sec.key.
Также мы описываем нашего соседа (соединение) в блоке «Peer». В качестве публичного ключа у нас выступает srv-pub.key. Точка подключения (endpoint) выступает физический [не виртуальный] интерфейс 4.4.4.100 с портом 12345. Разрешённые (allowedIPs) сетями у нас являются 10.20.30.0/30 и 192.168.100.0/24. Дополнительно задаём параметр проверки состояния канала «PersistentKeepalive» в значении 10 секунд.
Сохраняется конфигурация комбинацией клавиш «Ctrl+X», нажимаем «Y» и «Enter».
Здесь тоже важно убедиться, что ключи у нас правильно указаны. Для этого выполняем следующую цепочку действий:
выводим содержимое cli-sec.key в консоль командой «cat cli-sec.key»;
выводим содержимое srv-pub.key в консоль командой «srv cli-pub.key»;
выводим содержимое файла конфигурации wg0.conf в консоль командой «cat /etc/wireguard/wg0.conf».
После вывода этой информации необходимо сравнить, что закрытый клиентский ключ соответствует «PrivateKey», а открытый серверный ключ соответствует «PublicKey».
Теперь запустим сервис wireguard и проверим состояние нашего сервиса.
Включение сервиса осуществляется командой «systemctl enable --now wg-quick@wg0», а проверка состояния – «systemctl status wg-quick@wg0».
Единственное, что осталось, так это проверить состояния соединения между RTR-L-Deb и RTR-R-Deb.
Зайдём вначале на RTR-L-Deb и пропишем команду «wg show all».
А затем на RTR-R-Deb и пропишем команду «wg show all».
И увидим, что наш виртуальный канал активен.
Дополнительно можно посмотреть на маршруты, которые у нас присутствуют командой «ip route» на RTR-L-Deb и на RTR-R-Deb.
И там, и там мы видим, что у нас появилась связность между внутренними сегментами сети. То есть связь между LEFT и RIGHT организована.
Убедимся в этом, выполнив команду ping между WEB-L и WEB-R.
На этом первая часть завершена.