Не получается настроить политики маршрутизации через ip rule

[EvgenNsk]

Решил закрыть для себя все непонятные моменты с ip route, и столкнулся с проблемой, решение которой не нашел.

Для освоения использования политик маршрутизации была создана виртуальная машина (типа тренажер) на Ubuntu Server 14.04 LTS с тремя сетевыми картами, подключенными в режиме «сетевого моста» на физическую карту хост-машины.

Хост-машина включена в подсеть 192.168.99.0\24, шлюз подсети – 192.168.99.1

Виртуальные сетевые карты имеют статические, вручную забитые адреса:
eth0: 192.168.99.160\255.255.255.0
eth1: 192.168.99.161\255.255.255.0
eth2: 192.168.99.162\255.255.255.0

Код: [Выделить]

cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.99.160
        network 192.168.99.0
        netmask 255.255.255.0
        broadcast 192.168.99.255

auto eth1
iface eth1 inet static
        address 192.168.99.161
        network 192.168.99.0
        netmask 255.255.255.0
        broadcast 192.168.99.255

auto eth2
iface eth2 inet static
        address 192.168.99.162
        network 192.168.99.0
        netmask 255.255.255.0
        broadcast 192.168.99.255
Обратите внимание, что ни один из интерфейсов не создает в таблице маршрутизации маршрут по умолчанию. Это сделано сознательно, т.к. все что надо - будет добавляться вручную:

Код: [Выделить]

ip route show table main
192.168.99.0/24 dev eth2  proto kernel  scope link  src 192.168.99.162
192.168.99.0/24 dev eth0  proto kernel  scope link  src 192.168.99.160
192.168.99.0/24 dev eth1  proto kernel  scope link  src 192.168.99.161
Правила iptables отсутствуют, политика – по умолчанию, ACCEPT на все.

В ходе эксперимента я пытался принудительно направить траффик до любого хоста, доступного через шлюз – пусть будет один из IP-адресов Яндекса (213.180.204.3, свободно пингуется, проверьте сами) – через определенную сетевую карту.

Для этого в файле /etc/iproute2/rt_tables были созданы 2 пользовательские таблицы:

Код: [Выделить]

cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
161     usertable_1
162     usertable_2
Предполагается поиграться с правилами ip route и понаправлять траффик в эти таблицы.
Используем пока что одну из них - проверить, что многочисленные мануалы не врут, и трафик действительно будет роутиться по дополнительным таблицам в соответствии с политиками.

В таблицу usertable_1 добавляем маршрут по умолчанию через шлюз подсети:

Код: [Выделить]

ip route add default via 192.168.99.1 dev eth1 table usertable_1
Проверим, что он действительно добавился:

Код: [Выделить]

ip route list table usertable_1
default via 192.168.99.1 dev eth1
Теперь добавляем политику, принудительно заворачивающую траффик до 213.180.204.3 в пользовательскую таблицу usertable_1, которая обязана выкинуть его через интерфейс eth1:

Код: [Выделить]

ip rule add from 213.180.204.3 table usertable_1
Проверим, действительно ли политика добавилась:

Код: [Выделить]

ip rule show
0:      from all lookup local
32765:  from 213.180.204.3 lookup usertable_1
32766:  from all lookup main
32767:  from all lookup default
Теперь самое интересное – пробуем пинговать 213.180.204.3:

Код: [Выделить]

ping 213.180.204.3
connect: Network is unreachable
Если ради эксперимента добавить основной шлюз 192.168.99.1 в главную таблицу main (на любой из интерфейсов), то все конечно пингуется, только не через ту сетевую карту, через которую мне надо:

К примеру:

Код: [Выделить]

ip route add default via 192.168.99.1 dev eth0

ping 213.180.204.3
PING 213.180.204.3 (213.180.204.3) 56(84) bytes of data.
64 bytes from 213.180.204.3: icmp_seq=1 ttl=52 time=58.8 ms
Просмотр iptstate на шлюзе (который 192.168.99.1) показывает, что icmp-пакеты идут с eth0 (с адреса 192.168.99.160), а должны идти от eth1 (192.168.99.161) согласно политике.

В связи со всем изложенным, возник вопрос:
Почему ядро игнорирует политику отправки траффика в пользовательскую цепочку, стоящую выше по приоритету чем политика отправки в главную системную таблицу main?
Если комментировать детально – что я делаю не так? И что надо сделать так, чтобы собранная схема заработала.

[AnrDaemon]

Вы from и to перепутали.

[EvgenNsk]

Вы from и to перепутали.

Большое Вам спасибо!
Совершенно верно, перепутаны "откуда" и "куда".
Заменил правило на:

Код: [Выделить]

32765:  to 213.180.204.3 lookup usertable_1и пинги пошли.
Мониторинг с помощью iptstate на шлюзе показывает, что пакеты сыпятся ровно с того интерфейса, откуда требуется.
Для эксперимента во вторую пользовательскую табличку добавил еще один IP-адрес, добавил нужное для него правило - пинги идут, и также с требуемого (теперь уже eth2) интерфейса. Эксперимент повторим.

Заметил особенность: если пинг (любой из двух) остановить, и спустя какое-то время запустить, то он подтупливает какое-то время, затем - начинает идти.
При внесении маршрута к этому IP в таблицу main, такого эффекта не наблюдается. Шлюз точно не виноват (с хост-машины пингуется вообще все и без тупняков), сбрасвыать кэш маршрутов командой ip route flush cache пробовал - не помогает.

С чем может быть связано такое затупливание при запуске пинга?

[AnrDaemon]

Запускайте tcpdump и смотрите, "с чем связано".

[EvgenNsk]

Запускайте tcpdump и смотрите, "с чем связано".

На данный момент список правил такой:

Код: [Выделить]

ip rule show
0:      from all lookup local
32764:  from all to 93.158.134.3 lookup usertable_2
32765:  from all to 213.180.204.3 lookup usertable_1
32766:  from all lookup main
32767:  from all lookup default
Если пинговать 93.158.... то пинги идут ровно.
Следующее же за ним правило - и пинги подтупливают.

Посмотрел на шлюзе с помощью iptstate, пинг к 213.180... виден, и самое главное - колонка TTL не меняет свое значение, там все время 0:29 и таймер не отсчитывает назад, т.е. тестовая машина исправно шлет icmp-пакеты через шлюз. Если пинг на тестовой машине остановить, таймер в iptstate на шлюзе тут же начнет отсчет назад и в результате соединение помрет от старости через полминуты.

Т.е. и тестовая машина не виновата, и тем более шлюз не виноват.

Более того, если еще одним правилом завернуть трафик до еще одного IP в usertable_1 то пинги до него также будут подупливать, а если в usertable_2 - то все пингуется нормально. Какая то получается проклятая usertable_1.

Содержимое у обоих таблиц идентичное - шлюз по дефлоту через шлюз данной подсети:

Код: [Выделить]

ip route show table usertable_1
default via 192.168.99.1 dev eth1

ip route show table usertable_2
default via 192.168.99.1 dev eth2
Стойкое ощущение, что тупняки обусловлены положением правила в таблице правил, но такого быть не может. Но отличаются правила пересылки в таблицы только номером приоритета. Всю голову поломал, что бы это могло быть.

[AnrDaemon]

Вам отдельные правила и таблицы вообще не нужны. Вы можете сразу роутить.

[EvgenNsk]

Вам отдельные правила и таблицы вообще не нужны. Вы можете сразу роутить.

Для данной машины - понятное дело. загнать default via 192.168.99.1 в таблицу main и все будет работать.

Я в самом первом сообщении указывал, что это машина-тренажер для отработки умения применять ip route и ip rule.
Скоро начну пробовать применение возможностей iptables, в частности MARK и CONNMARK, для распределения траффика через разные интерфейсы.

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

[AnrDaemon]

Нет, как раз

Код: [Выделить]

ip route to XXX via YY src ZZZБез всяких rule.

[EvgenNsk]

Нет, как раз

Код: [Выделить]

ip route to XXX via YY src ZZZБез всяких rule.

А если к уже созданному я буду прикручивать совместную работу с iptables, и правила будут переделаны в вид типа такого:
ip rule add fwmark 0x1/0x1 lookup usertable_1
ip rule add fwmark 0x2/0x2 lookup usertable_2

Для пересылки пакетов в отдельные таблицы в зависимости от маркировки без отдельных таблиц ведь ничего не получится?

Хочу потренироваться в настройке MultiWAN-машины как в роли сервера (который должен корректно отвечать на запросы с тех интерфейсов, откуда они пришли), также в роли шлюза (который будет корректно раскидывать транзитный траффик по нужным шлюзам в зависимости от ip source из lan-сети), и также - в обоих ролях одновременно.

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

[AnrDaemon]

Так… так-так-так…
Что же вы, батенька, задание на ходу меняете?…
То у вас исходящий трафик, а то, вдруг, входящий…
Это, знаете ли, совсем разные категории настроек.

ip route from ZZZ dev NNN via YYY

[EvgenNsk]

Что же вы, батенька, задание на ходу меняете?…

Задание на ходу и не меняется, я лишь озвучил дальнейшие планы по работе с "учебно-боевой" машиной.
На данный момент мне требуется добиться надежной работы машины в условиях наличия у нее более одного интерфейса к локальной сети при котором трафки однозначно ходит по правилам, заданным с помощью ip rule, которые пересылают его на отдельные (дополнительные) пользовательские таблицы, а те - выкидывают с разных интерфейсов.
Эксперименты в стиле "сервер с 2-мя и более внешними и чтобы корректно обслуживал с обоих линков" и тем более - "шлюз MultiWAN с балансировкой" - это все совсем потом.

Я пока не могу разобраться с тупняками при пинге через таблицу usertable_1. Мне бы пока локальные вопросы закрыть (и главное - четко понять как и почему такое происходит), а двигаться дальше буду потом.
Пользователь добавил сообщение 22 Июня 2016, 10:49:21:Есть! Экспериментально нашел зависимость тупняков с пингами от настроек.

Смотрим сюда:

Код: [Выделить]

cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
160     usertable_0
161     usertable_1
162     usertable_2
Содержимое всех пользовательских таблиц одинаковое, только указаны разные интерфейсы:

Код: [Выделить]

ip route show table usertable_0 && ip route show table usertable_1 && ip route show table usertable_1

default via 192.168.99.1 dev eth0
default via 192.168.99.1 dev eth1
default via 192.168.99.1 dev eth2
Так вот, с помощью ip rule можно раскидывать любые ip по любым таблицам, но тупить пинг не будет только в той, которая в /etc/iproute2/rt_tables указана в самом конце списка. В моем примере - usertable_2

Как объяснить этот эффект - не знаю.

[AnrDaemon]

Берите tcpdump и смотрите, что происходит.
Не бывает "тупить" в вакууме. Раз "тупит", значит пакеты приходят не туда, куда надо.

[EvgenNsk]

Берите tcpdump и смотрите, что происходит.

Судя по наблюдением за состоянием icmp-сессии (через iptstate), пакеты с тестовой машины приходят на шлюз корректно, и ip источника\получателя светятся правильные. А вот на обратном пути (возможно - на участке между шлюзом и тестовой машиной) есть какой-то затык.

Подскажите пожалуйста, с какой стороны (тестовая машина или шлюз) вероятнее всего обнаружить проблему, и с какими аргументами-значениями запускать tcpdump?

[AnrDaemon]

Смотреть надо на самой машине.
Запускать tcpdump на все интерфейсы с одним фильтром 'proto icmp' (раз icmp ловите).
Пользователь добавил сообщение 23 Июня 2016, 04:42:48:И ещё один момент.
В зависимости от типа виртуализации, могут работать дополнительные ограничения на работу сети в ВМ.

[EvgenNsk]

В зависимости от типа виртуализации, могут работать дополнительные ограничения на работу сети в ВМ.

Используется Oracle VirtualBOX версии 5, все три виртуальные сетевки завернуты "сетевым мостом" на физическую сетевку хост-машины.

А вообще, Вы дали мне идею: повторить эксперимент на реальной физической машине (из старого ПК), куда в дополнение к интегрированной в матплату сетевке, добавить еще парочку в PCI-слоты.