форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"подписка пакетов на шлюзе с многими интерфейсами"

Сообщение от Алекс (??) on 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

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "подписка пакетов на шлюзе с многими интерфейсами"

Сообщение от Алекс (??) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от biffant (ok) on 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 на ум не приходит но это немного не то
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от Алекс (??) on 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, а в любом демоне
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от biffant (ok) on 09-Ноя-07, 17:35
	Про нормальные адреса не понял - имеете ввиду что там реальники забиты?? В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на 10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны клиента
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от Алекс (??) on 09-Ноя-07, 17:39
	>Про нормальные адреса не понял - имеете ввиду что там реальники забиты?? да, реальные... >В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий >порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на >10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны >клиента проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче.. типа rp_filter или подобных. Теперь уже сомневаюсь
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от biffant (ok) on 09-Ноя-07, 17:50
	>проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче.. >типа rp_filter или подобных. Теперь уже сомневаюсь У меня есть multihomed-сервер, на котором вертится sendmail, так вот через какой интерфейс ему ответить подключившемуся клиенту, определяется именно функционалом rule в iproute. Правда там все тривиально - через какой обратились, от того имени и отвечаем, потому как иначе клиент видит что запрос отправлял одному хосту а отвечает совсем другой - и отключается... По сетевым настройкам ядра не специалист, но по-моему это не фича даже а неслабый такой функционал, который одним параметром не задашь. Но задача интересная, всегда думал что в описанной ситуации ответ будет от 192.168.0.1
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от Алекс (??) on 09-Ноя-07, 17:53
	>Правда там все тривиально - через какой обратились, от того имени и >отвечаем, потому как иначе клиент видит что запрос отправлял одному хосту >а отвечает совсем другой - и отключается... не отключится.. дело в том, что на роутере этом поднят BGP, и за ним - своё адресное пространство, и нужно "отвечать" под своим родным ИП, а не под ИП интерфейсных пар БГП-пиров.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от biffant (ok) on 09-Ноя-07, 18:06
	Если научитесь эту задачу решать ядром, без использования iproute и iptables, пишите, любопытно :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от thehangedman (ok) on 09-Ноя-07, 17:52
	А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих с 10.1.0.1 с 53 порта - разве не решит проблему?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "подписка пакетов на шлюзе с многими интерфейсами"
	Сообщение от Алекс (??) on 09-Ноя-07, 17:55
	>А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих >с 10.1.0.1 с 53 порта - разве не решит проблему? возможно решит. Нужно поэкспериментировать. Но этот выход кажется каким-то искуственным
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]