Как стать автором
Обновить

OpenVZ + venet + vlan/адреса из разных сетей

Время на прочтение 5 мин
Количество просмотров 11K
Этот пост посвящён назначению контейнерам OpenVZ адресов из разных сетей на интерфейсе venet. Я решил написать этот пост потому, что видел как эту задачу решали другие специалисты неказистыми способами или же вовсе отказывались от использования venet.

Окружение


Мы имеем хостноду 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.
Теги:
Хабы:
+17
Комментарии 15
Комментарии Комментарии 15

Публикации

Истории

Работа

DevOps инженер
39 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн