iptables необычный проброс портов (не получается как надо :()

[falcol]

Здравствуйте. Столкнулся с интересной задачей.
Есть роутер, сервер приложения и клиент (для примера клиент один, но вообще их много)
роутер в основном занимается выпуском клинета в инет.
роутер 192.168.0.1
сервер приложения 192.168.0.2
порт приложения 12345
клиент 192.168.0.3

Задача сделать так чтобы клиент подключаясь на 192.168.0.1:12345 мог подключиться к приложению, находящемуся на 192.168.0.2:12345.
Казалось бы проще простого
iptables -A PREROUTING -d 192.168.0.1 -p tcp --dport 123456 -j DNAT --to-destination 192.168.0.2
работатет
НО т.к. приложение использует фильтрацию по ip адресу, то получается сервер приложения пускает всех клиентов, если в фильтре приложения прописано от ip 192.168.0.1 и не пускает никого если убрать из фильтра 192.168.0.1.
Т.е получается что DNAT подменяет не только адрес получателя, но и адрес отправителя.
Как быть, посоветуйте пож. что нибудь, я уже всю голову сломал.

[arkhnchul]

Т.е получается что DNAT подменяет не только адрес получателя, но и адрес отправителя.

нет. Адрес отправителя меняет SNAT или MASQUERADE. Раз у вас роутер, то всяко такие правила есть. Посмотрите внимательно, что под них подпадает и какого поведения вы хотитие.

[falcol]

Т.е получается что DNAT подменяет не только адрес получателя, но и адрес отправителя.

нет. Адрес отправителя меняет SNAT или MASQUERADE. Раз у вас роутер, то всяко такие правила есть. Посмотрите внимательно, что под них подпадает и какого поведения вы хотитие.

Ну вообще да,Вы правы... Ну если можно... приведиде пример как решить эту задачу если предположительно нет ни одного правила в фаерволе...
Если просто сделать DNAT, она же тоже не будет работать... ведь получается как... пакет идет от 192,168,0,3, попадает на 192,168,0,1 меняет адрес получателя на 192,168,0,2, попадает на 192,168,0,2 вроди понятно.
но теперь как 192,168,0,2 поймет кому ему отвечать... если он ответит клиенту - тот его проигнорирует,т.к. он ждет ответа от 0,1, а если он ответит 0.1-му то тот не поймет че с ним делать... во всяком случае у меня так вообще не подключается...

[sash-kan]

приведиде пример

port forwarding

[falcol]

приведиде пример

port forwarding

Ды это как раз таки пробовалось... если сделать так, то на машину 192,168,0,2 будут приходить пакеты от 192,168,0,1 и соответственно фильтр не пустит... либо если сделать разрешить от 192,168,0,1 смогут ломиться все.
а мне надо чтобы 192,168,0,1 послал так, будто запрос пришел от 192,168,0,3

[alex_suse]

Тогда в mangle PREROUTING промаркируйте пакеты в соответствии с правилами пускать(не пускать), а в filter FORWARD заблокируйте кого не пускать.

[danger08]

Если просто сделать DNAT, она же тоже не будет работать... ведь получается как... пакет идет от 192,168,0,3, попадает на 192,168,0,1 меняет адрес получателя на 192,168,0,2, попадает на 192,168,0,2 вроди понятно.
но теперь как 192,168,0,2 поймет кому ему отвечать... если он ответит клиенту - тот его проигнорирует,т.к. он ждет ответа от 0,1, а если он ответит 0.1-му то тот не поймет че с ним делать...

Теоретические основы, почему так происходит, есть здесь. Начиная с фразы "А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети."
Если вкратце, то вам понадобится пара SNAT/DNAT.

[falcol]

Если просто сделать DNAT, она же тоже не будет работать... ведь получается как... пакет идет от 192,168,0,3, попадает на 192,168,0,1 меняет адрес получателя на 192,168,0,2, попадает на 192,168,0,2 вроди понятно.
но теперь как 192,168,0,2 поймет кому ему отвечать... если он ответит клиенту - тот его проигнорирует,т.к. он ждет ответа от 0,1, а если он ответит 0.1-му то тот не поймет че с ним делать...

Теоретические основы, почему так происходит, есть здесь. Начиная с фразы "А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети."
Если вкратце, то вам понадобится пара SNAT/DNAT.

я как раз таки и описал почему так происходит)))
я уже весь абзац 20 раз перечитывал по поводу действия DNAT, но если делать как там написано - ип адрес подменяется на ип адрес сервера,а мне надо чтобы он под клиентским ip адресом доходил до 192,168,0,2.
т.е. чтобы 192,168,0,2 думал что запрос приходит с ip 192,168,0,3,а не 192,168,0,1.
они в одной подсети... я думаю тут надо ченибуть приколбасить вроди форварда как в ипфв на фрибсд...

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

[danger08]

я как раз таки и описал почему так происходит)))
я уже весь абзац 20 раз перечитывал по поводу действия DNAT, но если делать как там написано - ип адрес подменяется на ип адрес сервера,а мне надо чтобы он под клиентским ip адресом доходил до 192,168,0,2.
т.е. чтобы 192,168,0,2 думал что запрос приходит с ip 192,168,0,3,а не 192,168,0,1.

Вы можете прописать на 192.168.0.2 роутинг на 192.168.0.3 так, чтобы шлюзом для него являлся 192.168.0.1. Тогда ответные пакеты к 192.168.0.3 будут идти не напрямую, а должны попасть в то же соединение. На сервере 192.168.0.1, нужен будет DNAT в сторону 192.168.0.2 (переброс клиента на настоящий сервер) и SNAT в сторону клиента, чтоб маскировать 192.168.0.2 адресом "подставного" сервера 192.168.0.1.

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

[falcol]

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

Дело в том,что это сервер который раздает инет абонентам. Абонентов много. У них адрес сервера (UTM5) и шлюз в их памятках прописаны как один сервер. Раньше этот сервер действительно был единственным. Но сейчас возникла необходимость перенести шлюз на другой комп. Если мы не сделаем проброс, то всем абонентам придется менять адрес шлюза, либо сервера (UTM5)

[danger08]

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

Дело в том,что это сервер который раздает инет абонентам. Абонентов много. У них адрес сервера (UTM5) и шлюз в их памятках прописаны как один сервер. Раньше этот сервер действительно был единственным. Но сейчас возникла необходимость перенести шлюз на другой комп. Если мы не сделаем проброс, то всем абонентам придется менять адрес шлюза, либо сервера (UTM5)

Лучше сразу оптимизируйте структуру.
Сейчас понадобился NAT в две стороны, потом понадобится особенное правило для обхода этого двустороннего NAT-a, а потом NAT, правила которого не затрагивают этот двусторонний NAT и т.п. Упрощайте логику, насколько возможно. Мне кажется, лучшим вариантом будет выпустить обновлённые памятки для абонентов.