Скрипты из /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, чтобы он отвечал с того же интерфейса откуда пришёл пакет, то тут много лишнего. Лучше напиши словами, чего хотел сделать и зачем для этого две дополнительные таблицы маршрутизации?

+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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

ip route add $P2_NET dev $IF2 src $IP2

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

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

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

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

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

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

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

table cache

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

??: from all lookup cache

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

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