OpenVZ veth etcnet

Здесь приведена информация, добытая в глубинах различных источников, которую я собрал для попытки описать максимально просто и последовательно, что же нужно сделать, чтобы получить следующее.

Работа с интерфейсом veth, etcnet и скриптами openvz

Конфигурация veth интерфейса с помощью etcnet

В различной документации для настройки veth-интерфейса для контейнера openvz предлагается использовать вручную вводимые команды или их наборы, помещаемые в стартовые скрипты(например). При наличии Etcnet дублировать (часть настраивать с помощью него, а часть нет) настройку не удобно, поэтому тут я привожу вариант только с помощью etcnet.

1. включить форвардинг пакетов на ноде в файле /etc/net/sysctl.conf:

net.ipv4.ip_forward = 1

2. создать и стартовать контейнер, но не добавлять адрес с помощью vzctl set --ipadd (он добавит интерфейс типа venet)

vzctl start 101

3. добавить veth-интерфейс в контейнер (формат команды подходит для vzctl 3.0.22, варианты см. по ссылке «например» выше).

vzctl set 101 --netif_add eth0 --save

при этом vzctl запишет в конфиг vz строку такого вида:

NETIF="ifname=eth0,mac=00:18:51:62:4E:08,host_ifname=veth101.0,host_mac=00:18:51:21:5F:E4"

первый mac-адрес будет использоваться для интерфейса в контейнере (обычный eth0 или как было задано в команде добавления)), а второй — для интерфейса на ноде (у него будет имя veth<номер ve>.0). mac-адреса можно указать и вручну, а если нет — то они вычислятся автоматически. Конечно, они не должны быть одинаковыми с соседними онтерфейсами (и вообще ни с чем в сети).

4. создать на ноде папку по имени интерфейса в etc/net/ifaces, а в нее положить такие файлы:

• ipv4address:

0 dev veth101.0

• ipv4route:

10.1.10.10 dev veth101.0

• options:

TYPE=eth
BOOTPROTO=static
ONBOOT=yes
USE_HOTPLUG=yes

• sysctl.conf:

proxy_arp=1
ipv4_forwarding=1

файл ipv4address запустит интерфейс, но не назначит ему адреса (адрес присуствует у части, которая внутри VE, а снаружи — нет). файл ipv4route пропишет маршрут для адреса VE на конкретный интерфейс на ноде. файл options содержит важную опцию USE_HOTPLUG, она позволяет запускать интерфейс только тогда, когда VE реально стартует, без нее при старте сети будет ругань на невозможность сконфигурировать отсутствующий интерфейс. файл sysctl.conf задает параметры sysctl для конкретного интерфейса, используя автодополнение

5. такой же файл sysctl.conf надо положить в каталог физического eth-интерфейса сервера (eth0, если вы не переименовали его).

• sysctl.conf:

proxy_arp=1
ipv4_forwarding=1

6. Теперь надо зайти в VE (например, vzctl enter 101) и настроить интерфейс там. Положить следующие файлы в каталог etc/net/ifaces/eth0/ (если при создании вы назвали его eth0):

• ipv4address:

10.1.10.10/32

• ipv4route:

default dev eth0
replace default via 10.1.10.150 dev eth0

• options:

TYPE=eth
BOOTPROTO=static
ONBOOT=yes

Здесь 10.1.10.10 — это адрес, который присваивается интерфейсу внутри VE, а 10.1.10.150 — адрес, присвоенный физическому интерфейсу на ноде. replace заменит маршрут по умолчанию, что необходимо когда HN и VE находятся в разных сетях.

Проверка результатов

Теперь можно проверить, что получилось:

Выключить VE

vzctl stop 101

Рестартовать сеть на ноде

service network restart

и обратить внимание на предупреждения, если такие будут

Включить VE

vzctl start 101

и проверить наличие интерфейса veth и маршрута:

ip a
ifconfig
route -n

например, оно может выглядеть так:

2: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
14: extbi: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:19:99:01:4b:82 brd ff:ff:ff:ff:ff:ff
   inet 10.1.10.150/16 brd 10.1.255.255 scope global extbi
21: veth1040.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
   link/ether 00:18:51:21:5f:e4 brd ff:ff:ff:ff:ff:ff

extbi     Link encap:Ethernet  HWaddr 00:19:99:01:4B:82
         inet addr:10.1.10.150  Bcast:10.1.255.255  Mask:255.255.0.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
lo        Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
veth1040.0 Link encap:Ethernet  HWaddr 00:18:51:21:5F:E4
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

10.1.10.40      0.0.0.0         255.255.255.255 UH    0      0        0 veth1040.0
10.1.0.0        0.0.0.0         255.255.0.0     U     0      0        0 extbi

и при этом обязательно должны быть включены forwarding и proxy_arp на соотв. интерфейсах (п .3 и 4)

[node]# cat /proc/sys/net/ipv4/conf/extbi/proxy_arp
1
[node]# cat /proc/sys/net/ipv4/conf/veth1040.0/proxy_arp
1

аналогично с forwarding.

с другого компьютера сети можно запустить ping

$ ping 10.1.10.10
PING 10.1.10.10 (10.1.10.10) 56(84) bytes of data.
64 bytes from 10.1.10.10: icmp_seq=1 ttl=64 time=2.82 ms

при этом в arp-таблице ноды появится запись

#arp
samba.local              ether   00:18:51:62:4E:08   C                     veth101.0

Если же у вас не так — смотрите, где что перепутано или забыто ;)

Как добиться прохождения broadcast в VE с интерфейсом veth

Если вы сделали все вышеописанное, то у вас будут работать сервисы в контейнере, которые получают пакеты, адресованные непосредственно им. (Такие как FTP, DNS, LDAP и другие). Но они работали бы и с интерфейсом venet, а veth обычно настраивают тогда, когда хотят поместить в контейнер что-то, что получало бы пакеты типа broadcast, адресованные всей подсети. Но на данном этапе работать это не будет ;) Причина в том, что в такой конфигурации между контейнером и остальной сетью есть роутер (это HN). Это можно легко проверить:

# traceroute -n 10.1.10.40
traceroute to 10.1.10.40 (10.1.10.40), 30 hops max, 40 byte packets
 1  10.1.10.150 (10.1.10.150)  0.149 ms   0.123 ms   0.119 ms
 2  10.1.10.40 (10.1.10.40)  0.139 ms   0.116 ms   0.118 ms

Т.е. пакеты из наружной сети проходя сначала через HN, но broadcast-пакеты роутеры не передают. Поэтому если поместить в такой контейнер сервисы типа DHCP или Samba, то работать они будут некорректно: например, Samba сможет работать как WINS-сервер, регистрируя имена тех, кто прямо укажет у себя адрес WINS-сервера, но она не сможет ответить за широковещательный запрос о наличии в сети master browser. Поэтому остальные машины выберут master browser кого-то другого, а не этот Samba-сервер ;)

А вот чтобы все же такие рассылки проходили и в этот контейнер, нужно сделать следующее.

1. Создать интерфейс типа bridge, как описано в пункте 3.6 статьи Etcnet. Поместить в него только один интерфейс, который является физическим ethernet на HN. С ним позже будет связываться интерфейс типа veth, который расположен на HN.

2. Использовать статью (и в частности раздел) OpenVZ wiki, где описано какие внести изменения в файлы конфигурации контейнера на HN.

3. Использовать приведенный там скрипт vznetcfg.custom, поместив его куда-нибудь, например в /usr/local/sbin/. Но исправить путь brctl=/usr/sbin/brctl

на /sbin.