Содержание


Сеть OpenStack

Начало работы с ip-таблицами, таблицами, правилами и цепочками

Comments

Это статья о том, как сетевая технология OpenStack управляет ip-таблицами, цепочками и правилами. Но сначала давайте рассмотрим структуру ip-таблиц, чтобы освежить в памяти знания о технологии, которой посвящена эта статья.

Структура ip-таблицы

ip-таблица – это прикладная программа в пространстве пользователя, которая позволяет системному администратору настраивать таблицы, создаваемые межсетевым экраном ядра Linux; в частности, ip-таблицы относятся к IPv4.

Для настройки межсетевого экрана Linux используются правила, каждое из которых определяет, что искать внутри пакета и что делать, когда такой пакет найден. Цепочки – это перечни правил.

В предыдущем воплощении ip-таблиц, ip-цепочках, добавилась концепция цепочек правил; ip-таблицы распространили эту идею на таблицы. Итак, структура ip-таблиц такова: ip-таблицы > таблицы > цепочки > правила.

ip-таблица содержит четыре встроенных таблицы:

  • таблицу фильтров: это таблица по умолчанию со следующими цепочками:
    • INPUT для пакетов, поступающих в локальный сервер;
    • OUTPUT для пакетов, создаваемых локально и исходящих из локального сервера;
    • FORWARD для пакетов, проходящих через локальный сервер;
  • таблицу NAT (преобразование сетевых адресов):
    • PREROUTING: используется для целевых адресов NAT; изменяет IP-адреса пакетов перед маршрутизацией;
    • POSTROUTING: используется для исходных адресов NAT; изменяет IP-адреса пакетов после маршрутизации;
    • OUTPUT: адреса NAT для локально создаваемых пакетов на уровне межсетевого экрана;
  • корректирующую таблицу: для изменения специализированных пакетов:
    • PREROUTING
    • OUTPUT
    • FORWARD
    • INPUT
    • POSTROUTING
  • Raw-таблицу: для настройки исключений:
    • PREROUTING
    • OUTPUT

ip-таблица в OpenStack

В OpenStack имеются цепочки ip-таблиц и правила, преимущественно в модуле CloudCompute-Nova – контроллере фабрики облачных вычислений (основная часть системы IaaS), написанном на языке Python с использованием большого количества внешних библиотек. В этой статье рассматривается компонент сети nova-network FlatDHCPManager, а также другие компоненты OpenStack, необходимые для решения задач управления сетями.

При запуске OpenStack определяет некоторые цепочки OpenStack. Они образуют структуру цепочек со встроенными цепочками Linux. Еще одна задача, решаемая при запуске, – определение некоторых правил для сети фиксированного размера и службы метаданных. После создания и начала эксплуатации сети новая сеть устанавливает некоторые правила. При создании одного экземпляра (называемого сервером и ВМ) nova-compute создает одну цепочку для этого конкретного экземпляра и настраивает правила в этой цепочке, обеспечивающие подключение экземпляра. Что касается плавающих IP, то OpenStack также использует некоторые правила, чтобы обеспечить их работу. Кроме того, в правилах ip-таблиц закреплена группа безопасности OpenStack и ее правила.

Введение в OpenStack

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

В настоящее время в OpenStack входят шесть основных программных проектов:

  • Cloud Compute-Nova
  • Cloud Storage-Swift
  • Image Service-Glance (доставка и регистрация)
  • Identity Service-Keystone
  • Dashboard-Horizon
  • Network Connectivity-Quantum

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

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

  • nova-api предоставляет службу метаданных для виртуальных машин;
  • nova-compute настраивает сетевую среду для виртуальных машин;
  • nova-network устанавливает сетевую среду для всей облачной экосистемы, решая такие задачи, как распределение IP-адресов, настройка DHCP и т.п.

Модуль Nova состоит главным образом из набора Python-демонов, хотя и включает в себя ряд нативных системных компонентов для управления базами данных, обмена сообщениями и виртуализации. Он использует специальную службу метаданных, чтобы экземпляры виртуальных машин могли получать специфические для экземпляра данные. Экземпляры обращаются к службе метаданных по адресу: http://169.254.169.254.

В число метаданных входят открытые ключи SSH (определяются именем пары ключей при запросе пользователем нового экземпляра), данные пользователя (передаются в качестве параметра user_data в вызове API или флага --user_data в команде загрузки Nova). Службу метаданных реализует двоичный модуль nova-api.

OpenStack — это сложный набор компонентов. Чтобы больше узнать об этой системе и о том, как работает каждый из компонентов, познакомьтесь с обширными ресурсами по OpenStack в разделе Ресурсы.

Прежде чем перейти к правилам и цепочкам Nova, давайте рассмотрим режимы IP-адресации.

IP-адресация в Nova

Каждой виртуальной машине автоматически присваивается частный IP-адрес из каждой доступной сети nova-network. Эти IP-адреса называются фиксированными. При необходимости экземплярам можно назначить публичные IP-адреса. Для обозначения IP-адресов (обычно публичных), которые можно динамически добавлять к работающему виртуальному экземпляру, в OpenStack используется термин плавающий IP-адрес.

Существует несколько стратегий реализации фиксированных IP-адресов:

  • одноуровневый режим,
  • одноуровневый DHCP-режим,
  • режим VLAN DHCP,
  • режим nova-network с квантованием.

Одноуровневый режим

Одноуровневый режим – это простейший сетевой режим. Каждый экземпляр получает фиксированный IP-адрес из пула. По умолчанию все экземпляры подключены к одному и тому же мосту (br100). Мост нужно настраивать вручную. Конфигурация сети вводится в экземпляр до его загрузки. И в этом режиме нет функции плавающих IP-адресов.

Одноуровневый DHCP-режим

Аналогичен одноуровневому режиму в том плане, что все экземпляры подключены к одному и тому же мосту. В этом режиме некоторую настройку выполняет модуль Nova, пытаясь подключиться к Ethernet-устройству (по умолчанию eth0). Он также выполняет процесс dnsmasq в качестве dhcp-сервера, прослушивающего этот мост. Экземпляры получают фиксированные IP-адреса, выполняя процесс dhcpdiscover. Кроме того, предоставляется функция плавающих IP-адресов.

Режим VLAN DHCP

Это сетевой режим по умолчанию, который поддерживает большинство функций. Для установки с несколькими машинами требуется коммутатор, поддерживающий тегирование VLAN, управляемое из хоста. В этом режиме Nova создает VLAN и мост для каждого проекта (или «арендатора»). Проект получает набор частных IP-адресов, доступных только внутри сети VLAN. Чтобы пользователь мог обращаться к экземплярам своего проекта, нужно создать специальный экземпляр VPN (т.н. cloudpipe). Nova создает сертификат и ключ для доступа пользователя к VPN и автоматически запускает VPN.

Режим nova-network с квантованием

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

Группа безопасности в Nova – это именованная коллекция правил доступа к сети, такая как политики межсетевого экрана. Эти правила доступа указывают, какой входящий сетевой трафик должен доставляться всем экземплярам ВМ группы; весь остальной входящий трафик отсеивается. Пользователи могут в любое время изменять правила группы. Новые правила применяются автоматически для всех запущенных экземпляров и экземпляров, запускаемых с этого момента. Группу безопасности можно рассматривать как профиль безопасности или роль безопасности, например, веб-сервер приложений (webappserver).

Правила и цепочки ip-таблиц

Как было сказано выше, ip-таблица – это прикладная программа в пространстве пользователя, которая позволяет системному администратору настраивать таблицы, создаваемые межсетевым экраном ядра Linux, а также содержащиеся в нем цепочки и правила.

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

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

Цепочки, создаваемые при запуске nova-network

Рисунок 1. Соединение класса NetworkManager с другими классами
Соединение класса NetworkManager с другими классами
Соединение класса NetworkManager с другими классами

Как показано на рисунке 1, NetworkManager — это большой класс, который соединен со многими другими классами, или модулями. Один из этих классов, или модулей, – linux_net. Он содержит объект IptablesManager, метод __init__() которого инициализирует цепочки, определенные в системе OpenStack.

Рисунок 2. Инициализация цепочек
Инициализация цепочек
Инициализация цепочек

Как говорилось выше, таблицы правил фильтрации пакетов IPv4 в ядре Linux содержат несколько встроенных цепочек: PREROUTING, INPUT, FORWARD, OUTPUT и POSTROUTING. В общем случае пакет, поступивший в Linux-узел, передается в цепочку PREROUTING. После ее прохождения ядро принимает решение о маршрутизации. Если пакет предназначен для хост-машины Linux, он поступает в цепочку INPUT и если принимается, то передается в целевой процесс. Если пакет не предназначен для хост-машины Linux, он поступает в цепочку FORWARD, затем в цепочку POSTROUTING, после чего покидает узел. Пакеты, созданные локальными процессами, сначала поступают в цепочку OUTPUT и если принимаются, то передаются в цепочку POSTROUTING.

Помимо этих встроенных цепочек, система OpenStack создает некоторые другие, подключенные к системе цепочек. Цепочки OpenStack бывают двух типов — неизолированные и изолированные.

Примером неизолированных цепочек служат цепочки nova-filter-top и nova-postrouting-bottom. Nova-filter-top добавляется к вершине цепочек FORWARD и OUTPUT. Ее имя не изолировано, поэтому она обобщается между различными процессами Nova. Эта цепочка предназначена для правил, которые должны оставаться в верхней части цепочек FORWARD и OUTPUT. Она присутствует в наборе таблиц IPv4 и IPv6.

Примером изолированных цепочек служат цепочки, показанные зеленым цветом. Имя этих цепочек содержит имя процесса в виде суффикса. Например, nova-network создает цепочку nova-network-PREROUTING.

В IPv4 и IPv6 встроенные цепочки фильтров INPUT, OUTPUT, и FORWARD изолированы, то есть «реальная» цепочка INPUT содержит правило, которое переходит в изолированную цепочку INPUT и т.д. Кроме того, существует изолированная цепочка local, перешедшая из nova-filter-top.

Для IPv4 встроенные цепочки PREROUTING, OUTPUT и POSTROUTING NAT изолированы тем же способом, что и встроенные цепочки фильтров. Существуют также цепочки sNAT и float-sNAT, которые применяются после цепочки POSTROUTING.

Правила, выполняемые при запуске nova-network

На рисунке 3 показана часть процесса запуска FlatDHCPManager. Метод __init__(), который создает объект IptableManager для создания многих цепочек OpenStack, был описан выше. Поэтому здесь мы сосредоточимся на методе init_host(). Метод init_host() вызывает метод initialize() из LinuxNet3, который вызывает методы из linux_net для настройки некоторых правил ip-таблиц в таблице NAT.

Рисунок 3. Процесс запуска FlatDHCPManager
Процесс запуска FlatDHCPManager
Процесс запуска FlatDHCPManager

(Увеличенная версия рисунка 3).

Рассмотрим эти правила.

Правило для узла метаданных

Одно из правил, созданных методом init_host() из linux_net, позволяет IP-адресам из FLAGS.fixed_range обращаться к узлу метаданных (metadata_host – в данном случае 192.168.1.90).

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 192.168.1.90/32 -j ACCEPT

ensure_metadata_ip() добавляет адрес 169.254.169.254/32 к устройству lo с помощью следующей команды:

# ip addr add 169.254.169.254/32 scope link dev lo

Затем metadata_forward() добавляет правило dNAT для маршрутизации пакетов из 169.254.169.254/32 в metadata_host:

-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT
--to-destination 192.168.1.90:8775

Если nova-network и nova-api не работают в одном и том же узле, то необходимо определить metadata_host в узле nova-network, чтобы он указывал на узел nova-api.

Правило доступа к dmz

FLAGS.dmz_cidr определяет список классов CIDR (классы междоменной маршрутизации) dmz (периметра сети). По умолчанию это пустой список. В данном случае – 10.128.0.0/24. Так что правило выглядит следующим образом:

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.128.0.0/24 -j ACCEPT

Правило для соединения ВМ друг с другом

Еще одно правило обеспечивает соединение друг с другом двух ВМ с фиксированными IP-адресами:

-A nova-network-POSTROUTING -s 10.0.0.0/8 -d 10.0.0.0/8 -m conntrack ! --ctstate DNAT 
-j ACCEPT

Правило доступа вне фиксированной подсети

Метод add_snat_rule() добавляет правило sNAT в изолированную цепочку sNAT таблицы NAT. ip_range и FLAGS.routing_source_ip представлены на рисунке 3. Значение ip_range определяется в FLAGS.fixed_range. В данном случае это 10.0.0.0/8. По умолчанию FLAGS.routing_source_ip – это FLAGS.my_ip; значение по умолчанию задается функцией flags._get_my_ip(). В данном случае FLAGS.my_ip имеет значение 192.168.1.90. В результате получаем следующее правило:

-A nova-network-snat -s 10.0.0.0/8 -j SNAT --to-source 192.168.1.90

Для доступа фиксированных IP-адресов к внешней сети необходимо создать сеть, которая будет подсетью FLAGS.fixed_range. Таким образом, когда шлюз по умолчанию указывает на один IP-адрес br100 на машине nova-network, ВМ с IP-адресами этой подсети могут обращаться к внешней сети.

Правила для каждой сети

Чтобы настроить сеть, nova-network создает правила в таблице фильтров. Для запуска nova-network в данной сети выполняются следующие команды.

  1. Создать сеть и настроить узел:
    # ./bin/nova-manage network create mynet 10.10.10.0/24
  2. Загрузить сервер:
    nova boot --image a3fb743d-42df-49ba-b9c4-8042ebbd344e --flavor 1 myserver

После выполнения этих команд у вас будут следующие правила.

  1. Разрешение передачи трафика через мост, так что IP-адрес в br100 может работать в качестве шлюза:
    -A nova-network-FORWARD -i br100 -j ACCEPT
    -A nova-network-FORWARD -o br100 -j ACCEPT
  2. Разрешение трафику из DHCP и DNS поступать в локальный процесс dnsmasq:
    -A nova-network-INPUT -i br100 -p udp -m udp --dport 67 -j ACCEPT 
    -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 67 -j ACCEPT
    -A nova-network-INPUT -i br100 -p udp -m udp --dport 53 -j ACCEPT
    -A nova-network-INPUT -i br100 -p tcp -m tcp --dport 53 -j ACCEPT

Примечание. 67 — это порт DHCP, а 53 – порт DNS.

Правила для узла nova-compute

Модуль nova-compute также создает изолированные цепочки. В этих цепочках он создаёт некоторые правила в таблице фильтров. Рассмотрим их.

Правила, разрешающие трафику пересекать мост

Эти правила для узла nova-compute позволяют ВМ соединиться с узлом nova-network и ВМ из других вычислительных узлов.

-A nova-compute-FORWARD -i br100 -j ACCEPT 
-A nova-compute-FORWARD -o br100 -j ACCEPT

Цепочка и правила для каждого экземпляра

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

Рисунок 4. Цепочка и правила для каждого экземпляра
Цепочка и правила для каждого экземпляра
Цепочка и правила для каждого экземпляра
  1. Nova-compute создает одну цепочку для каждого экземпляра. Имя цепочки на рисунке 4 – nova-compute-inst-1.
  2. Весь трафик, предназначенный для этого экземпляра, независимо от того, перенаправлен ли он или сгенерирован локальным процессом, поступает в указанную цепочку данного экземпляра.
  3. Весь трафик из IP-адресов подсети, в которой находится экземпляр, разрешен.
  4. Весь трафик DHCP от указанного DHCP-сервера разрешен.
  5. Весь остальной трафик блокируется.

nova-api

При запуске nova-api создает правило в таблице фильтров, разрешающее другим обращаться к службе nova-api.

-A nova-api-INPUT -d 192.168.1.90/32 -p tcp -m tcp --dport 8775 -j ACCEPT

Плавающие IP-адреса

Чтобы увидеть, как реализованы плавающие IP-адреса, сначала свяжем плавающий IP-адрес с фиксированным IP-адресом экземпляра. Фиксированный IP-адрес созданного ранее экземпляра — 10.10.10.2.

Создание плавающего IP-адреса в пуле по умолчанию

Создадим в пуле по умолчанию плавающий IP-адрес:

# nova-manage floating create --ip_range=192.168.1.232/30

Выделим плавающий IP-адрес из этого пула:

# Nova floating-ip-create

Мы получили IP 192.168.1.233. Теперь присвоим его экземпляру с идентификатором 8f773639-c04f-4885-9349-ac7d6a799843:

# nova add-floating-ip 8f773639-c04f-4885-9349-ac7d6a799843 192.168.1.233

Привязка плавающего IP-адреса к публичному интерфейсу

Для привязки плавающих IP-адресов используется FLAGS.public_interface. Выполнив команду nova add-floating-ip, получим следующий плавающий IP-адрес в public_interface:

# ip addr list dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 08:11:96:75:91:54 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.90/16 brd 192.168.255.255 scope global wlan0
    inet 192.168.1.233/32 scope global wlan0
    inet6 fe80::a11:96ff:fe75:9154/64 scope link 
       valid_lft forever preferred_lft forever

Правила для плавающих IP-адресов в NAT-таблице

Когда экземпляр получил плавающий IP-адрес на хосте nova-network, действуют следующие правила:

-A nova-network-OUTPUT -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2
-A nova-network-PREROUTING -d 192.168.1.233/32 -j DNAT --to-destination 10.10.10.2 
-A nova-network-float-snat -s 10.10.10.2/32 -j SNAT --to-source 192.168.1.233

Как видите, правило dNAT используется для перевода плавающего IP-адреса в фиксированный IP-адрес экземпляра. Если в узел nova-network прибывает пакет с плавающим IP-адресом в качестве целевого IP-адреса, целевой IP-адрес переводится. Далее, имеется правило sNAT, которое переводит трафик из фиксированного IP-адреса экземпляра в плавающий IP-адрес. Так как весь трафик от виртуальных машин вне фиксированной сети направляется в шлюз, который настроен процессом nova-network dnsmasq, с помощью этого правила sNAT трафик из ВМ можно успешно замаскировать как трафик из плавающих IP-адресов. Кроме того, в изолированной цепочке OUTPUT есть правило dNAT, которое позволяет местному процессу в nova-network обращаться к ВМ с плавающими IP-адресами.

Пингование ВМ с плавающим IP-адресом

Для пингования ВМ с плавающими IP-адресами необходимы еще несколько правил. В nova-computehost есть специальные цепочки для каждого экземпляра; содержащиеся в них правила разрешают трафик только из IP-адресов фиксированной подсети. При пинговании плавающего IP-адреса трафик будет блокироваться этими правилами, так как исходный IP-адрес ping-пакета не находится в пределах фиксированной подсети. Очевидно, что нужно добавить правило, разрешающее трафик icmp.

Чтобы добавить правило, разрешающее пингование, используем концепцию правил группы безопасности OpenStack:

# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0

После этого появится еще одно правило, созданное в цепочке данного экземпляра:

-A nova-compute-inst-1 -p icmp -j ACCEPT

Таким же образом можно разрешить трафик SSH в ВМ с плавающим IP-адресом.

Заключение

В сети OpenStack широко используются правила iptables. Ее концепции группы безопасности и плавающих IP-адресов – лишь начало использования правил iptables. Изучив приведенные ниже ресурсы, вы узнаете о среде IaaS OpenStack гораздо больше.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Open source
ArticleID=1009301
ArticleTitle=Сеть OpenStack
publish-date=06242014