Вопрос по linux c OpenVZ контейнерами

Как-то немного туманно у вас написано, но сделаю предположение: у вас есть сеть, в ней хост, на хосте виртуалка, виртуалка в другой сети, чем хост. Так?

Если так, то вам нужна маршрутизация: во-первых, системе должно быть разрешено перебрасывать пакеты («echo 1 >/proc/sys/net/ipv4/ip_forward» при загрузке или соответствующая запись в /etc/sysctl.conf), а во вторых нужно, чтобы шлюз знал адрес машины в сети, которая имеет доступ в сеть контейнера.

Типа:

хост:

eth0: 192.168.1.100/24, шлюз по умолчанию - 192.168.1.1

контейнер:

eth0: 10.0.0.100/24

тогда для того, чтобы шлюз или любая другая машина из сети 192.168.1.0/24 видела контейнер, ей нужно знать, что маршрут для пакетов в сеть 10.0.0.0/24 идет через 192.168.1.100. Чтобы контейнер знал, куда отправлять ответные пакеты, нужно, чтобы он знал, что хост - это шлюз в 192.168.1.0/24. Единственное, что меня смущает - я не могу сейчас сообразить, нужно ли на контейнере задавать маршрут по умолчанию явно, или это делается за нас OpenVZ.

Или я неправильно понял проблему?

/etc/vz/vz.conf

NEIGHBOUR_DEVS=all

Это?

1. «Как-то немного туманно у вас написано, но сделаю предположение: у вас есть сеть, в ней хост, на хосте виртуалка, виртуалка в другой сети, чем хост. Так?» Нет. Есть сеть A.A.A.0/27, в ней хост с IP из A.A.A.A/27, на хосте виртуалка в той же самой подсети как и хост , хотя линк из виртуалки через venet0:0 point-to-point маска 255.255.255.255 . Этот вариант работает. А мне нужно чтобы работало во так Есть сеть A.A.A.0/27, в ней хост без IP из A.A.A.A/27, на хосте виртуалка с IP сети A.A.A.0/27, хотя линк из виртуалки через venet0:0 point-to-point. Этот вариант не работает и непонятно почему. Вот это проблема! т.е. зачем тратить IP адрес на хостовую часть если в хостовой части нет необходимости в этом (в моей ситуации публичном) IP адресе.

2. «echo 1 >/proc/sys/net/ipv4/ip_forward» - это все сделано, потому что в случае наличия на HN IP адреса все работает. venet это типа технология проброса/коммутации пакетов на основе IP информации. Роут не прописывал, т.к. пологал, что HN должен генерить арп ответы, но попробую. А вообще в штатном режиме vzctl start CTID скрипт активации необходимых сетевых параметров поднимает маршрут в HN для IP CT указывая в качестве gw venet0.

в настройках сейчас NEIGHBOUR_DEVS=detect пробовал NEIGHBOUR_DEVS=eth1.801 и другие интерфейсы указать, не работало. Пробовал руками задать результат вычисления списка интерфейсов в скрипте vps-functions, в переменную NETDEVICES жестко ставил что мне нужно. Не работает.

Такой вариант попробую, но после 18.00

2.

поднимает маршрут в HN для IP CT указывая в качестве gw venet0

значит, я угадал

1. Понятно вроде. Виртуалка должа видеть сеть, которая снаружи хоста, притом, что хост этой сети не видит. У меня знакомый так делал, сейчас его в джаббере нет. Увижу - спрошу

Попробовал опцию
NEIGHBOUR_DEVS=all
Запускаю два tcpdump - на машине с XP (10.18.1.21) с которой пингую и на машине с OpenVZ (10.18.1.25) на HN слушаю физический интерфейс.
На машине с XP вижу arp ответы, ICMP запросы уходят, ICMP ответов не вижу.
На машине с OPenVZ вижу арп запрос, ответ на арп запрос, ICMP запросы и ICMP ответы.
в логах пакетов tcpdump с машины с OpenVZ вижу вот что

13:08:40.960819 00:1a:4d:44:99:df > 00:02:b3:49:44:64, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 64177, offset 0, flags [none], proto ICMP (1), length 60) 10.18.1.21 > 10.18.1.25: ICMP echo request, id 768, seq 3072, length 40
0x0000: 4500 003c fab1 0000 8001 29be 0a12 0115 E..<......).....
0x0010: 0a12 0119 0800 3e5c 0300 0c00 6162 6364 ......>\....abcd
0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 efghijklmnopqrst
0x0030: 7576 7761 6263 6465 6667 6869 uvwabcdefghi

13:08:40.960897 00:02:b3:49:44:64 > 02:31:d1:2f:0f:f3, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 43041, offset 0, flags [none], proto ICMP (1), length 60) 10.18.1.25 > 10.18.1.21: ICMP echo reply, id 768, seq 3072, length 40
0x0000: 4500 003c a821 0000 4001 bc4e 0a12 0119 E..<.!..@..N....
0x0010: 0a12 0115 0000 465c 0300 0c00 6162 6364 ......F\....abcd
0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 efghijklmnopqrst
0x0030: 7576 7761 6263 6465 6667 6869 uvwabcdefghi

ICMP запрос приходит с 00:1a:4d:44:99:df (WinXP) на 00:02:b3:49:44:64 (eth0 OpenVZ). Но ответ уходит уже с 00:02:b3:49:44:64 на 02:31:d1:2f:0f:f3
Мак 02:31:d1:2f:0f:f3 принадлежит шлюзу в интернет который указан в настройках HN, но его IP 10.16.1.1.

На шлюзе (10.16.1.1) ICMP ответы от появляются
13:21:32.580095 00:02:b3:49:44:64 > 02:31:d1:2f:0f:f3, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 43044, offset 0, flags [none], proto: ICMP (1), length: 60) 10.18.1.25 > 10.18.1.21: ICMP echo reply, id 768, seq 3840, length 40
0x0000: 4500 003c a824 0000 4001 bc4b 0a12 0119 E..<.$..@..K....
0x0010: 0a12 0115 0000 435c 0300 0f00 6162 6364 ......C\....abcd
0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 efghijklmnopqrst
0x0030: 7576 7761 6263 6465 6667 6869 uvwabcdefghi

добавил вторичный интерфейс на шлюзе, но толку никакого.
eth0:0 Link encap:Ethernet HWaddr 02:31:D1:2F:0F:F3
inet addr:10.18.1.30 Bcast:10.18.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:10 Base address:0x8000
Хотя машина с XP 10.18.1.21 с него пингуется.

добавил на HN
/sbin/ip rule add from 10.18.1.25 table 7
/sbin/ip route add default dev vmbr0 table 7
vmbr0 это виртуальный порт в HN связанный с eth0
пинг заработал.