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

[blockquote]-t mangle -A PREROUTING -d ext_ip -i ext_eth -p tcp -m tcp --dport 80(или какой нужно) -j MARK --set-mark 0x4(к примеру)

-t nat -A PREROUTING -p tcp -i ext_eth -d ext_ip -m tcp --dport 80 -j DNAT --to-dest int_ip:80
-t nat -A POSTROUTING -s int_ip -m mark --mark 0x4 -j SNAT --to-source ext_ip

-t filter -A FORWARD -d int_ip -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-t filter -A FORWARD -s int_ip -i gw_int_ip -m state --state NEW -j ACCEPT

next_ip - наружный IP шлюза;
ext_eth - наружная сетевая;
int_ip - IP машины куда надо пробросить соединение;
gw_int_ip - IP карточки на шлюзе, которая смотрит внутрь сети.

В таблицах mangle & nat - полиси на ACCEPT можно поставить.[/blockquote]

[blockquote]Хотелось бы сделать проброс портов с 10.1.0.1 на 192.168.1.11 (адрес этой машины).[/blockquote]
[blockquote]$IPT -t nat -A PREROUTING --dst 10.1.0.1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.10[/blockquote]

Тоесть ты хочешь по VPN (10.1.0.1) адресу сервера попадать с помощью RDP на хост 192.168.1.11, подключаясь к VPN серверу извне ?

Тогда почему у тебя в правилах проброс осуществляется на адрес 192.168.1.10 ?

[blockquote]Но если смотреть подробную статистику соединенй на 192.168.1.10, то видно что трафик лишь приходит, но никуда не отправлятеся.[/blockquote]
А хост 192.168.1.10 вообще может достучаться до машин из виртуальной подсети, может быть с маршрутизацией проблемы ? Ну например, что говорит ping 10.1.0.1 ?

[blockquote]$IPT –t nat –A OUTPUT –dst 192.168.1.10 –dport 3389 –j DNAT –to --to-destination 10.1.0.1[/blockquote]
А это правило вообще зачем ?
Оно гласит примерно о том, что исходящие (OUTPUT) из таблицы nat пакеты, адресованные хосту 192.168.1.10 на порт 3389 надо завернуть на хост 10.1.0.1. Мягко говоря в цепочку nat/OUTPUT попадают только пакеты исходящие от локальных процессов, получается, что трафик генериует сам сервер ? ( в общем бред какой то )

У меня конечно есть сомнения, что я правильно понял суть задачи, но если нужно сделать именно то, что я описал выше, то необходимо сделать примерно следующее:
[color=green]iptables -t nat -A PREROUTING -i ppp0 --dst 10.1.0.1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.11[/color]
при этом необходимо, что бы у хоста 192.168.1.11 была связь с 10.1.0.1
ещё необходимо, что бы фаервол пропускал пакеты относящиеся к этому соединению, т.е. что бы как минимум этот трафик принимался (ACCEPT) в цепочке FORWARD
например:
[color=green]iptables -A FORWARD -p tcp -i ppp0 -s 0/0 -d 192.168.1.11 --dport 3389 -j ACCEPT[/color]
причём в обратную сторону тоже:
[color=green]iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT[/color]

Тема проброса соединений обсуждалась так же в [link=http://www.nclug.ru/forum_viewtopic.php?4.7479]этой ветке[/link].
<span class='smallblacktext'>[ Редактирование 13.01.2007 - 21:37:35 ]</span>

[blockquote]вот товарищу ответ был на опеннете однажды
сие работает, у меня ощущения что тут много лишнего конешно, но сейчас влом копаться

[blockquote]-t mangle -A PREROUTING -d ext_ip -i ext_eth -p tcp -m tcp --dport 80(или какой нужно) -j MARK --set-mark 0x4(к примеру)

-t nat -A PREROUTING -p tcp -i ext_eth -d ext_ip -m tcp --dport 80 -j DNAT --to-dest int_ip:80
-t nat -A POSTROUTING -s int_ip -m mark --mark 0x4 -j SNAT --to-source ext_ip

-t filter -A FORWARD -d int_ip -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-t filter -A FORWARD -s int_ip -i gw_int_ip -m state --state NEW -j ACCEPT

next_ip - наружный IP шлюза;
ext_eth - наружная сетевая;
int_ip - IP машины куда надо пробросить соединение;
gw_int_ip - IP карточки на шлюзе, которая смотрит внутрь сети.
[/blockquote]
В таблицах mangle & nat - полиси на ACCEPT можно поставить.[/blockquote]

Ещё один бред.
Сначала метятся пакеты, в дальнейшем переадресовываемые хосту внутренней сети, а потом делается попытка выпустить наружу через SNAT помеченные пакеты вернувшиеся от хоста внутренней сети, только не учитывается один момент, что на вход int_ip пакет не может прийти помеченным, можно было бы конечно по определённым критериям метить пакеты возвращающиеся из внутренней сети, но это помоему вообще лишний конструктивный элемент.
<span class='smallblacktext'>[ Редактирование 13.01.2007 - 22:34:53 ]</span>

[quote=frug]Тоесть ты хочешь по VPN (10.1.0.1) адресу сервера попадать с помощью RDP на хост 192.168.1.11, подключаясь к VPN серверу извне ?[/quote]
Поднять туннель и попасть в адресное пространство сервера (10.1.0.0/255.255.0.0). На сервере два сетевых интерфейса - один реальный 84.54........ и серый локальный 192.168..... Поверх реального ип уже работает овпн туннель. Таким образом хотелось бы поднять туннель и попасть по рдп на машину в локальной сети. Адрес этой машины - 192.168.1.10 Сервер в локальной сети имеет адрес 192.168.1.11. Соотв. указывая rdesktop 10.1.0.1 попадаем на 192.168.1.10 :). Единственное что не очень бы хотелось - чтобы 192.168.1.10 видела подсеть 10.1......

P.S. ip_forward включен :).
Первоначально правила были такие
$IPT -t nat -A PREROUTING --dst 10.1.0.1 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.10
$IPT -P FORWARD ACCEPT - на всякий случай, чтобы не заморачиваться с неработающими парвилами

Но в этом случае пакеты только принимались, но не делалось никаких попыток отослать его обратно :)

[blockquote]Но в этом случае пакеты только принимались, но не делалось никаких попыток отослать его обратно :) [/blockquote]
Тоесть как это не делалось никаких попыток ? Получается что машина получала запрос, но не давала ответа ?

[blockquote]Соотв. указывая rdesktop 10.1.0.1 попадаем на 192.168.1.10 :). Единственное что не очень бы хотелось - чтобы 192.168.1.10 видела подсеть 10.1......[/blockquote]
В данном случае можно ограничиться возможностью ssh пробрасывать соединения
например так:
[color=green]ssh 10.1.0.1 -L 13389:192.168.1.10:3389[/color]
а дальше подключиться по RDP на адрес localhost:13389
Правда это не совсем удобно, но работает, как надо.

А если обойтись средствами IPTables, то можно попробовать следующее:
[color=green]
iptables -A PREROUTING -i ppp0 -p tcp -d 10.1.0.1 --dport 3389 -j DNAT --to-destination 192.168.1.10
iptables -A POSTROUTING -o eth0 -p tcp -d 192.168.1.10 --dport 3389 -j SNAT --to-source 192.168.1.11
[/color]
Сам не пробовал, но думаю будет работать.
<span class='smallblacktext'>[ Редактирование 14.01.2007 - 00:48:54 ]</span>

[quote=frug][blockquote]

[color=green]iptables -A PREROUTING -i ppp0 -p tcp -d 10.1.0.1 --dport 3389 -j DNAT --to-destination 192.168.1.10
iptables -A POSTROUTING -o eth0 -p tcp -d 192.168.1.10 --dport 3389 -j SNAT --to-source 192.168.1.11[/color]

[/quote]
Спасибо. Вот так и заработало.

<span class='smallblacktext'>[ Редактирование 14.01.2007 - 10:34:29 ]</span>

Вот, кстати, товарищ из далёкой Финляндии обратил моё внимание на инструмент для перенаправления TCP соединений... и называется он прям как демон: [link=http://www.boutell.com/rinetd/]RINETD[/link]. Судя по всему - довольно простая в настройке программа.

Да и redir есть. Тоже работает. Задача была - обойтись средствами iptables.

Всё таки думаю "обойтись средствами IPTables", звучит не вполне корректно :)
как то снисходительно, корректней наверное будет "воспользоваться средствами IPTables" :)

### START скрипт проброса forward###
# created by Luter#
#!/bin/bash

DEBUG=1
iptabl="/sbin/iptables"
[ $DEBUG -eq 1 ] && iptabl="$iptabl -v"
LOCALNET=192.168.xxx.0/24 # локальная сеть

IF_EXT=eth1
IF_INT=eth0
IP_EXT=a.b.c.d # внешний IP

IP_INT=d.c.b.a # локальный IP
DIP=$3 # IP машины куда проброс порта
DPORT=$2 # порт на машине
SPORT=$1 # внешний порт смотрящий в мир

$iptabl -t nat -I PREROUTING --dst $IP_EXT -p tcp --dport $SPORT -j DNAT --to-destination $DIP:$DPORT
$iptabl -t nat -I POSTROUTING -p tcp --dst $DIP --dport $DPORT -j SNAT --to-source $IP_INT
$iptabl -t nat -I OUTPUT --dst $IP_EXT -p tcp --dport $SPORT -j DNAT --to-destination $DIP:$DPORT
$iptabl -I FORWARD -i eth1 --dst $DIP -j ACCEPT

IP_EXT=IP_INT # тоже самое делаем для внутренней сети для унифицирования ссылки
$iptabl -t nat -I PREROUTING --dst $IP_EXT -p tcp --dport $SPORT -j DNAT --to-destination $DIP:$DPORT
$iptabl -t nat -I POSTROUTING -p tcp --dst $DIP --dport $DPORT -j SNAT --to-source $IP_INT
$iptabl -t nat -I OUTPUT --dst $IP_EXT -p tcp --dport $SPORT -j DNAT --to-destination $DIP:$DPORT
$iptabl -I FORWARD -i eth0 --dst $DIP -j ACCEPT

### STOP скрипт проброса ###

*** синтаксис ***
forward $sport $dport $d_ip
где $sport порт смотрящий в мировую сеть
$dport порт на который идет переадресация
$d_ip IP хоста куда переадресуем

*** пример ***
forward 81 80 192.168.1.50

*** пробрасываем вебсервер на хост 192.168.1.50 порт 80
с внешнего IP с порта 81, т.к. на нашем внешнем хосте может крутиться веб сервер на 80 порту

и юзаем счастье

Luter, а о подпрограммах не знаешь ? :)

знаю тока писал на скорую руку
для локальной сети дописывал методом контрол+цэ -> контрол+вэ
для 2 сетевых я думаю не критично.....

если хочеш можешь переделать, потом сравним прирост производительности скрипта %))

А нафига тут вообще какие-то пробросы, забросы? Просто маршрутами разрулить не пробовал? Пропиши на машине, с которой собираешься коннектиться статику, что сетка 192.168.0.0/24, находится за дальним адресом туннеля, а сервер уже знает про обе сетки и про 10-ю и про 192-ю, и соединяйся наздоровье просто указывая 192 адрес. Ну а чтобы не попадали назад, из 192 в 10-ю, закрой уже правилом.

это хорошо, но если это шлюз интернета и правилами закрыта локалка.... то без проброса уже никак

[quote=Luter]это хорошо, но если это шлюз интернета и правилами закрыта локалка.... то без проброса уже никак[/quote]

Ну откройте правила, не пойму в чем разница, рулить ли проброс на сервере, либо разрешить из туннеля пользоваться локалкой?

парни, edge дело говорит - маршрутизация траффика всегда (почти всегда) эффективней ната (это еще в tcp/ip illustrated говорица). NAT`ом надо пользоваться только в том случае, когда маршрутить не представляется возможным (например на границе lan|wan)..