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

Представь, что у тебя есть готовая инфраструктура с гипервизорами и виртуалками внутри. Задача: предоставить определенной группе виртуальных машин IP-адрес в одном широковещательном домене, другой группе — в другом, а самому гипервизору — в третьем. То есть разместить их в различных сетях.

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

  1. Обязанности в организации строго разделены. Есть администратор доменной сети (AD), есть администратор других серверов, предоставляющих различные сетевые сервисы организации (DNS-сервер, mail-сервер, веб-сервер, сервер баз данных и другие). Администратор сервера AD хочет, чтобы его виртуальный сервер был в одной сети с клиентами, при этом безопасник настаивает, чтобы сам гипервизор находился в отдельной сети серверов (отдельный широковещательный домен).
  2. Ты предоставляешь доступ извне к виртуальной машине. Как обеспечить такой доступ и закрыть доступ к любому другому узлу?

Самый простой способ реализовать такую схему — это включить один сетевой интерфейс в одну сеть, другой в другую и настроить мосты соответствующим образом. Нельзя сказать, что такой подход на 100% правильный или неправильный, но он вполне рабочий. И значит, имеет право на жизнь. А как быть тем, у кого всего один сетевой интерфейс? В любом случае наиболее правильный метод, если есть коммутатор второго уровня (L2), — это разделить сеть на логические сегменты. Проще говоря, построить сеть на VLAN’ах.

 

Что нужно знать о VLAN

VLAN — это виртуальные сети, которые существуют на втором уровне модели OSI и реализуются с помощью коммутаторов второго уровня. Не вдаваясь в подробности, можно сказать, что это группа портов коммутатора, разделенная на логические сегменты сети. Каждый такой сегмент имеет свой маркер (тег PVID). Каждая группа портов VLAN’а знает о своей принадлежности к определенной группе благодаря этим тегам.

Существует два типа портов: access и trunk. В access подключаются конечные сетевые устройства, в trunk подключаются только другие trunk-порты. Если с компьютера пакет попадает на access-порт, то он помечается тегом (PVID), и далее коммутатор отправляет этот пакет только на порты точно с такими же VLAN ID или на trunk-порт. При отправке кадра конечному узлу тег снимается, так что они понятия не имеют о том, что находятся в каком-либо VLAN’е.

Когда пакет попадает на trunk-порт, он передается как есть, тег не снимается. Таким образом, внутри trunk-порта передаются пакеты с несколькими тегами (PVID).

Стоит заметить, что access-порт можно настроить так, чтобы тег на выходе не снимался, тогда для принятия пакета конечный клиент должен знать, в какой VLAN он подключен. Не все сетевые карты и/или ОС поддерживают работу с VLAN по умолчанию. Как правило, это зависит от драйвера сетевой карты.

 

Приступаем к настройке

Напоминаю, что в одной из предыдущих статей мы рассматривали построение виртуализации на базе Ubuntu/Debian и KVM. Поэтому исходить будем из того, что система установлена и настроена, есть два физических интерфейса, один подключен к виртуальному мосту и есть виртуальные машины, которые им пользуются. Второй интерфейс не сконфигурирован.

Теперь вернемся к нашим VLAN’ам. Чтобы наша идея работала, нам нужно подключить первый физический интерфейс нашей машины к trunk-порту коммутатора, но при этом заблаговременно разделить (а точнее, протегировать) трафик виртуалок по разным VLAN’ам.

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

  1. Очень некрасивый вывод ifconfig.
  2. Нет возможности на лету добавить или удалить VLAN. Иначе говоря, для каждого нового VLAN’а нужно добавлять виртуальный интерфейс. Подключать его в VLAN, включать в мост. Останавливать виртуальную машину и подключать сеть через этот мост.
  3. Занимает много времени.

Но если у нас виртуальные машины, почему бы не воспользоваться виртуальным коммутатором второго уровня, в который и воткнуть все виртуальные проводки? Это решение гораздо лучше, позволяет более гибко настроить систему. Ну и использовать такой коммутатор, как самый обычный!

Гугление привело к трем наиболее популярным решениям. Одно входит в состав Hyper-V, который платный и не умеет OpenFlow. Второе: MikroTik, с помощью которого можно не только создать виртуальный коммутатор, но и перенести его конфигурацию на железный. Отпугивает только, что он базируется на полноценной операционной системе — RouterOS. А это уже совсем не то. И наконец, встречай — Open vSwitch.

 

Open vSwitch

Open vSwitch — программный многоуровневый коммутатор с открытым исходным текстом, предназначенный для работы с гипервизорами. Работает в Linux начиная с версии 2.6.15. Основные возможности коммутатора:

  • учет трафика, в том числе проходящего между виртуальными машинами с использованием SPAN/RSPAN, sFlow и Netflow;
  • поддержка VLAN (IEEE 802.1q);
  • привязка к конкретным физическим интерфейсам и балансировка нагрузки по исходящим MAC-адресам;
  • работа на уровне ядра, совместимость с программным мостом Linux Bridge;
  • поддерживает OpenFlow для управления логикой коммутации;
  • с меньшей производительностью, чем в режиме на уровне ядра, Open vSwitch может работать как обычное приложение.

Open vSwitch используется в составе Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU, ProxMox (начиная с 2.3).

В качестве наглядного примера будем виртуализировать сервер Kerio 9.1.4. Итак, чтобы понимать, как сейчас все устроено до переделки. Железный сервер Kerio — второй сервер виртуализации, в котором работает несколько сетевых сервисов организации: клиентские сети net1, net2, net3 и net4, серверная сеть net5. Каждый сегмент сети подключен в отдельный сетевой интерфейс «железного» Kerio.

Схема, которую будем реализовывать
Схема, которую будем реализовывать

Напоминаю: исходим из того, что сервер виртуализации уже установлен и настроен. Также установлен пакет bridge-utils и настроен сетевой мост br0. В системе присутствуют некоторые виртуальные машины, подключенные через этот сетевой мост.

 

Установка и первоначальная настройка

На самом деле установка Open vSwitch сводится к установке одного пакета:

$ sudo apt-get install openvswitch-switch

После установки никаких изменений не происходит, кроме запуска сервиса OVS. Создадим коммутатор:

$ sudo ovs-vsctl add-br br1

Посмотрим, что к нему подключено:

$ sudo ovs-vsctl show.
  0b58d70f-e503-4ed2-833c-e24503f2e45f
  Bridge "br1"
      Port "br1"
          Interface "br1"
              type: internal
    ovs_version: "2.5.2"

Мы видим, что создан коммутатор br1 с подключенным интерфейсом br1. Если требуется, можно этот порт настроить, например задать ему определенный VLAN или порт как trunk с ограничениями по конкретным VLAN’ам. Далее подключим к нашему коммутатору свободный сетевой интерфейс ОС.

$ sudo ovs-vsctl add-port br1 eth0
Схема подключения OVS и физического интерфейса
Схема подключения OVS и физического интерфейса

По умолчанию этот порт начинает работать как обычный и транковый порт, пропуская все VLAN’ы. Далее можно сделать этот порт транковым для указанных VLAN ID. Или можно оставить как есть, тогда порт будет пропускать все VLAN ID. У нас структура большая, сеть может каждый день меняться, поэтому оставим как есть.

Следующим шагом обнуляем конфигурацию интерфейса eth0 и отключаем его от TCP/IP-стека операционной системы:

$ sudo ifconfig eth0 0

Далее вместо eth0 подключаем к TCP/IP-стеку ОС новый внутренний интерфейс br1 коммутатора br1. Приятная новость: OVS автоматически применяет и сохраняет свою конфигурацию, поэтому ничего особо делать не придется. Интерфейс OVS управляется, как обычный интерфейс операционной системы, а значит, идем в /etc/network/interfaces и делаем необходимые изменения — меняем eth0 на br1, eth0 пишем как manual:

auto eth0
iface eth0 inet manual

auto br1
iface br1 inet static
    address 192.168.*.160
    netmask 255.255.255.0
    gateway 192.168.*.1
    dns-nameservers 192.168.*.2

И все! Никаких дополнительных настроек bridge, как в случае с мостом.

Подключаем наш интерфейс к порту коммутатора, на котором настройки такие: trunk-порт для всех VLAN, для VLAN ID 1 трафик не тегирован. То есть порт пропускает транком все VLAN ID и трафик без VLAN вообще. Запускаем сеть командой ifup br1, после этого мы в сети. В некоторых случаях это может не сработать из-за правки файла настроек сети. Тогда можно попробовать запустить интерфейс вот так:

$ sudo ifconfig br1 up

Проверяем пингами доступность.

Посмотрим, что изменилось у нас на виртуальном коммутаторе:

$ sudo ovs-vsctl show
0b58d70f-e503-4ed2-833c-e24503f2e45f
Bridge "br1"
    Port "eth0"
        Interface "eth0"
    Port "br1"
        Interface "br1"
            type: internal
ovs_version: "2.5.2"

Как видим, в коммутатор подключено уже два интерфейса: физический интерфейс коммутатора eth0 и интерфейс операционной системы br1.

Теперь займемся виртуальными машинами.

Продолжение статьи доступно только подписчикам

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

Подпишись на журнал «Хакер» по выгодной цене!

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

2 комментария

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

Конкурс хаков: пишем на PowerShell скрипт, который уведомляет о днях рождения пользователей Active Directory

В компаниях часто встречается задача уведомлять сотрудников о приближающихся днях рождения…