Управление сетевыми сервисами в Proxmox

Управление сетевыми сервисами – это деятельность сетевого администратора, которая обеспечивает надёжную, бесперебойную, производительную и безопасную работу сетевых систем, включая сервисы (услуги). Это включает задачи администрирования, мониторинга, планирования и предотвращения сбоев в работе сети.

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

Некоторые задачи управления сетевыми сервисами:

• планирование изменений в структуре сети;
• установка и настройка сетевых служб;
• поиск неисправностей;
• поиск узких мест сети;
• мониторинг сетевых узлов;
• мониторинг сетевого трафика.

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

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

Создание сетевой инфраструктуры

Создание сетевой инфраструктуры будет выполняться на базе гипервизора Proxmox.

Создайте виртуальные машины в соответствии с таблицей ниже.

Должно быть так:

Создайте необходимые интерфейсы:

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

Когда все виртуальные коммутаторы будут созданы, обязательно необходимо нажать кнопку «Apply Configuration».

Установка операционной системы MikroTik RouterOS:

Запустите маршрутизатор («rtr») и нажмите «i».

При установке системы все данные с диска будут утеряны. Нас это не волнует, поэтому нужно согласиться (написать «y»). После чего начнется процесс установки:

Дальше нужно нажать Enter, чтобы система перезапустилась.

Чтобы войти в учетную запись, нужно написать логин «admin», а на запросе пароля нажать Enter (пароль по умолчанию отсутствует). Далее система предложит посмотреть пользовательское соглашение. Спасибо, не надо (написать «n» и нажать Enter).

В качестве нового пароля установите «P@ssw0rd».

На этом установке системы завершена. Как и в предыдущих практических работах, самостоятельно установите операционные системы на ВМ «srv» и «cli»!

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

На RTR:

На SRV:

На CLI:

Настройка сетевых сервисов

Что необходимо настроить в данной работе?

На базе MikroTik RouterOS необходимо настроить NAT для выхода в Интернет, NTP-сервер (сервер времени), IP-конфигурацию для подключаемых устройств, а также DHCP-relay для корректной передачи DHCP-запросов от клиентов к DHCP-серверу.

По классике для начала необходимо настроить полное имя устройства на ВМ «rtr»:

system/identity/set name=rtr.ditk.local

(обратите внимание, что наличие слэшей в командах не обязательно)

Чтобы ВМ «rtr» получил DHCP-конфигурацию, необходимо настроить DHCP-client, который раньше работал в системе по умолчанию. Со временим от этого отказались в угоду (я так понимаю) безопасности.

ip/firewall/nat/add chain=srcnat src-address=0.0.0.0/0 action=masquerade out-interface=ether1
ip/dhcp-client/add interface=ether1 disabled=no
ip/dns/set servers=77.88.8.8,8.8.8.8 allow-remote-requests=yes
ip/address/print

Настройка NTP-клиента:

system/ntp/client/set enabled=yes mode=unicast servers=ntp1.stratum2.ru,ntp2.stratum2.ru
system/clock/set time-zone-name=Asia/Vladivostok
system/ntp/client/print

Чтобы другие устройства в сети могли получать актуальное время, в качестве локального сервера времени стоит настроить ВМ «rtr»:

system/ntp/server/set enabled=yes manycast=yes

На всякий случай можно проверить связь с Интернет:

ping ya.ru count=3

Отлично, ВМ «rtr» настроена и все работает корректно!

Теперь необходимо настроить статические IP-адреса на интерфейсах. Один интерфейс смотрит в сторону ВМ «rtr», другой – ВМ «cli». Будут следующие подсети:

• 172.16.0.0/24 (rtr);
• 192.168.0.0/24 (cli).

ip/address/add address=172.16.0.1/24 interface=ether2 comment=”Link to SRV” disabled=no
ip/address/add address=192.168.0.1/24 interface=ether3 comment=”Link to CLI” disabled=no

Теперь необходимо перейти к настройке ВМ «srv» и служб, которые будут установлены и настроены.

Поскольку тема «Участие в управление сетевыми сервисами» подразумевает не количество настроенных служб, а непосредственно принцип, важно затронуть все аспекты настройки.

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

hostnamectl set-hostname srv.ditk.local
exec bash
hostname -f

Теперь стоит заняться конфигурацией сети. Казалось бы, настройки IP-адреса, маски подсети и шлюза – плевое дело. Однако здесь есть немало важных моментов, которые могут пригодиться в будущем.

Для начала стоит взглянуть на физические соединения виртуальной машины:

ip -c link

Видно, что у виртуальной машины «srv» присутствует 1 физическое соединение, однако интерфейсов в системе несколько. Помимо физического соединения, в системе присутствует программный loopback (петлевой) интерфейс, который необходим для того, чтобы можно было обращаться к самому себе в пределах операционной системе.

Это пригождается, к примеру, тогда, когда вы выполняете развертывание локального сервера – во время разработки заходите в браузер по петлевому адресу (127.0.0.1 или localhost) и смотрите, что получается в ходе разработки.

Обычно операционная система автоматически создает директорию физического соединения (но только 1-го). Стоит убедиться в этом:

ls /etc/net/ifaces/

Внутри данной директории находится файл «options» с базовой конфигурацией:

cat /etc/net/ifaces/ens18/options

Какие файлы могут быть в директории интерфейса?

• ipv4address
• ipv4route
• options
• resolv.conf

где:

• файл ipv4address – содержит IP-адрес в формате CIDR; может быть несколько адресов построчно;
• файл ipv4route – в случае единственного интерфейса содержит маршрут по умолчанию;
• файл options – содержит настройки конфигурации;
• файл resolv.conf – при активации интерфейса копируется в /etc/resolv.conf;

Все файлы не являются обязательными, однако, если Ethernet-интерфейс не называется ethN, обязательно наличие файла options с параметром «TYPE=eth».

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

• static – адреса и маршруты будут взяты из файлов ipv4address и ipv4route;
• dhcp – интерфейс будет сконфигурирован по DHCP;
• ipv4ll – интерфейс будет сконфигурирован с помощью IPv4LL (link-local). Это значит, что из сети 169.254.0.0/16 (169.254.0.1-169.254.255.254) будет подобран ещё не использованный адрес и назначен на интерфейс.

К примеру, для настройки статического IP-адреса для интерфейса ens18 необходимо, чтобы в файле «options» параметр BOOTPROTO было в значении «static». Затем нужно задать IP-адрес и маску подсети – например, 172.16.0.10/24. Для этого в файл «ipv4address» следует записать параметры соединения:

cat /etc/net/ifaces/ens18/options

Если у вас BOOTPROTO находится в значении «dhcp», измените его через консольный редактор mcedit!

echo 172.16.0.10/24 > /etc/net/ifaces/ens18/ipv4address
cat /etc/net/ifaces/ens18/ipv4address

Теперь необходимо указать шлюз по умолчанию. Напомню, шлюз по умолчанию – это IP-адрес устройства, которое предоставляет выход в Интернет из локальной сети (или из сегмента сети – это зависит от топологии сети).

echo “default via 172.16.0.1” > /etc/net/ifaces/ens18/ipv4route
cat /etc/net/ifaces/ens18/ipv4route

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

echo “nameserver 77.88.8.8” > /etc/net/ifaces/ens18/resolv.conf
cat /etc/net/ifaces/ens18/resolv.conf

Возможно, вы задавались или все еще задаетесь вопросом: «А почему именно 77.88.8.8»? Все просто. Это легко запоминающийся публичный DNS-сервер Яндекса, однако можно использовать любой другой. В Интернете альтернатив, благо, достаточно. Вот фрагмент из списка публичных DNS-серверов на GitHub:

Можете использовать любой из этих DNS-серверов. Главное, убедитесь, что они работают и отвечают на DNS-запросы.

После всех манипуляций необходимо перезапустить службу «network» и убедиться, что все сработало:

systemctl restart network
ip -c -br address
ip -c route
cat /etc/resolv.conf
ping ya.ru -c3

Прежде, чем что-либо устанавливать, необходимо обязательно выполнить обновление локальных индексов пакетов (кэш пакетов):

apt-get update

Это, конечно, все замечательно, однако зачем иметь внутренний DNS-сервер, когда есть сотни публичных серверов, которые можно использовать?

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

Какие еще задачи может решать собственный DNS-сервер?

1. Уменьшение времени ответа на DNS-запрос абонентов внутренней сети. Если канал подключения к Интернет обладает большим временем задержки (скажем, четверть секунды), то работа с данными, включающими в себя много доменных имён (например, с www-страницами) может стать весьма медленной, хотя общий объём трафика будет невелик.

Система доменных имён – распределённая база данных, замечательно поддерживающая механизм кеширования запросов. Первое обращение к кеширующему DNS-серверу приводит к выполнению рекурсивного запроса: опрашивается сервер более высокого уровня, который, если не знает ответа, передаст запрос дальше. Результат запроса оседает в кеше, так что все последующие обращения именно к этой записи дальше кеширующего сервера не уйдут. Время жизни (Time To Live, TTL) записи в кеше определяется хозяином запрошенного доменного имени. По истечении TTL запись из кеша удаляется.

2. Именование компьютеров в интранет-сети (не опечатка, intra – «внутри»). Это бывает важно, если среди компьютеров внутренней сети есть свои серверы (например, корпоративный WWW-сервер), к которым другие компьютеры обращаются по доменному имени. Поскольку адреса такой сети не пойдут дальше межсетевого экрана, вы можете использовать имя какого угодно, в том числе – несуществующего – домена и составить табличку в /etc/hosts. Однако раздавать эту табличку лучше все-таки средствами DNS.

Обе эти задачи можно было решить и воспользовавшись Bind – мощным полнофункциональным DNS-сервером (обратите внимание, пакет и сервис называются bind, а сам демон – named). Bind – программа весьма сложная (общий объем документации в пакете bind-doc – более полутора мегабайтов, одних RFC поддерживается около сорока), с замысловатой моделью безопасности и долгой историей эксплуатации.

Как во всякой сложной программе, в Bind изредка обнаруживаются уязвимости, поэтому в ALT Linux 2.4 Master этот сервер (Bind версии 9) запускается с использованием chroot. В /etc от Bind осталась только символьная ссылка на главный файл настроек, named.conf. Всю свою жизнь named проводит, запертый в /var/lib/bind в качестве корневого каталога. Там у него есть собственный /etc, содержащий (в варианте ALT Linux) целый набор включаемых друг в друга настроечных файлов, /var и даже /dev. Обратите внимание, что все пути к файлам и каталогам в настройках Bind начинаются именно из этого каталога, и /zone соответствует /var/lib/bind/zone.

Пора установить bind:

apt-get install -y bind bind-utils

Для того, чтобы запустить named в кеширующем режиме, достаточно раскомментировать и заполнить раздел настройки forwarders (вышестоящие серверы) в файле /var/lib/bind/etc/options.conf. Обратите внимание на возможные ограничения на право обращаться к серверу с обычными и рекурсивными запросами (настройки allow-query и allow-recursion). Можно раскомментировать находящиеся в этом файле разумные установки по умолчанию. Эти настройки открывают доступ только абонентам локальных сетей, т. е. сетей, к которым компьютер подключён непосредственно.

grep allow- /var/lib/bind/etc/options.conf

Использование Bind для полноценного именования компьютеров в локальной сети требует создания двух зон (т. н. прямой и обратной), содержащих в виде записей определённого формата информацию о доменных именах компьютеров и об их роли в этих доменах. Каждая зона должна включать запись типа SOA (State Of Authority, сведения об ответственности).

В этой записи определяются основные временные и административные параметры домена, в том числе электронный адрес лица, ответственного за домен (администратора) и серийный номер зоны. Серийный номер – число в диапазоне от 0 до 4294967295 (2**32); каждое изменение, вносимое в зону, должно сопровождаться увеличением этого номера. Обнаружив увеличение серийного номера, кеширующие и вторичные серверы признают все закешированные записи из этой зоны устаревшими.

Структура номера может быть любой, лишь бы он постоянно увеличивался. Удобно использовать формат годмесяцчисловерсия, где все числа, кроме года, двузначные, а версия может обнуляться раз в день, соответствовать времени (например, по формуле 100 * (часы * 60 + минуты) / (60 * 24) или иметь сквозную нумерацию (в этом случае появляется сложность с переходом от версии 99 к версии 100, то есть 0). Даже если серийный номер генерируется автоматически, рекомендуется пользоваться этим форматом, наглядно отражающим время создания зоны. Пример зоны, не содержащей ничего, кроме записи SOA, находится в файле /var/lib/bind/zone/empty.

cat /var/lib/bind/zone/empty

Кроме записи типа SOA, в каждой зоне должна быть хотя бы одна запись типа NS (Name Server), указывающая адрес DNS-сервера, авторитетного в этом домене (как минимум – адрес сервера, на котором запущен named). Несколько зон включаются в настройку Bind автоматически (файл /var/lib/bind/etc/rfc1912.conf). Они нужны для обслуживания сети, привязанной к сетевой заглушке (127.0.0.1/8).

Стоит обратить внимание на то, что имя домена, который обслуживается зоной, задаётся в файле настроек, а в самом файле зоны можно использовать относительную адресацию (без «.» в конце имени), так что операция переименования домена делается редактированием одной строки. В ALT Linux рекомендуется добавлять описания зон в настроечный файл /var/lib/bind/etc/local.conf.

Прямая зона нужна для преобразования доменного имени в IP-адрес – операции, необходимой многим программам постоянно. Большинство записей в прямой зоне – типа A (Address) – предназначены именно для этого. Другие часто встречающиеся типы записей – это CNAME (Canonical Name, настоящее имя), позволяющий привязать несколько дополнительных имён к одному, и MX (Mail eXchange, обмен почтой), указывающий, куда пересылать почтовые сообщения, в поле адресат которых встречается определённое доменное имя.

Для того, чтобы превращать IP-адреса в доменные имена у каждой сети должна быть обратная зона. Если такой зоны нет, и в файле /etc/hosts тоже ничего не написано, операция не выполнится. Такое преобразование нужно гораздо реже и в основном по соображениям административным: для того, чтобы выяснить принадлежность компьютера (с которого, допустим, пытаются атаковать сервер) по его IP-адресу.

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

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

Обратная зона состоит почти целиком из записей типа PTR (Pointer, указатель). Чтобы не класть сущностей, решено было не вводить новый способ работы сервера имён и представить обратное преобразование IP-адреса как прямое преобразование доменного имени специального вида. Например, чтобы выяснить доменное имя компьютера с адресом 1.2.3.4, необходимо запросить информацию о доменном имени 4.3.2.1.in-addr.arpa. Таким образом, каждой подсети класса C (или выше) соответствует определённый домен, в котором можно найти ответ.

Теорию рассмотрели, стоит перейти к практике. Для начала необходимо отредактировать конфигурационный файл «options.conf»:

mcedit /var/lib/bind/etc/options.conf

Данных изменений уже достаточно, чтобы DNS-сервер мог переотправлять запросы от клиентов из внутренней сети во внешнюю! Чтобы в этом убедиться, нужно запустить службу «bind» и изменить «resolv.conf» на интерфейсе:

systemctl enable --now bind
mcedit /etc/net/ifaces/ens18/resolv.conf

systemctl restart network
systemctl restart bind
cat /etc/resolv.conf

ping ya.ru -c3

Сейчас наш DNS-сервер выступает в роли эникейщика – принеси/подай. Но самостоятельной роли у него нет, что, несомненно, нужно исправить:

mcedit /var/lib/bind/etc/local.conf

Дальше нужно скопировать шаблон пустой зоны и скорректировать в соответствии с нашими потребностями:

cp /var/lib/bind/etc/zone/empty /var/lib/bind/etc/zone/ditk.local
cp /var/lib/bind/etc/zone/empty /var/lib/bind/etc/zone/0.16.172.in-addr.arpa
cp /var/lib/bind/etc/zone/empty /var/lib/bind/etc/zone/0.168.192.in-addr.arpa

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

mcedit /var/lib/bind/etc/zone/ditk.local

mcedit /var/lib/bind/etc/zone/0.16.172.in-addr.arpa

mcedit /var/lib/bind/etc/zone/0.168.192.in-addr.arpa

Конфиги написаны. Стоит перезапустить службу «bind» и проверить работоспособность службы:

systemctl restart bind
ping ya.ru -c3

Как видно, DNS отрабатывает, но…

host rtr
host srv
host cli

По какой-то причине разрешение доменных имен не срабатывает. Говорит, серверная ошибка. Посмотрим:

systemctl status bind

Живее всех живых! Но в чем же дело? Может опечатался в конфиге зон? Можно явно проверить:

named-checkconf -z

Зоны загружены! Ошибок нет, а bind почему-то их не видит. Дело вот в чем:

ls -l /var/lib/bind/etc/zone/

Ничего не замечаете? Служба bind тупо не видит файлы зон, потому что файлы созданы пользователем «root» и находятся в группе «root». А нужно, чтобы файлы были в группе «named». Чтобы это исправить, нужно изменить группу:

chown root:named /var/lib/bind/etc/zone/ditk.local
chown root:named /var/lib/bind/etc/zone/0.*
ls -l /var/lib/bind/etc/zone/

Теперь все корректно. Нужно перезапустить bind:

systemctl restart bind
host rtr
host srv
host cli
host 172.16.0.1
host 172.16.0.10
host 192.168.0.1
host 192.168.0.10

Грац! Теперь нужно скачать DHCP-сервер:

apt-get install -y dhcp-server

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

mcedit /etc/sysconfig/dhcpd

mcedit /etc/dhcp/dhcpd.conf

Обратите внимание, что в конфигурационном файле выделен MAC-адрес ВМ «cli». Чтобы его получить, нужно зайти на ВМ «cli» и в терминале написать:

ip -c link

У вас, разумеется, MAC-адрес у ВМ «cli» может отличаться!

Заполните конфигурационный файл в соответствии с изображением выше.

После:

systemctl enable --now dhcpd
systemctl status dhcpd

Чтобы DHCP-конфигурацию ВМ «cli» смог получить, необходимо донастроить ВМ «rtr»:

ip/dhcp-relay/add dhcp-server=172.16.0.10 interface=ether3 local-address=192.168.0.1 name=”DHCP-Relay” disabled=no

После применения этой настройки, необходимо зайти на ВМ «cli» и выполнить команду «reboot».

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

Также стоит проверить корректность выданного DNS-сервера и автоматическое назначение NTP-сервера:

cat /etc/resolv.conf
chronyc tracking

host rtr
host srv
host cli
host 172.16.0.1
host 172.16.0.10

На десерт:

ping ya.ru -c3