LINUX.ORG.RU
ФорумAdmin

Нужна помощь в настройке iptables

 


0

3

Итак, на машине имеется приложение. Приложению можно с помощью telnet отправлять различные команды, но только с локалхоста. То есть, например, команда

telnet localhost [port]
устанавливает соединение, а команда
telnet [ip] [port] 
запущенная с другой машины, не срабатывает.

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

telnet [ip] [port] 
?

ЗЫ

пробовал так:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5554 -j DNAT --to-destination 127.0.0.1:5554
iptables -t nat -A POSTROUTING -j MASQUERADE 
теперь пакеты приходят на локалхост, но у меня нет никаких идей, как заставить их уйти обратно.

А нет ли возможности попросить приложение слушать сокет не на 127.0.0.1, а на 0.0.0.0 или просто на адресе интерфейса в локальной сети?

pianolender ★★★ ()

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 5554 -j DNAT --to-destination 127.0.0.1:5554

Этак получаются пакеты, у которых в source адрес из локальной сети, а в destination - localhost, не очень понятно, как они будут обрабатываться..

pianolender ★★★ ()

Вообще правильно было бы, чтобы ваш telnet сервер слушал на интерфейсе eth0. Тогда надобность в правиле отпадет.

Первое правило верное, оно означает:
Когда пакет попадет в таблицу nat в цепочку PREROUTING, то если пакет пришел из интерфейса eth0, по протоколу tcp и порт назначения у него 5554 то измени, его адрес назначения на 127.0.0.1 а порт на 5554.
Здесь только лишний порт 5554 в конце. Можно написать просто 127.0.0.1 вместо 127.0.0.1:5554. Но так тоже работать будет.

Но с чего ты взял что он теперь должен его направить на адрес 127.0.0.1 ?
Чтобы он туда пошёл необходимо включить форвадинг. Делается это так.

echo 1 > /proc/sys/net/ipv4/ip_forward

После этого пакет попадет на telnet сервер на адресе 127.0.0.1. Вот только telnet сервер отправит ответ опять на 127.0.0.1. На этом этапе он и застрянет.

Идем дальше. Вот telnet сервер отправил ответ на адрес 127.0.0.1, то есть сам себе. Получается он должен попасть опять в таблицу nat и цепочку PREROUTING. Вот тут то и надо поменять его адрес назначения, а адрес назначения должен быть ip адресом того компа на котором запущен telnet клиент.

iptables -t nat -A PREROUTING -s 127.0.0.1 -i lo -d 127.0.0.1 -j DNAT --to-destination "Адрес компа клиента"
Дальше по логике вещей, вроде как этот пакет должен отправиться в интерфейс eth0. Тогда он попадет в таблицу nat цепочку POSTROUTING. Где ваше второе правило, должно поменять адрес источника пакета на правильный(на адрес компа с telnet сервером в сети интерфейса eth0).То есть второе правило сработает.

Но все это тупость. Так как нужно просто чтобы telnet сервер слушал на интерфейсе eth0.

demsi ()

Вы вообще можете объяснить почему ваш telnet сервер слушает только на интерфейсе localhost ?

demsi ()
Ответ на: комментарий от demsi

Все проще - у него на loopback коннекты разрешены, а через eth прикрыты файрфолом наверное :-)

no-dashi ★★★★★ ()
Ответ на: комментарий от no-dashi

Ну так ему надо с OUTPUT ковыряться в iptables, а он на ЛОР пришёл...

DALDON ★★★★★ ()

Ну кстати показали бы вообще как там у вас в таблицах.
Кароче

iptables -L -n
iptables -t nat -L -n
В студию.

demsi ()

rinetd решит ваши проблемы

vxzvxz ★★★ ()
Ответ на: комментарий от demsi
# iptables -t nat -L -n                                        
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
idletimer_nat_PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0           

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
idletimer_nat_POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0           
natctrl_nat_POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0           

Chain idletimer_nat_POSTROUTING (1 references)
target     prot opt source               destination         

Chain idletimer_nat_PREROUTING (1 references)
target     prot opt source               destination         

Chain natctrl_nat_POSTROUTING (1 references)
target     prot opt source               destination

примерно так, то есть по умолчанию в таблице нет ничего.

Вы вообще можете объяснить почему ваш telnet сервер слушает только на интерфейсе localhost?

Потому что его так написали(

Спасибо за советы, про ip forwarding я как-то забыл, а зря.

ответ на адрес 127.0.0.1, то есть сам себе

спасибо за идею, не пришло в голову, что фильтровать выходные пакеты надо так, чтобы src и dst были 127.0.0.1 и интерфейс lo. Буду пробовать

Alpinist ()
Ответ на: комментарий от pianolender

А нет ли возможности попросить приложение слушать сокет не на 127.0.0.1, а на 0.0.0.0 или просто на адресе интерфейса в локальной сети?

Увы, нет. Приложение в качестве параметра, имеющего отношение к работе телнет-сервера, принимает только номер порта

Alpinist ()
Ответ на: комментарий от demsi

а адрес назначения должен быть ip адресом того компа на котором запущен telnet клиент.

И как же узнать этот адрес?

Alpinist ()
Ответ на: комментарий от demsi

iptables -t nat -A PREROUTING -s 127.0.0.1 -i lo -d 127.0.0.1 -j DNAT --to-destination «Адрес компа клиента»

Весь трафик с lo на lo пойдет через eth0 вовне? А как насчет сислога и прочих демонов, которые друг с другом по сети через локалхост разговаривают? Или у них source не 127.0.0.1?

pianolender ★★★ ()

на компе клиента есть возможность запустить ssh/putty?

Если да, то можно сделать так: ssh -L 5554:localhost:5554 <ip компа, на котором telnet-сервер>, и после этого на клиентской машине ходить на локалхост. Вроде даже iptables не надо ковырять.

pianolender ★★★ ()
Ответ на: комментарий от pianolender

Ну тогда можно еще добавить --dport 5554, и тогда демоны не будут потревожены

Alpinist ()
Ответ на: комментарий от Alpinist

Кстати!

Можно сделать прямо на сервере

ssh -L 192.168.1.2:5554:localhost:5554 -fN

И тогда уже подключаться прямо с клиента на сервер

pianolender ★★★ ()

Это невозможно, сам не так давно пытался это сделать.

Ядро не будет маршрутизировать пакеты in/out 127.0.0.1 а также broadcast и multicast. Так как это противоречит требованиям ietf (http://tools.ietf.org/html/rfc1812#section-5.3.7)

invokercd ★★★★ ()

Что-то зачастили в последнее время темы с попытками проброса внешних пакетов на loopback.
Кина не будет, iptables тебе не поможет. Лезь на хост по SSH и там уже телнеться куда надо - это самый правильный путь имхо.

thesis ★★★★★ ()
Ответ на: комментарий от pianolender

Весь трафик с lo на lo пойдет через eth0 вовне? А как насчет сислога и прочих демонов, которые друг с другом по сети через локалхост разговаривают? Или у них source не 127.0.0.1

Ну если бы ядро маршрутизировало пакеты in/out 127.0.0.1
То проблем никаких по поводу демонов:

iptables -t nat -A PREROUTING -s 127.0.0.1 -i lo -d 127.0.0.1 -j DNAT --sport 5554 --to-destination «Адрес компа клиента»
Но как сказал invokercd

Это невозможно, сам не так давно пытался это сделать. Ядро не будет маршрутизировать пакеты in/out 127.0.0.1 а также broadcast и multicast. Так как это противоречит требованиям ietf

Кстати я этого не знал. Спасибо invokercd за просвещение.

Alpinist Я же вас просил дать вывод двух команд.

iptables -L -n 
и 
iptables -t nat -L -n 
Вообщето у iptables Не одна таблица, а четыре. А вы дали вывод только одной.

Увы, нет. Приложение в качестве параметра, имеющего отношение к работе телнет-сервера, принимает только номер порта

А откуда уверенность что ваш telnet сервер слушает только localhost ?
Может дадите вывод команды. C компа где запущен telnet сервер.

netstat -apn | grep "telnet"
У меня вообще возникает мысль что ваш telnet сервер слушает все правильно, а просто в таблице filter фильтруются пакеты с интерфейса eth0. Но пока вы не дадите вывод команды iptables -L -n мы этого не узнаем.

И еще желательно iptables -v. А то у меня например нету стандартной цепочки INPUT в таблице nat. У меня версия 1.4.8

demsi ()

Ну даже если на то пошло что ваш СТРАННЫЙ telnet-сервер слушает ТОЛЬКО на localhost. Почему бы не использовать другой telnet-сервер, который можно настроить как вам удобно. Или использовать более безопасный ssh( например openssh-server) ?

demsi ()
Ответ на: комментарий от demsi

Фуф, получил доступ к машине, привожу все листинги

netstat -apn | grep «telnet»

пусто, ничего нег

iptables -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
bw_INPUT   all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
bw_FORWARD  all  --  0.0.0.0/0            0.0.0.0/0           
natctrl_FORWARD  all  --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
bw_OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           

Chain bw_FORWARD (1 references)
target     prot opt source               destination         

Chain bw_INPUT (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           
           all  --  0.0.0.0/0            0.0.0.0/0            owner socket exists

Chain bw_OUTPUT (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0           
           all  --  0.0.0.0/0            0.0.0.0/0            owner socket exists

Chain costly_shared (0 references)
target     prot opt source               destination         
penalty_box  all  --  0.0.0.0/0            0.0.0.0/0           

Chain natctrl_FORWARD (1 references)
target     prot opt source               destination         

Chain penalty_box (1 references)
target     prot opt source               destination

Кина не будет, iptables тебе не поможет

эх, спасибо за информацию, не знал.

Ладно, всем спасибо за помощь и информацию, буду искать другие пути, в принципе, в теме уже много насоветовали

Alpinist ()
Ответ на: комментарий от Alpinist

netstat -apn | grep «telnet»

пусто, ничего нет

Вы издеваетесь ?
Название исполняемого файла вашего telnet сервера не знаете ?
Так ладно, мне все надоело, я думаю вы сами разберетесь. Потому что предоставляемая информация не позволяет понять, что у вас там происходит.
Еще раз повторюсь, в чем причина использования именно этого telnet сервера ?

demsi ()
Ответ на: комментарий от Alpinist

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

iptables -t nat -F PREROUTING
iptables -t nat -F POSTROUTING
iptables -F INPUT
iptables -F OUTPUT
И тогда точно будете знать что iptbales ничего не фильтрует.
И еще раз дайте вывод
netstat -apn | grep -i "НАЗВАНИЕ ИСПОЛНЯЕМОГО ФАЙЛА TELNET СЕРВЕРА"
или
netstat -apn | grep "5554"
Естественно при запущенном telnet сервере.

demsi ()
Ответ на: комментарий от demsi

netstat -apn | grep «5554»

tcp6       0      0 ::ffff:127.0.0.1:5554  :::*                   LISTEN

такие дела

Всё, спасибо, волшебный патч - и теперь программа слушает 0.0.0.0

Просто никто не хотел перепиливать чужую программу, мы думали, что проблему можно решить с помощью iptables

Спасибо за ответы

Alpinist ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.