port mapping outgoing ipfw

FreeBSD, NetBSD, OpenBSD, DragonFly и т. д.

Модератор: arachnid

Balace
Сообщения: 3
ОС: FreeBSD 8.4

port mapping outgoing ipfw

Сообщение Balace »

Доброе время суток.
есть сервер FreeBSD ipfw+natd
Настроил nat порт с инета в локалку 213.23.23.23:443 -> 10.10.1.251:443
если заходить с мира на 213.23.23.23:443 проброс работает и сервис отдает нужную инфу с сервера 10.10.1.251:443
но если с локальной сети например с 10.10.1.200 на 213.23.23.23:443 проброс не работает.
как это исправить?
Спасибо сказали:
Аватара пользователя
kisil
Сообщения: 204
ОС: Slackware 13,37-14

Re: port mapping outgoing ipfw

Сообщение kisil »

Как это реализовать на фряхе не подскажу, а вот для iptables есть такой пример, может натолкнёт на мысль

Код: Выделить всё

Рассмотрим простой пример. У нас есть WEB сервер и мы хотим разрешить доступ к нему из Интернет. Мы имеем только один реальный IP адрес, а WEB-сервер расположен в локальной сети. Реальный IP адрес $INET_IP назначен брандмауэру, HTTP сервер имеет локальный адрес $HTTP_IP и, наконец брандмауэр имеет локальный алрес $LAN_IP. Для начала добавим простое правило в цепочку PREROUTING таблицы nat:

iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP


В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш 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
Спасибо сказали:
Balace
Сообщения: 3
ОС: FreeBSD 8.4

Re: port mapping outgoing ipfw

Сообщение Balace »

iptabels я знаю как сделать
можно пример правил для
ipfw
Спасибо сказали:
Аватара пользователя
kisil
Сообщения: 204
ОС: Slackware 13,37-14

Re: port mapping outgoing ipfw

Сообщение kisil »

Я не работал с ipfw вообще потому и не напишу. Вот ещё нашёл

Вот что ещё нашёл

Код: Выделить всё

SNAT - natd -n interface
MASQ - natd -a address_alias
(правда если надо в пул натить, затрудняюсь ответить)
DNАT - natd -redirect-port
       natd -redirect-address
Спасибо сказали:
lazhu
Сообщения: 70
ОС: FreeBSD 9-STABLE / clang 3.3

Re: port mapping outgoing ipfw

Сообщение lazhu »

Balace писал(а):
05.01.2014 03:43
Доброе время суток.
есть сервер FreeBSD ipfw+natd
Настроил nat порт с инета в локалку 213.23.23.23:443 -> 10.10.1.251:443
если заходить с мира на 213.23.23.23:443 проброс работает и сервис отдает нужную инфу с сервера 10.10.1.251:443
но если с локальной сети например с 10.10.1.200 на 213.23.23.23:443 проброс не работает.
как это исправить?


Само собой не работает. Как реализовен мэппинг? from any to me in via ${ext_iface}? Так пакеты с локалки никогда под него не попадут.
Полный конфиг покажите. И зачем, кстати, с локалки запрашивать внешний IP?
Спасибо сказали:
Balace
Сообщения: 3
ОС: FreeBSD 8.4

Re: port mapping outgoing ipfw

Сообщение Balace »

Код: Выделить всё

${FwCMD} add divert natd ip from 10.10.15.0/23 to any out via ${inet}
${FwCMD} add divert natd ip from any to ${Ip} in via ${Inet}
${FwCMD} add divert natd ip from any to ${Ip2} in via ${inet}
Спасибо сказали:
lazhu
Сообщения: 70
ОС: FreeBSD 9-STABLE / clang 3.3

Re: port mapping outgoing ipfw

Сообщение lazhu »

и где тут мэппинг порта?
покажите полностью конфиг или вывод

Код: Выделить всё

ipfw -a list

Спасибо сказали:
Аватара пользователя
skeletor
Сообщения: 1224

Re: port mapping outgoing ipfw

Сообщение skeletor »

Для таких целей лучше использовать redir, так как из локалки проброс не работает.
Спасибо сказали: