vnet
Материал из Xgu.ru
Автор: Игорь Чубин
Vnet — средство Xen, позволяющее объединять виртуальные мосты на различных хост-системах между собой. Аналогично тому как VLAN'ы в реальных коммутаторах объединяются между собой с помощью каналов, передающих тэгированный трафик.
Содержание |
[править] Общая информация
Пользовательские домены Xen не обязательно должны работать на одной хост-системе. Они могут мигрировать между несколькими хост-системами, причём процесс миграции для стороннего наблюдателя в идеале должен быть абсолютно незаметным. С другой стороны, в пределах хост-системы, домены могут быть соединены с помощью виртуальных мостов в сеть произвольной топологии. Необходимо, чтобы виртуальная сеть работала одинаково вне зависимости от того, на какой хост-системе сейчас находится тот или иной пользовательский домен.
Такого результата можно добиться с помощью распределённых мостов. Распределённый мост может быть представлен мостами на нескольких хост-системах. При поступлении пакета по любому из интерфейсов распределённого моста, он должен попадать на все остальные виртуальные мосты, входящие в этот распределённый мост.
Распределённые мосты в Xen реализуются с помощью vnet'ов.
[править] Что такое vnet?
Xen предоставляет поддержку сетей для доменов с помощью, так называемых, vnet'ов.
Они эмулируют виртуальные частные сети доменов. Домены, находящиеся в одном vnet'е, могут размещаться на одной машине или на отдельных машинах, и vnet'ы остаются подсоединёнными во время миграции доменов. Ethernet-трафик внутри vnet'а туннелируется внутрь IP-пакетов передающихся по физической сети. Vnet - это виртуальная сеть и адресация внутри этой сети не имеет никакого отношения к адресации в физической сети. Отдельные vnet'ы или vnet'ы и физическую сеть можно соединить с помощью доменов Xen, имеющих более чем один сетевой интерфейс, и включённой поддержкой forwarding'а или bridging'а.
Изнутри vnet больше всего похож на коммутатор с поддержкой VLAN'ов: пакеты передаются на интерфейсы исходя из их vnet id. Пакеты vnet передающиеся по сети помечаются идентификаторами vnet id, точно также как пакеты в тегированных каналах, передающиеся между коммутаторами, помечаются VLAN ID. После того как пакет приходит, из него убирается vnet id, и этот пакет передаётся на соответствующий интерфейс.
[править] Различия между VLAN и vnet
На первый взгляд может показаться, что всё что делают vnet'ы можно сделать с помощью обычных VLAN'ов и мостов. В действительности между ними есть несколько принципиальных отличий:
- Для vnet'ов не нужен специальный коммутатор. Для того чтобы VLAN'ы работали, необходим коммутатор, который их поддерживает. Кроме того, коммутатор должен быть соответствующим образом сконфигурирован. Vnet'ы не предъявляют никаких дополнительных требований к сети. Они могут использоваться в любой коммутируемой среде.
- Использование vnet'ов поверх маршрутизируемой IP-сети. Поскольку в Vnet ethernet-кадры туннелируются в IP, между vnet'ами сеть может быть не только коммутируемой, но и маршрутизируемой.
- Несколько инфраструктур vnet в одной сети. Можно одновременно использовать несколько различных инфраструктур Vnet в одной сети - для этого достаточно настроить эти инфраструктуры на разные multicast-адреса.
- Длина идентификатора vnet. В отличие от VLAN'ов 802.1Q, где выделяется только 12 битов на vlan id, в vnet'ах на идентификатор выделяется 128 битов.
- Безопасность. Vnet'ы поддерживают шифрование. Сейчас для этого применяется IPsec.
[править] Альтернативы
Альтернатив, которые бы могли заменить Vnet'ы полностью, не существует. Однако, в некоторых случаях, можно обойтись без Vnet'ов, используя другие технологии.
[править] VLANы
Если хост-системы Xen соединяются между собой коммутируемой сетью, с поддержкой тегированного трафика 802.1Q, можно обойтись без VNET'ов. Для этого нужно подключить каждую хост-систему транковым каналом и поднять на этих хост-системах VLAN-интерфейсы. VLAN-интерфейсы нужно подключить к соответствующим виртуальным мостам.
Подробнее о настройке VLAN'ов в Linux:
[править] Средства передачи тегированного трафика
Если хост-системы не соединяются с помощью коммутируемой сети, с поддержкой VLAN'ов, альтернатив у Vnet практически нет.
Можно попробовать добиться передачи тегированного трафика между хост-системами двумя способами:
- OpenVPN Ethernet Bridging. OpenVPN может соединять две коммутируемые сети в режиме моста. В этом случае, через него может передаваться и тегированный трафик (не проверялось).
- Vtun. Детально описание процедуры на странице [1];
- MPLS. Сеть MPLS в состоянии переносить тегированный трафик Ethernet.
[править] Использование vnet
- (здесь представлена выдержка из "Руководства пользователя Xen")
Поддержка vnet включена в xm и в xend. Команда
%# xm vnet-create <config>
создаёт vnet на основе конфигурационного файла <config>. После того как vnet создан, его конфигурация сохраняется xend, vnet становится постоянным, и он будет существовать до тех пор пока он не будет удалён с помощью команды:
%# xm vnet-delete <vnetid>
Список vnets, о которых знает xend, можно получить командой:
%# xm vnet-list
Другие команды по управлению vnet'ами доступны через программу vn, входящую в дистрибутив vnet.
Формат конфигурационного файла vnet такой:
(vnet (id <vnetid>)
(bridge <bridge>)
(vnetif <vnet interface>)
(security <level>))
Пробелы не имеют существенного значения.
Параметры:
- <vnetid>: vnet id, 128-битный идентификатор vnet. Он может быть задан как 8 4х-разрядных шестнадцатеричных числа, разделенных двоеточиями или, в сокращённой форме, как одно 4х-разрядное число. В последнем случае 7 первых полей заполняется нулями. Идентификаторы vnet id должны быть ненулевыми и идентификатор 1 зарезервирован.
- <bridge>: имя моста для vnet'а. Домены подсоединяются к vnet'у путём подсоединения виртуального интерфейса к этому мосту. Длина имени моста ограничивается ядром до 14 символов.
- <vnetif>: имя виртуального интерфейса vnet (опционально). Интерфейс инкапсулирует и декапсулирует трафик vnet в сеть. Он подсоединён к мосту vnet. Длина имени интерфейса ограничивается ядром до 14 символов.
- <level>: уровень безопасности для vnet (опционально). Уровень может принимать одно из следующих значений
- none: нет безопасности (по умолчанию). Трафик vnet передаётся в открытом виде.
- auth: аутентификация. Трафик vnet аутентифицируется с помощью IPSEC ESP hmac96.
- conf: конфиденциальность. Трафик vnet аутентифицируется и шифруется IPSEC ESP hmac96 и AES-128.
- Аутентификация и конфиденциальность поддерживаются в экспериментальном режиме; сейчас в них используются hard-wired ключи.
Когда vnet создаётся, его конфигурация сохраняется xend -- vnet существует до тех пор, пока его не удалят командой:
%# xm vnet-delete <vnetid>
Интерфейсы и мосты, которые использует vnet, видны по командам ifconfig и brctl show.
[править] Пример
Предположим, содержимое файла vnet97.sxp выглядит так:
(vnet (id 97) (bridge vnet97) (vnetif vnif97)
(security none))
После этого команда 'xm vnet-create vnet97.sxp определяет vnet с идентификатором 97 и без обеспечения безопасности. Мост для vnet'а называется vnet97, а виртуальный интерфейс -- vnif97. Для того чтобы добавить интерфейс домена в этот vnet, нужно установить в конфигурационном файле мост соответствующего интерфейса равным vnet97.
В python'е:
vif="bridge=vnet97"
В sxp:
(dev (vif (mac aa:00:00:01:02:03) (bridge vnet97)))
Как только домен стартанул, его интерфейс должен быть виден в выводе команды brctl show в портах vnet97.
Для получения наивысшей производительности стоит уменьшить MTU доменных интерфейсов, смотрящих в vnet, до 1400. Это можно сделать, например, с помощью команды 'ifconfig eth0 mtu 1400 или установив строку MTU=1400 в файле ifcfg-eth0. После этого может понадобиться удалить кэшированные файлы для интерфейса eth0 в каталоге /etc/sysconfig/networking. Vnet'ы будут работать в любом случае, но производительность может пострадать от IP-фрагментации, вызванной инкапсуляцией vnet'ов и выходом за пределы аппаратного MTU.
[править] Инсталляция поддержки vnet
Vnet реализуется модулем ядра, и модуль должен быть загружен до того как буду использоваться vnet'ы. Это можно сделать до старта xend вручную с помощью команды vn insmod или же настроить xend вызывать скрипт network-vnet, указав в конфигурационном файле /etc/xend/xend-config.sxp строку:
(network-script network-vnet)
Этот скрипт загружает модуль ядра с помощью insmod, а затем вызывает скрипт network-bridge.
Код vnet по умолчанию не компилируется и не устанавливается. Для того чтобы откомпилировать код и установить его на текущей системе, нужно вызвать make install в корне дерева исходников vnet, tools/vnet/. Также можно установить vnet в инсталляционный каталог с помощью make dist. Подробности об этом можно найти в Makefile в каталоге исходных текстов.
По умолчанию модуль vnet создаёт интерфейсы vnif0002, vnif0003 и vnif0004. Проверить работают vnet'ы или нет можно так: настроить на них IP-адреса и попробовать их с помощью ping. Например, для машин hostA и hostB:
hostA# ifconfig vnif0004 10.0.0.100 up hostB# ifconfig vnif0004 10.0.0.101 up hostB# ping 10.0.0.100
Реализация vnet использует IP-multicast для обнаружения интерфейсов vnet, поэтому все машины, на которых есть vnet'ы, должны быть доступны по multicast'у. Сетевые коммутаторы часто сконфигурированы так, что бы не ретранслировать multicast пакеты, это означает что все машины, использующие vnet, должны быть в том же сегменте сети на канальном уровне, за исключением случая, когда сконфигурирован vnet forwarding.
Проверить покрытие multicast можно пропинговав multicast-адрес vnet:
%# ping -b 224.10.0.1
Должны прийти ответы от всех машин, на которых работает модуль vnet. Посмотреть передаются ли и принимаются ли пакеты vnet можно просматривая трафик UDP на порту vnet:
%# tcpdump udp port 1798
Если многоадресные (multicast) пакеты не передаются между хостами, multicast forwarding можно настроить с помощью vn. Предположим, есть хост hostA с адресом 10.10.0.100 и hostB с адресом 10.11.0.100, и multicast forwarding между ними не выполняется. Настройка передачи между хостами выполняется с помощью vn:
hostA# vn peer-add hostB hostB# vn peer-add hostA
Multicast forwarding нужно использовать очень осторожно -- нужно избегать петель. Как правило, только одну машину в сети нужно настраивать на передачу (forward), x она будет передавать многоадресные пакеты, полученные от других машин в сети.
[править] Вопросы и ответы
Вопрос: Может ли один виртуальный интерфейс принадлежать нескольким vnet'ам одновременно?
Ответ: Нет. Vnet как VLAN -- как интерфейс может попадать только в один VLAN (транки не в счёт), так интерфейс может быть подключен только к одному vnet'у.
Если нужно чтобы домен получал доступ сразу к нескольким vnet'ам, нужно сделать у него несколько сетевых интерфесов, точно также как для того чтобы компьютеру получить доступ к нескольким сетям, ему нужно сделать несколько сетевых карт.
Вопрос: Можно ли включить мост в несколько vnet'ов?
Ответ: Vnet'ы реализованы с помощью специального vnet-интерфейса, пакеты попадающие на этот интерфейс туннелируются в многоадресные IP-пакеты. Vnet-интерфейс соединяется с виртуальным интерфейсом с помощью моста. К одному мосту должен подключаться только один vnet-интерфейс.
Вопрос: Как выполняется управление ключами для режимов безопасности auth и conf?
В качестве message transform используется IPSEC ESP. Ключи и шифры в настоящий момент жёстко зашиты.
Сейчас используется своя собственная реализация IPSEC ESP, но в итоге она будет заменена на реализацию из ядра Linux. Это связано с тем, что поддержка IPSEC появилась ещё в Xen 1.0, и тогда не было возможности использовать IPSEC в Linux, нужно было писать свой собственный.
Вопрос: Какие режимы безопасности сейчас есть?
Ответ: Сейчас есть три режима: none, auth и conf. В режиме none безопасность vnet'ов вообще не обеспечивается; в auth используется HMAC; в conf используется ESP+HMAC, шифр AES-CBC-128 и жёстко зашитые ключи.
Вопрос: Как можно различить другой правильный Xen-хост, на котором работают Vnet'ы, и злонамеренный замаскировавшийся хост, который угадал vnetid и настройки безопасности?
Ответ: Поскольку используются жёстко зашитые ключи (hard-coded keys), пока что никак. Если бы IPSEC использовался как следует, этой проблемы бы не было: или хосты бы использовали одинаковую SA (и следовательно, оба знали shared secret), или с помощью IKE они обсуждали бы договаривались о сертификатах и SA. Если использовать vnet'ы без дополнительных средств повышения безопасности, предотвратить спуфинг невозможно.
[править] Дополнительная информация
Страница составлена на основании материалов списков рассылки Xen и руководства пользователя Xen:
- Руководство пользователя Xen
- Сообщения про Vnet в списке рассылки Xen: [2], [3], [4]
О средствах передачи тегированного Ethernet-трафика через IP-сеть можно прочитать здесь:
- http://gentoo-wiki.com/HOWTO_OpenVPN_Server_for_Ethernet_Bridging_with_Server_Certificates
- Re: (Openvpn-users) openvpn and VLAN - обсуждение в списке рассылки OpenVPN
 |
|
|---|
 |
|
|---|
