7 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Записки IT специалиста

  • Автор: Уваров А.С.
  • 02.10.2019

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

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

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

Внешняя сеть

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

В основе всех виртуальных сетей в Proxmoх лежит сетевой мост (Linux Bridge) — vmbr, допускается создание до 4095 таких устройств. Сетевой мост может включать в себя как физические, так и виртуальные адаптеры, выполняя для них роль неуправляемого коммутатора. Физическая сетевая карта, подключенная к мосту, не имеет настроек и используется как физический Ehternet-интерфейс для данного виртуального коммутатора. Все сетевые настройки производятся внутри виртуальных машин, которые через мост и физический адаптер прозрачно попадают во внешнюю сеть.

Присвоение интерфейсу моста IP-адреса фактически подключает к виртуальному коммутатору сам хост, т.е. гипервизор, который также прозрачно попадет во внешнюю сеть. Если в Hyper-V для подключения гипервизора к сети на хосте создавался еще один виртуальный сетевой адаптер, то в Proxmox для этого следует назначить IP-адрес интерфейсу моста. Ниже показан пример такой настройки:

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

Фактически это сетевые настройки самого гипервизора. Обратите внимание, что сервера DNS указываются отдельно, в Система — DNS:

Для того, чтобы подключить к такой сети виртуальную машину в настройках ее сетевого адаптера следует выбрать нужный мост (виртуальный коммутатор):

Сетевые настройки виртуальной машины либо задаются вручную, либо могут быть получены от DHCP-сервера внешней сети.

Внешняя изолированная сеть

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

Читать еще:  Установка Kali Linux. Подробная пошаговая инструкция

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

Для доступа к самому гипервизору может быть использован либо другой сетевой адаптер (как показано на нашей схеме), так и созданная по умолчанию внешняя сеть с сетевым мостом. Оба варианта имеют право на жизнь, а во втором случае вы сможете также подключать виртуальные машины к разным виртуальным сетям. Поэтому не следует рассматривать приведенную нами схему как догму, это только один из возможных вариантов и выбран нами в целях упрощения схемы.

Для примера мы подключили к такой сети виртуальную машину, которая тут же получила по DHCP адрес из внешней сети, никак не связанной с гипервизором.

Внутренняя сеть с NAT

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

Обратите внимание, данная конфигурация не может быть изолирована от хоста, так как именно хост предоставляет ей службу трансляции сетевых адресов (NAT) и выступает шлюзом для виртуальных машин. Для настройки такой сети создайте новый сетевой мост без привязки к физическому адаптеру и назначьте ему IP-адрес из произвольной сети, отличной от внешней.

Все изменения сетевой конфигурации требуют перезагрузки узла гипервизора, поэтому, чтобы не перезагружать узел дважды перейдем в консоль сервера и перейдем в директорию /etc/network, в котором будут присутствовать файлы interfaces — с текущей сетевой конфигурацией и interfaces.new — с новой, которая вступит в силу после перезагрузки.

Откроем именно interfaces.new и внесем в конец следующие строки:

В качестве сети, в нашем случае 192.168.34.0/24, укажите выбранную вами сеть, а вместо интерфейса ens33 укажите тот сетевой интерфейс, который смотрит во внешнюю сеть с доступом в интернет. Если вы используете сетевую конфигурацию по умолчанию, то это будет не физический адаптер, а первый созданный мост vmbr0, как на скриншоте ниже:

Перезагрузим узел и назначим виртуальной машине или контейнеру созданную сеть (vmbr1), также выдадим ей адрес из этой сети, а шлюзом укажем адрес моста.

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

Внутренняя сеть

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

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

Частная сеть

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

Для такой сети просто создайте еще один сетевой мост без каких-либо настроек:

Читать еще:  Бесплатный wifi - для кого

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

Организуем службы DNS и DHCP для внутренних сетей

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

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

В качестве серверов DNS и DHCP мы будем использовать уже известный нашим читателям пакет dnsmasq, который является простым и легким кеширующим DNS и DHCP-сервером. Установим его:

Затем перейдем в конфигурационный файл /etc/dnsmasq.conf и найдем и приведем к следующему виду параметры:

Здесь мы явно указали интерфейсы и адреса, на которых будет работать наш сервер. С одной стороны, присутствует некоторая избыточность, но лучше так, чем потом, при изменении сетевых настроек в вашей сети неожиданно появится неавторизованный DHCP-сервер.

Затем укажем выдаваемые клиентам диапазоны адресов:

Обратите внимание на формат записи, перед каждой настройкой мы указываем сетевой интерфейс к которой она применяется.

Аналогичным образом зададим нужные DHCP-опции, в нашем случае это Option 3 и 6 (шлюз и DNS-сервер).

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

Сохраняем конфигурационный файл и перезапускаем службу

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

Подготовка шлюза

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

Сеть на будущем программном роутере настроили, доступ в интернет на сервере есть. Обновим его:

Установим MC, мне в нем удобнее всего работать, в том числе в редакторе mcedit:

Настроим часовой пояс, если раньше не сделали это:

Устанавливаем сервис ntp для автоматического обновления времени:

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

Установка

Когда вы запускаете Dnsmasq как DHCP сервер, он также начинает прослушивать локальный интерфейс (localhost) на запросы DNS. Для запуска функции кэширования DNS отредактируйте /etc/dnsmasq.conf , добавив в него:

Чтобы другие компьютеры локальной сети могли использовать этот сервер, можно позволить слушать локальный IP адрес:

В этом случае рекомендуется использовать статический IP адрес для локальной сети.

Файл адресов DNS

This article or section is a candidate for merging with resolv.conf.

После конфигурирования dnsmasq DHCP клиенту нужно будет дописать локальный адрес в вершину списка известных DNS адресов /etc/resolv.conf . Это обеспечит отправку всех запросов на dnsmasq прежде попыток разрешить их на внешнем DNS. После конфигурирования DHCP клиента сетевые демоны должны быть перезапущены чтобы изменения вступили в силу.

resolv.conf

Одним из вариантов может быть использование конфигурации resolv.conf . Для этого просто укажите localhost первой строчкой в /etc/resolv.conf :

Читать еще:  Что такое тихое сканирование программой Nma?

Теперь все запросы DNS будут перенаправляться на обработку к dnsmasq. Внешние сервера будут использоваться только тогда, когда dnsmasq не удастся выполнить запрос. dhcpcd может переписать стандартный /etc/resolv.conf . Если используется DHCP, то хорошей практикой будет защита /etc/resolv.conf . Для этого добавьте nohook resolv.conf в конфигурационный файл dhcpcd:

Кроме того, можно защитить resolv.conf, запретив любую его модификацию:

Больше трех серверов DNS

В Linux имеется ограничение способности самостоятельной обрабатки DNS запросов, при котором можно использовать не более трех серверов DNS в resolv.conf . В качестве обходного пути можно указать только localhost в resolv.conf , а затем создать отдельный resolv-file для используемых внешних серверов DNS. Сначала создайте новый resolv файл для dnsmasq:

Затем отредактируйте /etc/dnsmasq.conf для использования нового resolv файла:

dhcpcd

dhcpcd может сам добавлять или удалять DNS сервера в /etc/resolv.conf создавая или изменяя /etc/resolv.conf.head и /etc/resolv.conf.tail файлы соответственно:

dhclient

Для dhclient добавьте или раскомментируйте в /etc/dhcp/dhclient.conf :

NetworkManager

NetworkManager можно сконфигурировать так, чтобы он запускал dnsmasq. Добавьте опцию dns=dnsmasq в секцию [main] файла NetworkManager.conf , затем выключите dnsmasq.service :

Собственные настройки dnsmasq желательно хранить в /etc/NetworkManager/dnsmasq.d/ . Например, чтобы изменить размер кэша DNS (который хранится в RAM):

Когда dnsmasq запускается NetworkManager , настройки в этом каталоге приоритетней стандартного файла конфигурации.

Enabling dnsmasq in NetworkManager may break IPv6-only DNS lookups (i.e. dig -6 [hostname] ) which would otherwise work. In order to resolve this, creating the following file will configure dnsmasq to also listen to the IPv6 loopback:

In addition, dnsmasq also does not prioritize upstream IPv6 DNS. Unfortunately NetworkManager does not do this (Ubuntu Bug). A workaround would be to disable IPv4 DNS in the NetworkManager config, assuming one exists

Другие методы

Другим вариантом является использование NetworkManager, настроенного вручную. Доступ к настройкам зависит от используемого фронтэнда; как правило, вызываемые по нажатию правой кнопки мыши апплета, редактирование (или создание) профиля, затем выбрав ‘DHCP Автоматический’ (указать адрес). Адреса DNS серверов должны быть введены так:

Firewall

Какой бы мы режим не выбрали, нам нужно сделать так, чтобы доступ в интернет осуществлялся только через прокси-сервер. И прежде чем мы пойдем дальше, нам необходимо внести некоторые коррективы в правила фаервола. Если вы устанавливали pfSense по нашим предыдущим обзорам, то набор правил по умолчанию в закладке LAN меню FirewallRules у вас будет выглядеть следующим образом:

На данном этапе нужно удалить все правила кроме первого, которое нужно только для того, чтобы бы мы сами себе не заблокировали доступ на web-интерфейс pfSense. Удалить любое правило можно нажатием кнопки с изображением крестика справа от нужного правила. После удаления список правил получился вот такой:

Теперь добавим одно довольно простое правило, которое будет разрешать доступ с компьютеров локальной сети до машины с pfSense. Это делается кнопкой, я её указал стрелкой на скриншоте выше. Такое правило нужно по двум причинам как минимум:

Вы можете задать вопрос по статье специалисту.

[edit] Устранение неполадок

Если вы не можете проверить связь комадной ping по доменному имени компьютера, добавьте точку в конец команды. Т.е. вместо «ping server» попробуйте «ping server.».

Если статические адреса заданы, но компьютеры продолжают получать обычный IP-адрес DHCP, попробуйте перейти на страницу Setup веб-интерфейса. Нажмите Save и затем Apply settings. DHCP-сервер должен перезапуститься, и ненадолго возможна потеря соединения. Попробуйте обновить аренду DHCP, и в этот момент вы получите правильный IP-адрес.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector