Этот пост посвящён назначению контейнерам OpenVZ адресов из разных сетей на интерфейсе venet. Я решил написать этот пост потому, что видел как эту задачу решали другие специалисты неказистыми способами или же вовсе отказывались от использования venet.
Мы имеем хостноду openvz с контейнерами, которым нужно назначить реальные адреса и адреса во внутренней сети. Притом, у контейнера может быть или реальный, или внутренний, или оба адреса сразу. Реальные адреса и внутренняя сеть доступны из хостноды через разные сетевые сегменты. В моём примере они в разных vlan-ах, а внутренняя сеть представлена блоком адресов
ОС хостноды — CentOS 6.
Если просто добавить внутренний и внешний адрес контейнеру, то сеть в контейнерах не будет работать как надо: для всех назначений будет всегда выбираться самый первый адрес в качестве исходящего, а при выборе маршрута на хостноде будет использована таблица маршрутизации, непригодная для внутренней (внешней) сети.
Документация и рассылки openvz склоняют к использованию veth для такой сетевой конфигурации. Однако стараюсь не использовать veth по следующим причинам:
Поэтому игра стоит свеч и хотелось бы даже в такой конфигурации иметь сеть на контейнерах на venet-интерфейсах.
Как говорилось выше, проблема с venet-интерфейсами в том, что на них приходит всё вместе, а при отправке нужно разграничить исходящие адреса и выбрать разные машруты для них. Администраторы решают эту проблему по-разному, присовывая внутрь контейнера сбоку свои правила или меняя в ifup скриптах vz шаблон добавления адреса в контейнер. Я считаю, что сетевая конфигурация должна быть вне контейнера, чтобы не было проблем при миграции.
Действие происходит в
Внутренний интерфейс:
Внешний интерфейс:
Определим две дополнительные таблицы маршрутизации — для испускания виртуалками пакетов во внутреннюю сеть и во внешнюю. Две последние строки в файле ниже задают имена двум произвольно взятым свободным номерам для таблиц маршрутизации:
Определим содержимое этих таблиц:
И непосредственные подсети, и интернет доступны и с внутренних, и с внешних адресов, при этом внутренняя сеть связана с интернетом через NAT-шлюз (
Теперь нужно разделить, когда какие правила маршрутизации применять. По самим файлам трудно составить понимание, я дополню комментариями ниже.
Эти правила PBR добавляются снизу вверх, таким образом вторая строка оказывается первой и наоборот, а сами правила связаны с интерфейсом только тем, что добавляются когда этот интерфейс поднимается. Результирующая таблица правил:
Здесь видно, что всё из внешней сети, полученное через venet, маршрутизируется по правилам внешней сети (таблица external). Один или несколько адресов из внешней сети
Теперь наша хостнода в состоянии понять, что гасить сразу в интернет пакетами из серой сети и всё остальное в таком же духе не нужно.
Здесь всё просто, на venet можно добавлять не только /32 адреса в контейнере, но и адреса с обозначенной маской подсети. Это даёт ядру подсказку, что адреса из этого блока соседние, и что при отправке на них предпочтитетельнее использовать такой src:
По умолчанию будет выбираться первый адрес. Таким образом, если я поменяю местами адреса в конфиге контейнера, то контейнер будет стараться выбирать внутренний IP и хостнода будет направлять его в интернет через NAT-шлюз.
На мой взгляд venet это сильная сторона OpenVZ и по возможности лучше стараться пользоваться именно им. Решение выше позволяет контейнеру использовать сетевые адреса способом, абстрагированным от сетевой конфигурации.
Кроме того, я надеюсь, что помимо основного назначения пост послужит кому-то ещё и иллюстрацией использования policy based routing в Linux.
Окружение
Мы имеем хостноду openvz с контейнерами, которым нужно назначить реальные адреса и адреса во внутренней сети. Притом, у контейнера может быть или реальный, или внутренний, или оба адреса сразу. Реальные адреса и внутренняя сеть доступны из хостноды через разные сетевые сегменты. В моём примере они в разных vlan-ах, а внутренняя сеть представлена блоком адресов
192.168.1/24.ОС хостноды — CentOS 6.
Проблема
Если просто добавить внутренний и внешний адрес контейнеру, то сеть в контейнерах не будет работать как надо: для всех назначений будет всегда выбираться самый первый адрес в качестве исходящего, а при выборе маршрута на хостноде будет использована таблица маршрутизации, непригодная для внутренней (внешней) сети.
Документация и рассылки openvz склоняют к использованию veth для такой сетевой конфигурации. Однако стараюсь не использовать veth по следующим причинам:
- производительность veth ниже
- veth не накладывает на контейнер сетевых ограничений, это хуже в смысле безопасности
- veth в основном случае предполагает использование моста. Когда состав интерфейсов-членов моста меняется (контейнеры запускаются или останавливаются), MAC-адрес моста выбирается минимальным по численному значению из MAC-адресов интерфейсов-членов. Если вы останавливаете запускаете или останавливаете контейнер и вам не посчастливилось иметь новый MAC-адрес меньше текущего или останавливать контейнер, MAC-адрес которого сейчас у интерфейса моста, связь с host-нодой по этому интерфейсу будет утеряна, пока не залёрнится новый MAC на свитче. Это может произойти через не один десяток секунд в ряде случаев. Я решал эту проблему назначением виртуальным интерфейсам заведомо высоких MAC-адресов, но я не был в восторге от этого.
Поэтому игра стоит свеч и хотелось бы даже в такой конфигурации иметь сеть на контейнерах на venet-интерфейсах.
Решение
Как говорилось выше, проблема с venet-интерфейсами в том, что на них приходит всё вместе, а при отправке нужно разграничить исходящие адреса и выбрать разные машруты для них. Администраторы решают эту проблему по-разному, присовывая внутрь контейнера сбоку свои правила или меняя в ifup скриптах vz шаблон добавления адреса в контейнер. Я считаю, что сетевая конфигурация должна быть вне контейнера, чтобы не было проблем при миграции.
Выбираем нужный маршрут на хостноде
Действие происходит в
/etc/sysconfig/network-scripts, если не оговорено другого.Внутренний интерфейс:
[root@pve1 network-scripts]# cat ifcfg-vmbr0
DEVICE="vmbr0"
BOOTPROTO="static"
IPV6INIT="no"
DOMAIN="int"
DNS1="192.168.1.15"
DNS2="192.168.1.17"
GATEWAY="192.168.1.3"
IPADDR="192.168.1.142"
NETMASK="255.255.255.0"
ONBOOT="yes"
TYPE="Bridge"
Внешний интерфейс:
[root@pve1 network-scripts]# cat ifcfg-vmbr1
DEVICE="vmbr1"
BOOTPROTO="static"
IPADDR=200.200.100.6
NETMASK=255.255.254.0
IPV6INIT="no"
TYPE="Bridge"
Определим две дополнительные таблицы маршрутизации — для испускания виртуалками пакетов во внутреннюю сеть и во внешнюю. Две последние строки в файле ниже задают имена двум произвольно взятым свободным номерам для таблиц маршрутизации:
[root@pve1 network-scripts]# cat /etc/iproute2/rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
200 external
210 internal
Определим содержимое этих таблиц:
[root@pve1 network-scripts]# cat route-vmbr0
192.168.1.0/24 dev vmbr0 table internal
default via 192.168.1.3 table internal
[root@pve1 network-scripts]# cat route-vmbr1
200.200.100.0/23 dev vmbr1 table external
default via 200.200.100.30 table external
И непосредственные подсети, и интернет доступны и с внутренних, и с внешних адресов, при этом внутренняя сеть связана с интернетом через NAT-шлюз (
192.168.1.3). Как нам и надо.Теперь нужно разделить, когда какие правила маршрутизации применять. По самим файлам трудно составить понимание, я дополню комментариями ниже.
[root@pve1 network-scripts]# cat rule-vmbr0
from 192.168.1.0/24 iif venet0 lookup internal
from 192.168.1.0/24 to 192.168.1.0/24 iif venet0 lookup main
[root@pve1 network-scripts]# cat rule-vmbr1
from 200.200.100.0/23 iif venet0 lookup external
from 200.200.100.0/23 to 200.200.100.0/23 iif venet0 lookup main
Эти правила PBR добавляются снизу вверх, таким образом вторая строка оказывается первой и наоборот, а сами правила связаны с интерфейсом только тем, что добавляются когда этот интерфейс поднимается. Результирующая таблица правил:
[root@pve1 network-scripts]# ip ru li
0: from all lookup local
32762: from 200.200.100.0/23 to 200.200.100.0/23 iif venet0 lookup main
32763: from 200.200.100.0/23 iif venet0 lookup external
32764: from 192.168.1.0/24 to 192.168.1.0/24 iif venet0 lookup main
32765: from 192.168.1.0/24 iif venet0 lookup internal
32766: from all lookup main
32767: from all lookup default
Здесь видно, что всё из внешней сети, полученное через venet, маршрутизируется по правилам внешней сети (таблица external). Один или несколько адресов из внешней сети
200.200.100.0/23 может быть поднят на соседней виртуалке на этой же машине и тогда связываться с ним нужно не через физический интерфейс, а тоже через виртуальный. Поэтому для случая отправки из 200.200.100.0/23 в 200.200.100.0/23 я полагаюсь на главную таблицу маршрутизации, куда openvz добавляет соответствующие /32 маршруты, и в которой есть маршрут 200.200.100.0/23 через физический интерфейс для всего остального.Теперь наша хостнода в состоянии понять, что гасить сразу в интернет пакетами из серой сети и всё остальное в таком же духе не нужно.
Подсказываем контейнеру, какой выбирать исходящий адрес
Здесь всё просто, на venet можно добавлять не только /32 адреса в контейнере, но и адреса с обозначенной маской подсети. Это даёт ядру подсказку, что адреса из этого блока соседние, и что при отправке на них предпочтитетельнее использовать такой src:
[root@pve1 network-scripts]# fgrep IP /etc/vz/conf/138.conf
IP_ADDRESS="200.200.100.12/23 192.168.1.100/24"
[root@pve1 network-scripts]# vzctl exec 138 ip r
192.168.1.0/24 dev venet0 proto kernel scope link src 192.168.1.100
200.200.100.0/23 dev venet0 proto kernel scope link src 200.200.100.12
default dev venet0 scope link
По умолчанию будет выбираться первый адрес. Таким образом, если я поменяю местами адреса в конфиге контейнера, то контейнер будет стараться выбирать внутренний IP и хостнода будет направлять его в интернет через NAT-шлюз.
Заключение
На мой взгляд venet это сильная сторона OpenVZ и по возможности лучше стараться пользоваться именно им. Решение выше позволяет контейнеру использовать сетевые адреса способом, абстрагированным от сетевой конфигурации.
Кроме того, я надеюсь, что помимо основного назначения пост послужит кому-то ещё и иллюстрацией использования policy based routing в Linux.
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий