iptables и внутренняя сеть

[kinesis]

привет.
настраиваю шлюз для интернета.
1 интерфейс внешний с реальным IP, и 2 внутренних в разных подсетях.
Интернет раздается нормально.
Переадресацию портов настроил на внутренние сервера (ftp, www...), с наружи все вроде хорошо.
Но есть проблема с внутренней сетью при подключении на внешний интерфейс.
Внутренний веб-сервер 192.168.1.132:8080 снаружи как х.х.х.х:80
Как правильно написать правило чтоб пользователи из подсети 192.168.1.0/24 могли подключаться нормально на х.х.х.х:80 ?
Таких сервисов несколько, и ко всем из них я не могу подключиться изнутри.
Спасибо!

[kbu]

необходимы еще два правила вида:

/sbin/iptables -t nat -A POSTROUTING --dst $inet_ip -p tcp --dport 80 -j SNAT --to-source $lan_ip

/sbin/iptables -t nat -A OUTPUT --dst $inet_ip -p tcp --dport 80 -j DNAT --to-destination $http_ip

[kinesis]

спасибо, с этими двумя правилами я бьюсь сегодня целый день, и что-то не получается.
что есть lan_ip? это внутренний адрес шлюза?
что я еще упускаю?

[kbu]

привожу выдержку из мана по iptables скачанного с opennet.ru

(Нажмите, чтобы показать/скрыть)

Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в Интернет равным $EXT_BOX.

Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP

Пакет приходит на наш брандмауэр.

Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает его дальше, в другие цепочки.

Пакет передается на $HTTP_IP.

Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-умолчанию для HTTP сервера.

Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто бы пакет был сформирован на брандмауэре.

Пакет передается клиенту $EXT_BOX.

А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.

Пакет покидает $LAN_BOX.

Поступает на брандмауэр.

Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.

Пакет покидает брандмауэр и отправляется на HTTP сервер.

HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.

Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать "настоящий" ответ.

Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.

iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP
   
Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.

Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему, добавим правило:

iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
   
Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно возникать.