LINUX.ORG.RU
решено ФорумAdmin

Маршрутизация трафика (iproute)

 


0

1

Пытаюсь маршрутизировать трафик с локального интерфейса (eth0/172.17.169.40) через дополнительную таблицу:

$ cat /etc/iproute2/rt_tables

400 custom
$ ip rule list

0:	from all lookup local 
32763:	from 192.168.0.0/16 lookup custom 
32764:	from 172.16.0.0/12 lookup custom 
32765:	from 10.0.0.0/8 lookup custom 
32766:	from all lookup main 
32767:	from all lookup default 

$ ip route show table custom

default via 172.17.169.254 dev eth0 
$ ip route show table main

default via 172.17.169.254 dev eth0  proto static  metric 100 
172.17.169.0/24 dev eth0  proto kernel  scope link  src 172.17.169.40  metric 100 
192.168.17.194 via 172.17.169.200 dev eth0 
$ ip route show table local

broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 172.17.169.0 dev eth0  proto kernel  scope link  src 172.17.169.40 
local 172.17.169.40 dev eth0  proto kernel  scope host  src 172.17.169.40 
broadcast 172.17.169.255 dev eth0  proto kernel  scope link  src 172.17.169.40 

Теперь с консоли сервера пытаюсь получить доступ к 192.168.17.194, но трафик идет через 172.17.169.200

$ ip route get 192.168.17.194
192.168.17.194 via 172.17.169.200 dev eth0  src 172.17.169.40 
    cache 

Но

$ ip route get 192.168.17.194 from 172.17.169.40
192.168.17.194 from 172.17.169.40 via 172.17.169.254 dev eth0 
    cache 

Для уверенности добавляю еще правила:

$ ip rule list

0:	from all lookup local 
32760:	from all to 171.17.169.40 lookup custom 
32761:	from all oif eth0 lookup custom 
32762:	from 172.17.169.40 lookup custom 
32763:	from 192.168.0.0/16 lookup custom 
32764:	from 172.16.0.0/12 lookup custom 
32765:	from 10.0.0.0/8 lookup custom 
32766:	from all lookup main 
32767:	from all lookup default 

Результат тот же.

В чем ошибка?


Ответ на: комментарий от outsider

Я хочу, чтобы трафик с локального интерфейса 172.17.169.40 в сторону 192.168.17.194 маршрутизировался через таблицу custom. Необходимо, например, для того, чтобы в случае ошибок в таблице main не потерять управление устройством.

В нашем случае маршрут в main «ошибочный»: «192.168.17.194 via 172.17.169.200 dev eth0»

alexg
() автор топика
Ответ на: комментарий от alexg
ip route get 192.168.17.194

Вот эта поманда правила маршрутизации типа:

32763:	from 192.168.0.0/16 lookup custom 
32764:	from 172.16.0.0/12 lookup custom 
32765:	from 10.0.0.0/8 lookup custom 
ВООБЩЕ не смотрит, так как на этом этапе не известен исходящий адресс, поэтому берется default таблица находится ближайший маршрут до 192.168.17.194, и от туда берется from - и насколько я понимаю дальше маршрутизация не производится.

zaz ★★★★
()
Ответ на: комментарий от zaz

Получается, что правила работают до принятия решения о маршрутизации, но интерфейс (и его IP) локального пакета определяется после маршрутизации. Получается, что завернуть трафик в таблицу custom по адресу исходящего интерфейса вообще никак не получится? Только по адресу назначения?

Допустим так: from all to 192.168.17.194 lookup custom

alexg
() автор топика
Ответ на: комментарий от alexg

Только по адресу назначения?

Нет, основное отличие ip route2 от ip route1 было какраз в том что во второй версии появилась возможность маршрутизации не только по адресу назначения, но и по адресу отправителя (source base routing).

Проблема в том что ви тестируете маршрутизацию немного не корректно, а именно запрашиваете маршрут указав только TO без указания FROM. Соотвецтвенно в этом случае src маршрутизация не возможна (src нету), и запускается отдельная процедура маршрутизации которая должна не только выбрать маршрут но еще и подобрать подходящий (локальный) source адресс.

Для вашего случая (бекапный маршрут) все можно сделать гараздо проще, заводите на интерфейсе 2 IP адресса, первый маршрутезируете по дефолтной таблице - второй по алтернативной. Теперь если вы хотите подключится к серверу по дефолтной таблице - подключаетесь к основному IP, если по алтернативной - ко второму IP и все.

zaz ★★★★
()
Последнее исправление: zaz (всего исправлений: 1)
Ответ на: комментарий от anonymous

если кратко, то в каждой недефолтной таблице, должен быть маршрут с сурс адресом до дефолт или статик роута, который вам нужен.

не может быть просто дефорт и все. должен быть маршрут, КАК попасть до этого дефолта.

anonymous
()
Ответ на: комментарий от zaz

А как корректно протестировать?

$ ip route get 192.168.17.194 from 172.17.169.40
192.168.17.194 from 172.17.169.40 via 172.17.169.254 dev eth0 
    cache 
Покажет мне правильный маршрут

Но, например, ping с консоли сервера до хоста 192.168.17.194 не доходит, по причине того, что пакет уходит на 172.17.169.200.

Даже, если а добавлю второй IP на интерфейс, то как мне завернуть трафик с него в альтернативную таблицу?

На данном этапе я не понимаю на каких этапах отрабатывают правила маршрутизации и определяется src адрес/интерфейс, с которого уйдет пакет?

alexg
() автор топика
Ответ на: комментарий от alexg

В случае с ping у него есть специальный параметр для таких случаев -I где вы можете явно указать с какого IP следует отправлять пакеты. Аналогично в других программах вы можете указывать явно локальный IP (например -b в telnet). Source based маршрутизация как правило используется для FORWARD траффика (когда адресс src и dst адресса зарание известны), либо управлением входящих соединений (тогда src адрес выбирает не сервер а клиент при инициализации сессии).

Если же вы хотите просто подключатся с сервера к 192.168.17.194 по отдельному маршруту, вам не нужен source based routing, и алтернативные таблици вам тоже не нужны, это стандартный случай destination routing ...

Такчто для начала вам нужно пересмотреть и упорядочить в голове свои запросы, и определится что вы хотите получить в результате

zaz ★★★★
()
Ответ на: комментарий от zaz

Source based маршрутизация как правило используется для FORWARD траффика (когда адресс src и dst адресса зарание известны), либо управлением входящих соединений

Ну, зачем так категорично то. Во-первых, для маршутизации по источнику только источник и важен. Примеров использования можно сделать множество. Скажем, у меня proxy для http/ftp работает с другим каналом, а всё остальное - с маршрутом по умолчанию первого провайдера.

vodz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.