https://m.opennet.dev/openforum/vsluhforumID1/77267.html на шлюзе есть 3 интерфейса<br>xx.xx.xx.1<br>yy.yy.yy.2<br>zz.zz.zz.3<br><br>zz.zz.zz.3 слушает named, но если запросы приходят с xx.xx.xx.1 или yy.yy.yy.2, но соответственно от ставит сорсом IP интерфейса, с которого ушел ответ.<br><br>Можно ли добиться того чтобы независимо откуда пришел запрос на zz.zz.zz.3, ответ тоже уходил от zz.zz.zz.3<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#10 Fri, 09 Nov 2007 15:06:51 GMT Если научитесь эту задачу решать ядром, без использования iproute и iptables, пишите, любопытно :)<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#9 Fri, 09 Nov 2007 14:55:50 GMT &gt;А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих <br>&gt;с 10.1.0.1 с 53 порта - разве не решит проблему? <br><br>возможно решит. Нужно поэкспериментировать. Но этот выход кажется каким-то искуственным<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#8 Fri, 09 Nov 2007 14:53:37 GMT &gt;Правда там все тривиально - через какой обратились, от того имени и <br>&gt;отвечаем, потому как иначе клиент видит что запрос отправлял одному хосту <br>&gt;а отвечает совсем другой - и отключается... <br><br>не отключится.. дело в том, что на роутере этом поднят BGP, и за ним - своё адресное пространство, и нужно "отвечать" под своим родным ИП, а не под ИП интерфейсных пар БГП-пиров.<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#7 Fri, 09 Nov 2007 14:52:09 GMT А просто в POSTROUTING добавить SNAT на 192.168.0.1 для всех пакетов исходящих с 10.1.0.1 с 53 порта - разве не решит проблему?<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#6 Fri, 09 Nov 2007 14:50:41 GMT &gt;проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче.. <br>&gt;типа rp_filter или подобных. Теперь уже сомневаюсь <br><br>У меня есть multihomed-сервер, на котором вертится sendmail, так вот через какой интерфейс ему ответить подключившемуся клиенту, определяется именно функционалом rule в iproute. <br><br>Правда там все тривиально - через какой обратились, от того имени и отвечаем, потому как иначе клиент видит что запрос отправлял одному хосту а отвечает совсем другой - и отключается...<br><br>По сетевым настройкам ядра не специалист, но по-моему это не фича даже а неслабый такой функционал, который одним параметром не задашь. Но задача интересная, всегда думал что в описанной ситуации ответ будет от 192.168.0.1<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#5 Fri, 09 Nov 2007 14:39:05 GMT &gt;Про нормальные адреса не понял - имеете ввиду что там реальники забиты?? <br><br>да, реальные...<br><br><br>&gt;В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий <br>&gt;порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на <br>&gt;10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны <br>&gt;клиента <br><br>проблема не в маршрутизации.. маршрутизация работает корректно. Я думал дело в фиче.. типа rp_filter или подобных. Теперь уже сомневаюсь<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#4 Fri, 09 Nov 2007 14:35:29 GMT Про нормальные адреса не понял - имеете ввиду что там реальники забиты??<br><br>В общем можно через rule'ы iproute маршрутизировать ответ на пакеты на 53-ий порт третьего интерфейса через третий интерфейс (при этом прописать маршрут на 10.1.0.1/24 через интерфейс 10.1.0.1), но такое соединение может обрываться со стороны клиента<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#3 Fri, 09 Nov 2007 14:13:07 GMT &gt;Откуда уверенность что ответ приходит именно от 10.1.0.1? Случаем не настроен ли <br>&gt;NAT из 192.168.0.1/24 в 10.1.0.1/24? <br>&gt;<br>&gt;Очевидно, физически пакет в TCP/IP сети действительно приходит с интерфейса 10.1.0.1 т.к. <br>&gt;в данном случае сервер выступает в роли маршрутизатора <br>&gt;<br>&gt;Из настроек named, ничего кроме query-source на ум не приходит но это <br>&gt;немного не то <br><br>НАТа нет.. адреса нормальные, не серые. Сервер выступает в роли маршрутизатора и такое поведение есть нормальным, но можно ли поправить, ибо если у других включен source route verification, то пакеты будут отбрасываться, что и происходит сейчас, возможно есть какая-нибудь опция в /proc ? Дело не только в named, а в любом демоне<br> https://m.opennet.dev/openforum/vsluhforumID1/77267.html#2 Fri, 09 Nov 2007 13:52:34 GMT Откуда уверенность что ответ приходит именно от 10.1.0.1? Случаем не настроен ли NAT из 192.168.0.1/24 в 10.1.0.1/24?<br><br>Очевидно, физически пакет в TCP/IP сети действительно приходит с интерфейса 10.1.0.1 т.к. в данном случае сервер выступает в роли маршрутизатора<br><br>Из настроек named, ничего кроме query-source на ум не приходит но это немного не то<br>