Прошу помощи линуксоидов (iptables)!:решено: 

сразу навскидку - rinetd
в rinetd.conf пишешь:
200.150.100.50:9876 10.20.30.40:3389
запускаешь его, lsof -i | grep rinetd убеждаешься что rinetd слушает порт на внешнем адресе.
и все, но это при условии что в цепочках INPUT и OUTPUT стоит по умолчанию ACCEPT. Если нет, то пишешь:
iptables -A INPUT -s 200.150.100.50 -d 10.20.30.40 -j ACCEPT
iptables -A OUTPUT -s 10.20.30.40 -d 200.150.100.50 -j ACCEPT

а вот совсем просто:
iptables -t nat -PREROUTING -i eth0 -p tcp --dport 9876 -j DNAT --to 10.20.30.40:3389

ЗЫ. Тоже админю Фрю, не очень давно столкнулся с линухом)

в цепочках по умолчанию ACCEPT
Не срабатывает почему-то правило.
Или не доходит до него, х.з.
При попытке подключиться телнетом на 200.150.100.50:9876 телнет говорит, что ему не удалось установить подключение :/

Вот пытаюсь в лог что-нибудь заставить ее писать....

evgenyk писал:сразу навскидку - rinetd
в rinetd.conf пишешь:
200.150.100.50 9876 10.20.30.40 3389

Спасибо за подсказку!
Этот вариант заработал.
Но он только tcp умеет.

А вот вариант с iptables так и не заработал...

UPD:
часть проблем была из-за того, что я под действием электромагнитного поля коллайдера попутал интерфейсы :)
вместо eth0 есть venet0.

но с iptables заработал пока только SNAT из VPN-сети.
DNAT порт-форвардинг (исходная задача) так пока и не работает.
Но пакеты на удаленном порту уже принимаются :)
только вот до *filter:FORWARD они почему-то не доходят.
И к адресату не отправляются.... :/

Боевой серв, при конекте на внешний адрес на порт 20001 идет проброс на ХР

Код:

root@host:~# cat /etc/rc.d/rc.firewall | grep '10.3.0.5'     $IPTABLES -A FORWARD -s 10.3.0.5/32 -j ACCEPT     $IPTABLES -A FORWARD -d 10.3.0.5/32 -j ACCEPT     $IPTABLES -t nat -A PREROUTING -s 0/0 -d $INET\_IP -p tcp —dport 20001 -j DNAT —to-destination 10.3.0.5:3389

Кстати тут 2 форварда необязательно..., если не ошибаюсь для проброса достаточно -d.

Если данная конфигурация не заработает, смотри в сторону маршрутизации.
Грубо говоря...
Пакет добегает до внешнего адреса, потом с помошью iptables пробрасывается внутрь локалки и бежит до тачки по ЛОКАЛУ. Обратно он должен бежать также. Если у тебя используется впн, то при таком раскладе обратно пакет пойдет по тунелю. Отсюда ничего не будет работать. В таком случае надо бить роут на локальной машине, или iptables-ом заворачивать напрямую в тунель...

Во скока написал Надеюсь понятно

marader писал :Боевой серв, при конекте на внешний адрес на порт 20001 идет проброс на ХР

Кстати тут 2 форварда необязательно..., если не ошибаюсь для проброса достаточно -d.

У меня пока по умочанию всё ACCEPT, но на всякий случай добавил, ещё и в -j LOG

marader писал :Если данная конфигурация не заработает,

Не заработала :/

marader писал:смотри в сторону маршрутизации
Грубо говоря...
Пакет добегает до внешнего адреса, потом с помошью iptables пробрасывается внутрь локалки и бежит до тачки по ЛОКАЛУ. Обратно он должен бежать также. Если у тебя используется впн, то при таком раскладе обратно пакет пойдет по тунелю.

VPN выглядит как локалка (как я понимаю)

marader писал :Во скока написал Надеюсь понятно

Понятно вроде.
Но не работает :/
Но в лог что-то идёт:

Код:

~# dmesg -c IN=venet0 OUT= MAC= SRC=откуда\_пришёл DST=через\_кого\_проброс LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=51701 DF PROTO=TCP SPT=62337 DPT=20001 WINDOW=65535 RES=0x00 SYN URGP=0 IN=venet0 OUT=tun0 SRC=откуда\_пришёл DST=10.8.0.22(на\_кого\_проброс)  LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=51701 DF PROTO=TCP SPT=62337 DPT=3389 WINDOW=65535 RES=0x00 SYN URGP=0 IN=venet0 OUT=tun0 SRC=откуда\_пришёл DST=10.8.0.22 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=51702 DF PROTO=TCP SPT=62337 DPT=3389 WINDOW=65535 RES=0x00 SYN URGP=0 IN=venet0 OUT=tun0 SRC=откуда\_пришёл DST=10.8.0.22 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=51713 DF PROTO=TCP SPT=62337 DPT=3389 WINDOW=65535 RES=0x00 SYN URGP=0

То есть получается, что в локалку(vpn) она его всё-таки заворачивает.

ДЛЯ проверки DNAT вообще решил попробовать вот так:

Код:

iptables -t nat -A PREROUTING -d 10.8.0.1 -p tcp -m tcp —dport 1270 -j DNAT —to-destination 10.8.0.22:3389

То есть пробросить порт 1270 c 10.8.0.1 (сервер, он же с внешним IP, он же OpenVPN сервер) на ту же экспериментальную машину.

telnet с сервера (10.8.0.1) на 10.8.0.22:3389 дает коннект.
telnet с другой машины (тоже в ВПНе 10.8.0.6) на 10.8.0.22:3389 дает коннект.

telnet с другой машины (тоже в ВПНе 10.8.0.6) на 10.8.0.1:1270 пропадает в бездне....

Код:

# dmesg IN=tun0 OUT= MAC= SRC=10.8.0.6 DST=10.8.0.1 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=52225 DF PROTO=TCP SPT=1929 DPT=1270 WINDOW=16384 RES=0x00 SYN URGP=0 IN=tun0 OUT=tun0 SRC=10.8.0.6 DST=10.8.0.22 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=52225 DF PROTO=TCP SPT=1929 DPT=3389 WINDOW=16384 RES=0x00 SYN URGP=0 IN=tun0 OUT=tun0 SRC=10.8.0.6 DST=10.8.0.22 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=52231 DF PROTO=TCP SPT=1929 DPT=3389 WINDOW=16384 RES=0x00 SYN URGP=0 IN=tun0 OUT=tun0 SRC=10.8.0.6 DST=10.8.0.22 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=52238 DF PROTO=TCP SPT=1929 DPT=3389 WINDOW=16384 RES=0x00 SYN URGP=0

P.S.: я не админ вообще, всё что знаю, так.... в порядке самообразования. Просто когда-то интересно было юнихами позаниматься.
Потом в добровольном порядке удаленный freebsd-сервер (VDS) поддерживал корпоративный.
Узнавал решение проблем, так сказать по мере их возникновения.

А тут решил взять ещё один линух-сервер (то же VDS) именно для создания VPN сетки и возможности в неё порты пробрасывать.
OpenVPN поднял легко, даже через туннель выход во внешку для пробы получил, хотя задачи такой и нет...
А вот с проброской портов штатным iptables пока затык.
rinetd - работает без проблем.

Но блин, досадно себя дураком ощущать :)

Так. Попробуй мою конфигурацию, с учетом того, что на клиенте будет выключен впн, а также всякие фаерволы.
+ вопрос. Этот впн является шлюзом для клиента или нет?

marader писал :Так. Попробуй мою конфигурацию,

Твою и пробовал.

marader писал :с учетом того, что на клиенте будет выключен впн,

Это невозможно, тогда весь смысл пропадет.
VPN здесь выполняет роль псевдо-локалки.
На самом деле подключение к серваку идёт через инет.
Клиенты (с "серыми" IP) подключаются через VPN к серваку со всего мира (утрировано) и видят друг-друга как в обычной локалке.

marader писал :а также всякие фаерволы.

выключен.

marader писал :+ вопрос. Этот впн является шлюзом для клиента или нет?

нет, не является.

Всем спасибо!
Вопрос решен.

P.S.: оказывается действительно необходимо было дополнительно завернуть пакеты в туннель

Код:

iptables -t nat -A POSTROUTING -o tun0 -j SNAT —to-source 10.8.0.1

Где 10.8.0.1 VPNовский адрес того же сервака, с которого порт и пробрасывается