URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 77267
[ Назад ]
Исходное сообщение
"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 12:49 
на шлюзе есть 3 интерфейса
xx.xx.xx.1
yy.yy.yy.2
zz.zz.zz.3

zz.zz.zz.3 слушает named, но если запросы приходят с xx.xx.xx.1 или yy.yy.yy.2, но соответственно от ставит сорсом IP интерфейса, с которого ушел ответ.

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

Содержание
Сообщения в этом обсуждении
"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 16:31 
>на шлюзе есть 3 интерфейса
>xx.xx.xx.1
>yy.yy.yy.2
>zz.zz.zz.3
>
>zz.zz.zz.3 слушает named, но если запросы приходят с xx.xx.xx.1 или yy.yy.yy.2, но
>соответственно от ставит сорсом IP интерфейса, с которого ушел ответ.
>
>Можно ли добиться того чтобы независимо откуда пришел запрос на zz.zz.zz.3, ответ
>тоже уходил от zz.zz.zz.3

Возможно немного некорректно... перефразирую:

есть шлюз, интерфейсы 10.1.0.1/24 и 192.168.0.1/24... демон слушает 192.168.0.1,
клиент 10.1.0.2 посылает запрос на 192.168.0.1.. но приходит ответ от 10.1.0.1

как сделать чтобы ему ответ приходил от 192.168.0.1

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено biffant , 09-Ноя-07 16:52 
Откуда уверенность что ответ приходит именно от 10.1.0.1? Случаем не настроен ли NAT из 192.168.0.1/24 в 10.1.0.1/24?

Очевидно, физически пакет в TCP/IP сети действительно приходит с интерфейса 10.1.0.1 т.к. в данном случае сервер выступает в роли маршрутизатора

Из настроек named, ничего кроме query-source на ум не приходит но это немного не то

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 17:13 
>Откуда уверенность что ответ приходит именно от 10.1.0.1? Случаем не настроен ли
>NAT из 192.168.0.1/24 в 10.1.0.1/24?
>
>Очевидно, физически пакет в TCP/IP сети действительно приходит с интерфейса 10.1.0.1 т.к.
>в данном случае сервер выступает в роли маршрутизатора
>
>Из настроек named, ничего кроме query-source на ум не приходит но это
>немного не то

НАТа нет.. адреса нормальные, не серые. Сервер выступает в роли маршрутизатора и такое поведение есть нормальным, но можно ли поправить, ибо если у других включен source route verification, то пакеты будут отбрасываться, что и происходит сейчас, возможно есть какая-нибудь опция в /proc ? Дело не только в named, а в любом демоне

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено biffant , 09-Ноя-07 17:35 
Про нормальные адреса не понял - имеете ввиду что там реальники забиты??

В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на 10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны клиента

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 17:39 
>Про нормальные адреса не понял - имеете ввиду что там реальники забиты??

да, реальные...


>В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий
>порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на
>10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны
>клиента

проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче.. типа rp_filter или подобных. Теперь уже сомневаюсь

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено biffant , 09-Ноя-07 17:50 
>проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче..
>типа rp_filter или подобных. Теперь уже сомневаюсь

У меня есть multihomed-сервер, на котором вертится sendmail, так вот через какой интерфейс ему ответить подключившемуся клиенту, определяется именно функционалом rule в iproute.

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

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

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 17:53 
>Правда там все тривиально - через какой обратились, от того имени и
>отвечаем, потому как иначе клиент видит что запрос отправлял одному хосту
>а отвечает совсем другой - и отключается...

не отключится.. дело в том, что на роутере этом поднят BGP, и за ним - своё адресное пространство, и нужно "отвечать" под своим родным ИП, а не под ИП интерфейсных пар БГП-пиров.

"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено biffant , 09-Ноя-07 18:06 
Если научитесь эту задачу решать ядром, без использования iproute и iptables, пишите, любопытно :)
"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено thehangedman , 09-Ноя-07 17:52 
А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих с 10.1.0.1 с 53 порта - разве не решит проблему?
"подписка пакетов на шлюзе с многими интерфейсами"
Отправлено Алекс , 09-Ноя-07 17:55 
>А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих
>с 10.1.0.1 с 53 порта - разве не решит проблему?

возможно решит. Нужно поэкспериментировать. Но этот выход кажется каким-то искуственным