iproute2 и проброс портов (Проблмма с пробросом портов в случае с двумя провайдерами.)

[AnViar]

Собственно столкнулся со своим недопониманием работы iproute2.
Исходные данные:
Есть шлюз в интернет с тремя алиасами на интерфейсе - алиасы от разных провайдеров.
На шлюзе настроено iproute2 по мануалу с opennet.ru.
На шлюзе оуществлен проброс портов средствами iptables в DMZ (DNAT).
Было замечено, что при прохождении пакета в DMZ ответ идет все равно по default gw.

Я подозреваю, что iproute2 в принципе не может разрулить эту ситуацию,необходимой информации (какой именно??? - не нашел четкой документации по этому вопросу) после DNAT в пакете уже не содержится.

Буду весьма признателен за развернутое обьяснение этого механизма.

[stannum]

Закончите фразу:
- А если подробнее надо чтобы ....

[AnViar]

Закончите фразу:
- А если подробнее надо чтобы ....

1) Надо чтобы входящие запросы от одного провайдера и днатящиеся на сервис в DMZ уходили по тому же маршруту.
2) Еще интересно по каким критериям выбирается маршрут в iproute2 (хочу разобраться, чтобы не возникало впредь таких ситуаций)

[user]

2) Еще интересно по каким критериям выбирается маршрут в iproute2 (хочу разобраться, чтобы не возникало впредь таких ситуаций)

оно?

[stannum]

Я не уверен, задача для меня не тривиальная, но я бы попробовал реализовать это посредством маркировки пакетов, при помощи модуля CONNMARK в iptables, на самом шлюзе.
Добавлено: и соответственно SNATить потом в зависимости от марки.

[sash-kan]

а вообще ситуация попахивает чистой воды динамической маршрутизацией. со всеми вытекающими…

[AnViar]

У меня маскарад на выходе в интернет
также
# ip rule show
0: from all lookup local
32763: from (ip1 на интерфейсе) lookup SKY
32764: from (ip2 на интерфейсе) lookup CTS
32765: from (ip3 на интерфейсе) lookup UTK
32766: from all lookup main
32767: from all lookup default

по дефолту идет через CTS

замечено, что если сменить default gw, то конект пропадает из подсети CTS, но с других провайдеров заходит.
можете что сказать или следует детально изучить ситуацию через tcpdump? (просто сервисы кретичные и длительный просто не жлателен)

и еще:
ip route show table default
показывает пустоту. так должно быть? это что за таблица?

[Sandle_X]

разбей сети по таблицам, и для каждой таблицы назначь свой default маршрут

[AnViar]

разбей сети по таблицам, и для каждой таблицы назначь свой default маршрут

[root@gw root]# ip route show table UTK
default via 83.221.197.177 dev eth0
[root@gw root]# ip route show table CTS
default via 213.27.9.65 dev eth0

это сделано было. вот поступила информация от прова CTS - они говорят, что при моем переключении на UTK ответы на запросы из их сети идут все равно по моей цепочке main...
Повторю изначальный вопрос: DNAT не ломает этот механизм? Не должен ли я назначить таблицы для пакетов, возвращающихся из DMZ и перед этим DNAT-ить на разные ip в зависимости от источника?

[Olden Gremlin]

а вообще ситуация попахивает чистой воды динамической маршрутизацией. со всеми вытекающими…

Саша, нет тут даже близко динамической маршрутизации... Даже не пахнет... Так-что и вытекать-то нечему...

Вопрос в том в какой канал направить исходящий от внутреннего клиента ответ.
Имхо, задача вполне решаемая. Думать просто лениво... Но...

Совсем бредовая идея, а если делать DNAT с одного провайдера на 192.168.0.1, а с другого на 192.168.1.1. Где 192.168.0.1 и 192.168.1.1 это два адреса на одном и том-же интерфейсе?... Мысль ясна? К сожалению проверить идею нет ни сил, ни времени, ни возможности, ни желанья...

[AnViar]

а вообще ситуация попахивает чистой воды динамической маршрутизацией. со всеми вытекающими…

Саша, нет тут даже близко динамической маршрутизации... Даже не пахнет... Так-что и вытекать-то нечему...

Вопрос в том в какой канал направить исходящий от внутреннего клиента ответ.
Имхо, задача вполне решаемая. Думать просто лениво... Но...

Совсем бредовая идея, а если делать DNAT с одного провайдера на 192.168.0.1, а с другого на 192.168.1.1. Где 192.168.0.1 и 192.168.1.1 это два адреса на одном и том-же интерфейсе?... Мысль ясна? К сожалению проверить идею нет ни сил, ни времени, ни возможности, ни желанья...

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

[Olden Gremlin]

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

... неверно думал... в принципе наверняка можно еще как-то подумать над описанной проблемой... но...
о! еще одна мысль... например, если мы dnat'им 25-й порт, то...
от первого провайдера dnat на внутренний 2025 порт, от второго на 2125. соответственно эти два порта слушать, ну и отвечать на запросы...
как мысль?

[AnViar]

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

... неверно думал... в принципе наверняка можно еще как-то подумать над описанной проблемой... но...
о! еще одна мысль... например, если мы dnat'им 25-й порт, то...
от первого провайдера dnat на внутренний 2025 порт, от второго на 2125. соответственно эти два порта слушать, ну и отвечать на запросы...
как мысль?

те же яйца - вид сбоку...
так по каким же тогда критериям выбирается маршрут в iproute2, если я был не прав?

[Olden Gremlin]

так по каким же тогда критериям выбирается маршрут в iproute2, если я был не прав?

критерии по роутингу более чем просты:

Код: Выделить всё

ip rule
ip route

критерии по трафику...

Код: Выделить всё

tc qdisc
tc class
tc filter
tc action

и не требуйте с iproute больше чем он может сделать...

[AnViar]

так по каким же тогда критериям выбирается маршрут в iproute2, если я был не прав?

критерии по роутингу более чем просты:

Код: Выделить всё

ip rule
ip route

критерии по трафику...

Код: Выделить всё

tc qdisc
tc class
tc filter
tc action

и не требуйте с iproute больше чем он может сделать...

т.е. он может по полю from маршрутизировать по орпеделенной таблице и все?
про шейпинг я имею представление - хочу имеено маршрутизацию допонять.

[stannum]

Ради интереса нашел за < 1 минуты: помоему то что надо и причем через iproute2

[Olden Gremlin]

т.е. он может по полю from маршрутизировать по орпеделенной таблице и все?
про шейпинг я имею представление - хочу имеено маршрутизацию допонять.

нравится мне эта "группа пловцов в полосатых купальниках"... это я про то, что сначала разбираемся с шейпером, а потом уже можо и на роутинг взглянуть и понять... ну да ладно...
тут до меня уже дали замечательную ссылку, но я повторюсь - читаем IP Command Reference. там документированы если не все, то многие возможности ip. итак, какие возможности мы имеем с ip?

• ip link (ip l) - конфигурация сетевого устройства
• ip address (ip a) - управление назначениями адресов устройству
• ip neightbour (ip n) - управление состоянием arp-таблицы
• ip route (ip r) - управление таблицами роутинга (ясень красень, что их может быть, при использовании ip, больше одной)
• ip rule - управление базой политик роутинга (собственно в какую таблицу роутинга направить тот или иной пакет)
• ip maddress - управление мультикастовыми адресами (не разбирался... не помогу...)
• ip mroute - управление мультикастовым роутингом (не разбирался... не помогу...)
• ip tunnel (ip t) - конфигурация туннелей (ipip, gre... есть еще sit - насколько я понял - туннелирование IPv6 трафика через IPv4)
• ip monitor и ip rmon - мониторинг состояние (не разбирался... не помогу...)

хм... ничего не забыл?... 9 позиций... неплохо... так что для "он может по полю from маршрутизировать по определенной таблице" - несколько многовато. не правда ли? или вы до сих пор пользуетесь ifconfig'ом и route?

[Olden Gremlin]

Ради интереса нашел за < 1 минуты: помоему то что надо и причем через iproute2

ИМХО если человек описывал, что у него два провайдера, если говорил о том, что не работает только DMZ, то при каком ... тут Ваша ссылка?
Я так понимаю, что либо разделенный доступ, либо распределенная нагрузка у человека и так уже настроены... и не работает именно DMZ!
Но опять таки - это только мое ИМХО.

[stannum]

А ссылка как раз про двух провайдеров, и про маршрутизацию обратных ответов к ним, а DMZ (DeMilitary Zone) - демилитаризованная зона; область локальной сети, защищенная от несанкционированного доступа извне с помощью межсетевого экрана или другого средства сетевой защиты, тут мало чего меняет.

[AnViar]

А ссылка как раз про двух провайдеров, и про маршрутизацию обратных ответов к ним, а DMZ (DeMilitary Zone) - демилитаризованная зона; область локальной сети, защищенная от несанкционированного доступа извне с помощью межсетевого экрана или другого средства сетевой защиты, тут мало чего меняет.

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

[stannum]

А покажите ваш

Код: Выделить всё

# iptables -t nat -L -vn

[AnViar]

А покажите ваш

Код: Выделить всё

# iptables -t nat -L -vn

к сожелению не могу в целях безопасности, да и не разберете вы все мои правила...
На словах: в прероутинге идет днат определенных портов в дмз, в построутинге просто маскрад всех пакетов с внутреннего интерфейса. таблицу iproute2 привел выше.
А маскарад, как я понимаю, идет позже принятия решения о маршрутизации(оно и правильно) и маскарадит по default gw...
В понедельник думаю реализую предложеную схему с 3 различными адресами в дмз для разных провайдеров - на мой взгляд самое верное решение.

кстати спасибо за документацию по iproute2 - очень подробно, жаль правдо что не переведено, но это мелочи.

[stannum]

А вы проверьте не маскарадятся ли пакеты исходящие от самого шлюза? если да то проблема очевидна.

[Olden Gremlin]

А вы проверьте не маскарадятся ли пакеты исходящие от самого шлюза? если да то проблема очевидна.

не знаю как по поводу шлюза, но идея интересная и можно было бы еще проверить тему (если на машине в DMZ стоит nix) не маскарадятся ли пакеты исходящие оттуда (ну мало ли) - они должны уходить по роутингу и _НИКАКОГО_ маскарадинга.
но, увы, если внутренняя безопасность исключает вывод iptables -t nat -L -n с обеих машин (шлюза и DMZ) то идеи на этом и закончаться...
да по большому-то счету уберите свой реальный ip из вывода командочки, заменив на xxx.xxx.xxx.xxx - все это поймут... имхо это решит вопрос безопасности

[AnViar]

А вы проверьте не маскарадятся ли пакеты исходящие от самого шлюза? если да то проблема очевидна.

судя по правилу - маскарадятся... я вас понял...
нужно исключить из маскарада зону DNZ с этими портами.. и тогда по-идее заработает iproute2 как и задумано!

[AnViar]

А вы проверьте не маскарадятся ли пакеты исходящие от самого шлюза? если да то проблема очевидна.

не знаю как по поводу шлюза, но идея интересная и можно было бы еще проверить тему (если на машине в DMZ стоит nix) не маскарадятся ли пакеты исходящие оттуда (ну мало ли) - они должны уходить по роутингу и _ИКАКОГО_ маскарадинга.
но, увы, если внутренняя безопасность исключает вывод iptables -t nat -L -n с обеих машин (шлюза и DMZ) то идеи на этом и закончаться...
да по большому-то счету уберите свой реальный ip из вывода командочки, заменив на xxx.xxx.xxx.xxx - все это поймут... имхо это решит вопрос безопасности

Да верно товарищ подсказывает - маскарадинг происходит после принятия решения о маршрутизации - вспомните туториал. И соответственно маскарад идет по маршруту по-умолчанию.
А если этот маскарад убрать(он используется только для доступа в интернет из дмз), то обратное преобразование адресов(ответных пакетов) будет происходить по номеру сессии на основании правила DNAT. И тут то iproute2 показать должен себя во всей красе! Этож как маскарад наоборот - нам не нужно делать DNAT для доступа в интернет - хватает маскарада/SNAT.
Наконец-то мой мозг вышел из ступора Огромное спасибо за советы - во вторник попробую и отпишу о результатах.
Всем удачных праздников

[AnViar]

Путь оказался ложным. Пакеты, приходящие в ответ из DMZ не попадают в правило маскарада - проверено экспериментально добавлением тестовой цепочки. Кстати вопрос почему? Из-за какого-то состояния --state этих пакетов?

Остается вариант с несколькими алиасами в DMZ

[Olden Gremlin]

Путь оказался ложным. Пакеты, приходящие в ответ из DMZ не попадают в правило маскарада - проверено экспериментально добавлением тестовой цепочки. Кстати вопрос почему? Из-за какого-то состояния --state этих пакетов?

Думаю, что экстрасенсы, среди подписчиков этой темы, сегодня в отпуске... А свои правила файрвола (из соображений безопасности(?)) Вы показывать не хотите... Увы, с такими предпосылками врядли кто-то сможет тать Вам более-менее вразумительный ответ/совет.

[mirlas]

У меня обсолютно такая же задача, как и у Вас. Пока понятно, что все прокидывается на локальную машину за фаерволом (Правилом DNAT), а обратно ответ идет только тому хосту, который обратился к IP провайдера, чей DGW стоит по умолчанию на фаерволе для исходящих пакетов. У меня задача принципиальная - нужно прокидывать так, что бы на внутреннем почтовом сервере были реальные IP клиентов. Если это не критично - то помогает rinetd. Он подменяет внешние IP адреса на внутренние и таким образом мы можем получить доступ к SMTP на локальном почтовом сервере с двух разных провайдоров. Поясню: С одного провайдера SMTP доступен через DNAT (через него же и уходит инет), а c дргого через rinetd (в этом случае, все подключения на SMTP с этого провайдера будут выглядеть как подлючения от локального адреса фаервола).
С первым вариантом - без маркировки пакетов видимо не обойтись... Пока думаю, у меня такое чувство, что я скоро что-то придумаю ) Но оно может быть ложным... ))

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

[buklov]

решил пока эту проблемму просто мапя порты через xinetd
service nek
{
disable = no
port = 3388
socket_type = stream
protocol = tcp
user = root
redirect = 192.168.1.201 3389
type = UNLISTED
wait = no
}

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