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

Роутинг...


0

0

Наверное меня сейчас закидают помидорами, т.к. тема уже здесь вроде как подымалась, но все равно прошу помощи...

Есть сервер, подключенный по двум каналам(eth1, eth2) к двум разным провайдерам. Настроены две таблицы маршрутизации, транзитный трафик маркируется и отправляется по нужному каналу, никаких коллизий с неправильным NAT, все красиво и отлаженно работает.

В таблице маршрутизации main на сервере в качестве default gw указан первый провайдер. Встал вопрос, как сделать так, чтобы весь трафик ЛОКАЛЬНОГО пользователя на сервере(pinkbyte@server) отправлялся по ДРУГОМУ default gw(точнее по другой таблице маршрутизации)? Пробовал маркировать трафик в mangle/OUTPUT - ничего не вышло, все равно идет через 1 маршрут. Покурив Iptables HOWTO понял, что таким образов ничего и не получиться, ибо для исходящих(не транзитных) пакетов СНАЧАЛА определяется маршрут, а уже ПОТОМ они отправляются в iptables.

Гугление дало мне пищу для ума в виде patch-o-matic-ng для iptables, конкретно: «ROUTE target», с помощью которого можно изменить решение о маршрутизации непосредственно в iptables(кто-то считает что это не тру, но других альтернатив я не нашел).

Собственно казалось бы - в чем вопрос? patch-o-matic-ng я скачал и патч ROUTE даже наложился без ошибок... вроде бы... пока я не начал собирать ядро. вот тут то меня и ждал облом в виде «структура sk_buff не содержит в себе элемента dst»(точный текст сейчас привести не могу).

Собственно вопрос: как этим patch-o-matic пользоваться и нет ли альтернативных решений проблемы? Каким нибудь образом «превратить» исходящий трафик в транзитный?(чувствую ересь в этой фразе, но все же...)

P.S. Дистрибутив - Gentoo. Ядра пробовал разные - от 2.6.29-vanilla до 2.6.31-zen включительно(естественно родные гентушные тоже не обошел стороной). Ошибка везде одна и та же...

★★★★★

Блин, все оказалось проще - перечитал тему, которую тут подымали давно(SNAT & Routing) и понял, где ступил.

Было:

titan ~ # ip rule
0:      from all lookup local
32762:  from 192.168.1.7 lookup unlim
32763:  from 192.168.0.7 lookup traffic
32764:  from all fwmark 0x2 lookup unlim
32765:  from all fwmark 0x1 lookup traffic
32766:  from all lookup main
32767:  from all lookup default

Стало:

titan ~ # ip rule
0:      from all lookup local
10:     from all fwmark 0x1 lookup traffic
20:     from all fwmark 0x2 lookup unlim
30:     from 192.168.0.7 lookup traffic
40:     from 192.168.1.7 lookup unlim
32766:  from all lookup main
32767:  from all lookup default

После этих изменений трафик из цепочки mangle/OUTPUT стал не просто маркироваться, но и идти по правильному маршруту. Вопрос решен...

Pinkbyte ★★★★★ ()

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

anton_jugatsu ★★★★ ()

ROUTE отказываются брать в мейнстрим, да и автор на него уже забил, так что с новыми версиями ведра и не должно работать.

А правильный путь решения этой задачи как раз и состоит в маршрутизации на основе меток.

Покурив Iptables HOWTO понял, что таким образов ничего и не получиться, ибо для исходящих(не транзитных) пакетов СНАЧАЛА определяется маршрут, а уже ПОТОМ они отправляются в iptables.


А после цепочки nat/OUTPUT маршрут определяется заново :)

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

>только вот беда - исходящий адрес не меняется

Выбор исходящего адреса в линуксе — это капец. Емнип, он производится в строгом соответствии с таблицей main, с укладыванием большого прибора на policy-based routing.
К счастью, маскарадинг никто не отменял :)

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

> А после цепочки nat/OUTPUT маршрут определяется заново :)

Это если правильно rules расставлены, у меня же они были расставлены СНАЧАЛА по дефолтно присваемому ip-адресу(решается на основе default route по таблице main), а ПОТОМ - по маркировке пакетов. Как выяснилось надо было это делать абсолютно наоборот. Отсюда и вытекает то, что ROUTE для моей задачи мне нафиг оказался ненужным - нужно было лишь вдумчивее читать маны

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

> только вот беда - исходящий адрес не меняется

Правильно настроенный SNAT в nat/POSTROUTING спас отца русской демократии от этой проблемы.

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