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

Вопрос по ip route

 ,


0

1

Возникло несколько вопросов по данной команде.

Есть два провайдера:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface

allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 192.168.0.1
        netmask 255.255.255.0

allow-hotplug eth1
auto eth1
iface eth1 inet dhcp
#       metric 1
        hwaddress ether 00:1D:92:0F:9B:A5
#       address 10.0.4.104
#       netmask 255.255.0.0
#       gateway 10.0.3.1

allow-hotplug eth2
auto eth2
iface eth2 inet static
#       metric 10
        address 192.168.1.33
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1

Есть правила для роутинга:

#!/bin/sh

IF0=eth0
P0_NET=192.168.0.0/24

IF1=eth1
P1_NET=10.0.0.0/16
P1=10.0.3.1
IP1=10.0.4.104

IF2=eth2
P2_NET=192.168.1.0/24
P2=192.168.1.1
IP2=192.168.1.33

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

ip route add $P0_NET dev $IF0 table T1
ip route add $P1_NET dev $IF1 table T1
ip route add 127.0.0.0/8 dev lo table T1
ip route add $P0_NET dev $IF0 table T2
ip route add $P2_NET dev $IF2 table T2
ip route add 127.0.0.0/8 dev lo table T2

#ip route add default via $P1
ip route replace default scope global nexthop via $P1 dev $IF1 weight 10 nexthop via $P2 dev $IF2 weight 1
Данный скрипт лежит в /etc/network/if-up.d (кстати, нормально ли так делать?). И все, кроме replace не применяется. Насколько я понимаю, т.к. таблица маршрутизации уже создана. Как же её тогда правильно очистить? Команда ip route flush all в самом начале скрипта отрубает сеть.



Последнее исправление: cetjs2 (всего исправлений: 2)

Скрипты из /etc/network/if-up.d вызываются для каждого интерфейса, т.о. в твоём случае скрипт будет вызван три раза, что явно не желательно.

Нужно либо в скрипте по переменной $IFACE выяснять интерфейс, для которого он вызван, либо, что разумнее, вместо скрипта занести подъём маршрутов прямо в /etc/network/interfaces. Например:

allow-hotplug eth2
auto eth2
iface eth2 inet static
        address 192.168.1.33
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1
        post-up ip route add 192.168.1/24 dev $IFACE src 192.168.1.33 table T2
        post-up ip route add default via 192.168.1.1 table T2
        post-up ip route add 192.168.1/24 dev $IFACE src 192.168.1.33
        post-up ip rule add from 192.168.1.33 table T2
        post-up ip route add 192.168.1/24 dev $IFACE table T2

p.s. Сами маршруты из твоей конфигурации мне не ясны. Если это попытка сделать хост доступным по двум IP, чтобы он отвечал с того же интерфейса откуда пришёл пакет, то тут много лишнего. Лучше напиши словами, чего хотел сделать и зачем для этого две дополнительные таблицы маршрутизации?

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

+1

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

Это можно реализовать двумя путями:

1) как у автора треда - попытка продублировать все прямые маршруты во все таблицы, а потом через ip ru выбрать нужную таблицу. Пока интерфейсов всего 2 и нет кучи доп. маршрутов, это не сложно.

2) все дополнительные маршруты ( включая dgw ) вносить в отдельную таблицу(ы).

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

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

Не у всех пакетов есть адрес источника. Чтобы его определить используется таблица маршрутизации. т.ч. правило 40 как раз для этого.

0:      from all lookup local
10:     from all lookup main
20:     from X.X.X.X lookup table 1
30:     from Y.Y.Y.Y lookup table 2
40:     from all lookup table 1
32766:  from all lookup main
32767:  from all lookup default

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

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

20: from X.X.X.X lookup table 1
30: from Y.Y.Y.Y lookup table 2

Для меня загадка, зачем нужна специальная маршрутизация именно для пакетов, пришедших от шлюзов смежных сетей. Ведь пакеты, пришедшие из-за этих шлюзов, для которых как раз, как мне кажется, отдельная маршрутизация имеет смысл, не будут иметь в src ip адрес шлюза и не подпадут под это правило. Логичнее было бы использовать iif вместо from.

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

from X.X.X.X - нужно для локально сгененрированных пакетов. На роутере таких пакетов мало, но они есть и именно из за них приходится городить правило 40.

А для транзитных это может быть как from X/N так и iif, fwmark, to, tos.

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

Всё верно. Я попутал значения $IP2 и $P2 в скрипте автора треда. Почему-то решил, что $IP2 это адрес шлюза по умолчаню 2-го провайдера.

unterwulf
()

т.к. таблица маршрутизации уже создана.

Создана? Да она всегда есть. И ″ip route add″ не работает только если маршут на такой адрес уже есть.

Но таблицы T1 и T2 на момент запуска скрипта должны быть пустыми, поэтому весь ″add″ для них должен работать. Может вы просто не определили численные значения для T1 и T2? Команда ″ip route show table T1″ работает?

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

В данном случае это продолжение темы 2 интернет канала. Объединение каналов или скрипты? .

Таким способом я хотел сделать «резервирование» интернет-канала. Плюс, чтобы шлюз был доступен из интернета по любому интерфейсу. До данного скрипта интернет раздавался, но зайти на шлюз через интернет не было возможности.

Попробую прописать правила вашим способом.

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

Просто сообщения при перезапуске сети вида:

RTNETLINK answers: File exists
немного настораживают.

И еще, разве в выводе команды ip route не должны указываться напротив интерфейсов таблицы? У меня выводиться только так:

default
        nexthop via 10.0.3.1  dev eth1 weight 10
        nexthop via 192.168.1.1  dev eth2 weight 1
10.0.0.0/16 dev eth1  proto kernel  scope link  src 10.0.4.104
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
192.168.1.0/24 dev eth2  proto kernel  scope link  src 192.168.1.33
Вот вывод других команд:
ip route show table T1
default via 10.0.3.1 dev eth1
10.0.0.0/16 dev eth1  scope link  src 10.0.4.104
127.0.0.0/8 dev lo  scope link
192.168.0.0/24 dev eth0  scope link
ip route show table T2
default via 192.168.1.1 dev eth2
127.0.0.0/8 dev lo  scope link
192.168.0.0/24 dev eth0  scope link
192.168.1.0/24 dev eth2  scope link  src 192.168.1.33

Т.е. скрипт выполнился и маршруты занесены в таблицу?

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

При первом выполнении скрипт скорее всего ругается на команду:

ip route add $P2_NET dev $IF2 src $IP2

так как если на интерфейс назначен адрес с маской (подсетью), то и маршрут в эту сеть появится при поднятии интерфейса.

На перезапуск сети, точнее на повторное выполнение, ваш скрипт не расчитан, ″ip rule″ при каждом выполнении будет добавлять правила к уже существующим, ″ip route add″ ругаться на уже существующие маршруты. И, так как, скрипт будет вызван для каждого интерфейса, ругательств будет много.

Но, как бы терпимо, маршруты у вас добавляются, содержимое таблиц нормальное. Разве что, 127.0.0.0/8 в таблицах T1 и T2 лишее, этот маршрут и так есть в таблице local.

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

Значит лучше всего просто переписать все правила для каждого интерфейса индивидуально в interfaces как было предложено выше? Таблицу очищать не надо?

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

Таблицу лучше не очищать, сейчас у вас всё просто, а потом, допустим, появится dhcp-клиент или ещё что и скрипт, очищающий таблицу маршрутизации, окажется неприятной неожиданностью. Вместо ″ip route add″ используйте во всём скрипте ″ip route replace″ и ругательств не будет.

Прописывать такие простые команды в interfaces вполне разумно, тогда вся конфигурация в одном файле. Я бы на время первоначальной настройки так и сделал бы, а потом, возможно, прописал туда вызов скрипта.

Но скрипта сложного, чтобы он сам (с помощью ″ip addr show″, ″ip route show″) определял адреса интерфейсов и добавлял в T1 и T2 недостающие маршруты к локальным сетям. То есть чтобы в скрипте не задавались P2_NET, P2 и т.д., так как на мой взгляд не правильно дублировать информацию в разных файлах, изменяя /etc/network/interfaces можно забыть изменить P2_NET.

mky ★★★★★
()
11 декабря 2013 г.
Ответ на: комментарий от vel

table cache

А в какой момет выбора маршрута iproute2 просматривает table cache?

??: from all lookup cache

При наличии 2-х внешних интерфейсов какие правила/роуты Вы используете чтобы Ваш роутер случайно не стал мостом между двумя подсетями на которые смотрят wan1 и wan2? Или это лучше решать средствами iptables?

anonymous
()

Не использовать стандартные скрипты, всё кинуть наглядно в один самописный.

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