Ну где

route -n

ip route с одного сервера (второй такой же, отличие только в номерах хостов)

5.yy.yy.189 dev venet0 scope link 5.yy.yy.175 dev venet0 scope link 85.xx.xx.54 dev venet0 scope link 85.xx.xx.55 dev venet0 scope link

85.xx.xx.48/28 dev eth0 table comfortel scope link src 85.xx.xx.52 85.xx.xx.16/28 dev eth0 table comfortel scope link src 85.xx.xx.22 default via 85.xx.xx.17 dev eth0 table 120

5.yy.yy.160/27 dev eth1 table avantel scope link src 5.yy.yy.163 default via 5.yy.yy.161 dev eth1 table 130

85.xx.xx.48/28 dev eth0 proto kernel scope link src 85.xx.xx.52 85.xx.xx.16/28 dev eth0 proto kernel scope link src 85.xx.xx.22 5.yy.yy.160/27 dev eth1 proto kernel scope link src 5.yy.yy.163 default via 85.xx.xx.17 dev eth0

Ну где Lorcode?

а про правила маршутизации мы сами должны догадываться ?

Если есть несколько таблиц маршрутизации, то должны быть и правила по которым они выбираются.

«ip ru» что говорит ?

Раз много линков, то проблему наверно лучше решать немного иначе.

1) В таблице main нужно оставить только прямые маршруты (те, что создает система после подъема устройства) общими статическими маршрутами ( если такие есть )

2) создать 2 таблицы только с маршрутами по-умолчанию

3) таблица правил должна быть вида

0:      from all lookup local
100:    from all lookup main
# дальше правила определяющие таблицы маршрутизации для конкретных адресов интерфейсов
110:    from 5.yy.yy.189 lookup 120
120:    from 5.yy.yy.175 lookup 120
....
#и в конце добавить правило выбора аплинка по-умолчанию
200:    from all lookup 120

Чтобы работал доступ к соседним машинам нужно после просмотра таблицы local обязательно просмотреть таблицу с прямыми маршрутами и только потом начинать смотреть на адрес источника пакета.

Очень странные маршруты

5.yy.yy.189 dev venet0 scope link
5.yy.yy.175 dev venet0 scope link
85.xx.xx.54 dev venet0 scope link
85.xx.xx.55 dev venet0 scope link 

venet0 - это P-t-P или классический интерфейс ?

Спасибо, вы мне очень помогли.

Сделал вместо 2 таблиц - 3 (в каждой свой диапазон и шлюз), переписал правила.

Теперь выглядит так:

0:      from all lookup local
1:      from all lookup main
32748:  from 5.yy.yy.160/27 lookup 120
32749:  from 85.xx.xx.18/28 lookup 130
32750:  from 85.xx.xx.48/28 lookup 140
32766:  from all lookup 130
32767:  from all lookup default

table main:

5.yy.yy.189 dev venet0  scope link
5.yy.yy.175 dev venet0  scope link 
85.xx.xx.54 dev venet0  scope link 
85.xx.xx.55 dev venet0  scope link 
85.xx.xx.48/28 dev eth0  proto kernel  scope link  src 85.xx.xx.52 
85.xx.xx.16/28 dev eth0  proto kernel  scope link  src 85.xx.xx.22 
5.yy.yy.160/27 dev eth1  proto kernel  scope link  src 5.yy.yy.163 
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
169.254.0.0/16 dev eth2  scope link  metric 1004

120:

5.yy.yy.160/27 dev eth1  scope link  src 5.yy.yy.163
default via 5.yy.yy.161 dev eth1

130:

85.xx.xx.16/28 dev eth0  scope link  src 85.xx.xx.22 
default via 85.xx.xx.17 dev eth0 

140:

85.xx.xx.48/28 dev eth0  scope link  src 85.xx.xx.52 
default via 85.xx.xx.49 dev eth0 

Теперь оба хоста видят все контейнеры (и свои, и чужие).

Но контейнеры разных хостов с адресами из разных диапазонов друг друга по-прежнему не видят.

venet0 - это интерфейс виртуальной сети OpenVZ. По сути, P-t-P, да.

Дублировать прямые маршруты в доп. таблицы не нужно - оно и так есть в main.

Но контейнеры разных хостов с адресами из разных диапазонов друг друга по-прежнему не видят.

Не совсем понял с какого адреса какой недоступен.

«ip ro get XXX» и tracepath - в помощь. Смотреть нужно с двух сторон: возможно туда пакет приходит, а обратно отправляется не тем путем.

iptables ничего не режет?

А что через этот venet0 ходит ? «tcpdump -npi venet0» ?

Судя по https://openvz.org/Virtual_network_device этот venet поделка для экзотических случаев.

Сейчас все выглядит так:

Контейнер1 (5.yy.yy.171) - Хост1 (5.yy.yy.162, 85.xx.xx.51)- Свитч - Хост2 (5.yy.yy.163, 85.xx.xx.52) - Контейнер2 (85.xx.xx.54)

С Хост1 доступны и Контейнер1, и Контейнер2.

А вот с Контейнер1 до Контейнер2 и обратно не достучаться, если они из разных диапазонов.

iptables безусловно разрешает icmp.

В venet0 на Хост2 пакетов от Контейнер1 не видно. При этом входящем интерфейсе Хост2 - пакеты есть.

venet - штатный интерфейс для openvz контейнеров, и оно нормально работает. Но... В общем, плохо все.

5.yy.yy.189 dev venet0  scope link
5.yy.yy.175 dev venet0  scope link 
85.xx.xx.54 dev venet0  scope link 
85.xx.xx.55 dev venet0  scope link

для серверов IMHO здесь неправильно.

Отладка такой хрени дело не быстрое и требует внимательности.

В venet0 на Хост2 пакетов от Контейнер1 не видно. При этом входящем интерфейсе Хост2 - пакеты есть.

Значит на Хост2 нужно сказать «ip ro get 85.xx.xx.54 from 5.yy.yy.171 iif eth0» или «ip ro get 85.xx.xx.54 from 5.yy.yy.171 iif eth1» и понять что не так.

Если все совсем непонятно, то добавляем на Хост2 «iptables -t raw -A PREROUTING -p icmp -s 5.yy.yy.171 -d 85.xx.xx.54 -j TRACE» и смотрим куда оно уходит.

Хотелось бы увидеть таблицы маршрутизации и правил обоих хостов.

для серверов IMHO здесь неправильно.

Так создается автоматически при запуске vz контейнера.

# ip ro get 85.xx.xx.54 from 5.yy.yy.171 iif eth1
85.xx.xx.54 from 5.yy.yy.171 dev venet0  src 5.yy.yy.163 
    cache <src-direct>  mtu 1500 advmss 1460 hoplimit 64 iif eth1
# ip ro get 85.xx.xx.54 from 5.yy.yy.171 iif eth0
RTNETLINK answers: Invalid argument

Кажется, я начинаю что-то понимать.

Пакет приходит через eth0, а должен - т.к. с адреса 5.yy.yy - приходить через eth1...

Маршрутизация и правила одинаковы на обоих хостах (отличаются только адреса), я их выше приводил.

Удалил из таблицы main роуты на диапазоны 5.yy.yy.160/27 и прочие.

Пакеты пошли через default route (провайдерские шлюзы) и контейнеры стали доступны.

Это меня все еще не устраивает (хочу гонять их через прямой линк), но за идею спасибо.

Теперь вот вопрос - как заставить хосты роутить пакеты напрямую...

ip ro add 85.xx.xx.48/28 dev eth1 src 5.yy.yy.162 table 120 via 85.xx.xx.52 выдает RTNETLINK answers: No such process

Я достаточно давно смотрел на OpenVZ c точки зрения реализации сети и она мне не понравилась. На данный момент нормальная реализация сети только в lxc.

Пакет приходит через eth0, а должен - т.к. с адреса 5.yy.yy - приходить через eth1...

При ассиметричной маршрутизации нужно не забывать по net.ipv4.conf.{default,all}.{rp_filter,arp_filter,arp_ignore,arp_announce}

Они по-умолчанию 0 и это не всегда правильно. «rp_filter=2» для конкретного интерфейса или для всех, обычно помогало в таких ситуациях.

arping помогает выявить неправильные ответы (двойные ответы) и чтоб их исправить нужно подкрутить rp_filter, arp_ignore, arp_announce. У меня они на таких конфигурациях 1,2,1.

Удалил из таблицы main роуты на диапазоны 5.yy.yy.160/27 и прочие.

А зря, это прямой маршрут и его нужно просматривать сразу после локальных!

Теперь вот вопрос - как заставить хосты роутить пакеты напрямую...

ip ro add 85.xx.xx.48/28 dev eth1 src 5.yy.yy.162 table 120 via 85.xx.xx.52 выдает RTNETLINK answers: No such process

Бррр! В прямом маршруте «via» не нужен.

Верни назад в main прямые маршруты (адреса сетей непосредственно подключенных к машине). Убрав их, ты создал больше проблем, чем решил.

Правила маршрутизации могут использовать не только адрес источника в качестве селектора, но и имя входного интерфейса пакета и адрес назначения!

Спасибо за помощь, я разобрался и настроил.

Все оказалось довольно просто - из-за сорс-роутинга нужен был ассиметричный роутинг, а у меня rp_filter был выставлен в 1. И, да, роуты в main я вернул - они не мешают. А в чем из-за их отсутствия могут быть проблемы?

Если по правилам пакет уходит в табличку с одним default-route, а обращение идет к соседнему хосту, то пакет уходит не туда. А мы расчитываем, что к соседним компам всегда обращение идет напрямую...

Можно конечно дублировать прямые маршруты во все доп. таблицы, но это неудобно и трудно автоматизировать. А в main их ядро пихает само.