Подробное руководство по ipfw nat

[alx_nk]

Народ! Помогите не вывихнуть моСК окончательно. Я дурак или что-то вокруг не так. Вы так все далеко зашли в разборе ipfw-nat, что я со своим вопросом возможно мимо кассы, но надеюсь на помощь....
Итак,
есть некий шлюз на фре, выполняющий еще и дополнительные функции для сетки, ну там почту принять-отдать, про днс всем показать, ssh - в общем по-мелочи.
Вот стал я заменять natd на ipfw-nat и завяз, сократил скрипт запуска firewall'a до минимума, а все мимо.

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

${fw} -f flush
${fw} add allow ip from any to any via lo0 # Все что угодно через петлю
${fw} add allow ip from $lan_ip_range to $lan_ip_range via $lan_iface  # Все что угодно из локальной сети в нее же через внутренний интерфейс
${fw} add nat 1 ip from $lan_ip_range to any out via $inet_iface # Натить все что уходит из локальной сети наружу через внешний интерфейс
${fw} add nat 1 ip from any to $inet_ip in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   
${fw} nat 1 config ip $inet_ip # Конфигунация инстанса ната без излишеств(опции ничего не меняют)

${fw} add allow icmp from $inet_ip to any  out via $inet_iface # ICMP от шлюза - можно, ведь со шлюза может захотется попинговать или потрейсрутить 
${fw} add allow icmp from any to $inet_ip in via $inet_iface # ICMP для шлюза - можно, а вдруг нам ответят или тоже попингуют

${fw} add allow icmp from any to $lan_ip_range out via $lan_iface # ICMP от компьютеров в сети, там тоже люди любят пинговать все
${fw} add allow icmp from $lan_ip_range to any  in via $lan_iface # ICMP для компьютеров в сети, им тоже могут ответить

${fw} add deny ip from any to any # Все - больше ничего не надо

При таком наборе правил у компьютеров в сети все замечательно, а вот с шлюза пинги не проходят и сам он из вне не пингуется.
Если поставить "массовый заворот" в нат вида

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

${fw} add nat 1 ip from any to any via $inet_iface 

пинги от шлюза начинают идти, а он по прежнему не пингуется.

Вывод в моем понимании один, все входящие пакеты попадают, в любом раскладе, под правило "все в нат", и не находят там ничего приятного - записи в таблице ната для них нет и они очевидно дропятся. И если в первом случае это предположение прокатывает, то во втором у меня зреет вывод, что мысль о том, что пакеты могут быть адресованы и самому шлюзу в ipfw-nat не попала. А точнее мысль, что пакеты одного типа могут быть адресованы как самому шлюзу так и сетке за ним.

В общем, полейте меня грязью, считайте малограмотным ламером, но вытолкните меня из этого замкнутого круга.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Gamerman]

Перед натом разрешите пакеты to me. Тогда они будут попадать на шлюз.

PS. У вас пакет который приходит на внешний интерфейс шлюза не попадает ни в одно из правил, кроме последнего, которое все закрывает.

Думаю, что можно заменить

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

${fw} add nat 1 ip from any to $inet_ip in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   

на

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

${fw} add nat 1 ip from any to me in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   

[terminus]

У вас как сейчас выставлен

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

sysctl -a | grep one_pass

?

Начинайте свои эксперименты с этого конфига:

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

${fw} -f flush
${fw} add allow ip from any to any via lo0 
${fw} add deny ip from any to 127.0.0.0/8
${fw} add deny ip from 127.0.0.0/8 to any
${fw} add allow ip from any to any via $lan_iface
${fw} nat 1 config ip $inet_ip reset same_ports deny_in
${fw} add nat 1 ip from any to any via $inet_iface
${fw} add deny ip from any to any

Добейтесь чтобы при таком кофиге интернет работал как у самого рутера так и у клиентов в локальной сети за ним. Потом уже усложняйте. Посмотрите как настроена сетевая карта $inet_iface - если нат не работает попробуйте выключить TSO, rxcsum и txcsum на этой сетевухе (если они включены - см. ывывод ifconfig).

На пинги (ICMP) забейте - с пингами сложно...
Когда из интернета на рутер приходит пинг, то есть два варианта. Или мы ставим такое правило до ната:

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

${fw} add allow icmp from any to me via $inet_iface

тогда можно будет пинговать рутер, но icmp трафик не дойдет до nat и => не попадет на машины в локальной сети.

Или мы оставляем все как в примере сверху - тогда с интернета рутер пинговать нельзя, но icmp трафик нормально ходит (нормально ходит - значит то, что, как клиенты так и сам рутер будут получать icmp ответы на инициализированные ими icmp запросы.)

Дырки в нате для сервисов которые должны быть доступны из интернета прописывайте с помошью

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

redirect_port tcp $inet_ip:22 22

[alx_nk]

Перед натом разрешите пакеты to me. Тогда они будут попадать на шлюз.

PS. У вас пакет который приходит на внешний интерфейс шлюза не попадает ни в одно из правил, кроме последнего, которое все закрывает.

Думаю, что можно заменить

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

${fw} add nat 1 ip from any to $inet_ip in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   

на

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

${fw} add nat 1 ip from any to me in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   

Ключевое слово me трактуется как любой интерфейс принадлежащий данной машине.Правилу, которое Вы предлагаете изменить, соответствует любой ip пакет с destination ip установленному как внешний ip шлюза, и этот пакет попадет в шлюз, а точнее сразу в нат. Правило написанное Вами эквивалентно как моему, которое Вы исправляли, так и например правилу:

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

${fw} add nat 1 ip from any to  $lan_ip in via $inet_iface# Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном ВНУТРЕННЕГО IP

А пакет адресованный внутреннему ip на входе внешнего интерфейса не должен возникнуть.
IMHO

[alx_nk]

У вас как сейчас выставлен

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

sysctl -a | grep one_pass

?

в единицу, то бишь включен

Добейтесь чтобы при таком кофиге интернет работал как у самого рутера так и у клиентов в локальной сети за ним. Потом уже усложняйте. Посмотрите как настроена сетевая карта $inet_iface - если нат не работает попробуйте выключить TSO, rxcsum и txcsum на этой сетевухе (если они включены - см. ывывод ifconfig).

TCP соединения нормально начинают работать и у шлюза и у клиентской сети как только ВСЕ пакеты на внешнем интерфейсе направляются в NAT правилом:

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

${fw} add nat 1 ip from any to any via $inet_iface

вместо двух:

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

${fw} add nat 1 ip from $lan_ip_range to any out via $inet_iface 
${fw} add nat 1 ip from any to $inet_ip in via $inet_iface 

С точки зрения логики(правда моей ) они тоже выглядят премлимо.Кстати, спасибо Вам, это правило я в Вашей статье присмотрел. Но как я и писал раньше ситуация не в том, что "не работает совсем", а в том что не все работает как надо. Ведь правила написанные Вами здесь и приведенные в моем первом посте имеют немного отличий. Просто у меня они чуть четче ограничены. Где у меня "сетка через интерфейс" у Вас "все через интерфейс".

На пинги (ICMP) забейте - с пингами сложно...

Совсем забить нельзя, ведь ICMP это не только пинг...

Когда из интернета на рутер приходит пинг, то есть два варианта. Или мы ставим такое правило до ната:

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

${fw} add allow icmp from any to me via $inet_iface

тогда можно будет пинговать рутер, но icmp трафик не дойдет до nat и => не попадет на машины в локальной сети.
Или мы оставляем все как в примере сверху - тогда с интернета рутер пинговать нельзя, но icmp трафик нормально ходит (нормально ходит - значит то, что, как клиенты так и сам рутер будут получать icmp ответы на инициализированные ими icmp запросы.)

То есть именно так как я и предполагал, то что замечательно жило в NATD в IPFW-NAT не живет в принципе. Значит от вывиха могза меня уже спасли .

Дырки в нате для сервисов которые должны быть доступны из интернета прописывайте с помошью

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

redirect_port tcp $inet_ip:22 22

С учетом такого метода "открытия" сервиса теперь скрипт запуска firewall надо переписывать, а не адаптировать.
Я померил производительность ipfw-nat посылая через него на его внешний интерфейс из клиентской сети килобайтные ICMP пакеты (кстати пингом) и так же померил natd. Получилась задержка 0,600-0,640 ms против 0,650-0,700ms на пакет в пользу ipfw-nat. Конечно точность только оценочная, но заставляет подумать - а не попробовать ли PF

[Gamerman]

А пакет адресованный внутреннему ip на входе внешнего интерфейса не должен возникнуть.
IMHO

Правильно, по этому оно и не обрабатывалось никогда. То есть первое правило которое обрабатывалось было правило, которое все запрещало.

[alx_nk]

Правильно, по этому оно и не обрабатывалось никогда. То есть первое правило которое обрабатывалось было правило, которое все запрещало.

Вовсе нет. Правило

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

${fw} add nat 1 ip from any to $inet_ip in via $inet_iface 

запишем в цифрах, пусть $inet_ip - 1.2.3.4, $inet_iface - fxp1, $lan_ip - 192.168.0.1, $lan_ip_range - 192.168.0.0/24, $lan_iface - fxp0 получим:

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

${fw} add nat 1 ip from any to 1.2.3.4 in via fxp1 

Это правило идет четвертым по очереди, в него попадает пакет попавший на вход интерфейса fxp1, destination которого 1.2.3.4
По сути дела в случае применения того, что мы в данном случае называем NAT(он же PAT,NAT-OVERLOAD,IP-MASQUERADING), абсолютно все "нормальные" пакеты, попадающие на вход внешнего интерфейса(fxp1) всегда адресованы адресу 1.2.3.4. Только часть из них предназначена для внутренней сети, а часть для самого шлюза. Разделить, что кому, можно только проверив наличие записи в таблице трансляции адресов для этого пакета. Есть запись, меняем на нужный destination и отправляем по правилам, начиная со следующего(one_pass=1), нет записи - не меняем и снова в следующее правило той же очереди.

Следующим правилом подходящим под пакет, по прежнему, а точнее вновь, находящемуся на входе внешнего интерфейса(куда его должен вернуть механизм NAT) подходит правило

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

${fw} add allow icmp from any to $inet_ip in via $inet_iface

или в цифрах

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

${fw} add allow icmp from any to 1.2.3.4 in via fxp1

которое должно принять пакет;
Таким образом до deny все от-то всюду, пакет будет(точнее должен быть) обработан 2 раза.

Замена четко указанного ip 1.2.3.4 на me , даст ту же последовательность прохождения для "нормальных" пакетов. Но оно разрешит "не честные" пакеты, от сеток 127.0.0.0/8 и 192.168.0.0/24 на входe fxp1. Конечно если предварительно, до NAT, поставить запреты на такие пакеты - то и не страшно. Но смысла мало.
На практике получается, что пакет попавший а IPFW-NAT и не нашедший себе записи в таблице преобразования адресов умирает не выходя из NAT.
Ну и еще мелочь - та конфигурация, что я привел работает. Но не для обмена ICMP со шлюзом, а для обмена между интернетом и клиентской сетью;

Жуть сколько буковоков написал

[Gamerman]

Проблема была в том, что вы не описали значения конструкций типа $inet_ip. Соответственно я не верно их интерпретировал.

ЗЫ. С вашими мыслями я согласен

[Gamerman]

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

${fw} add nat 1 ip from any to $inet_ip in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   
...

${fw} add allow icmp from any to $inet_ip in via $inet_iface # ICMP для шлюза - можно, а вдруг нам ответят или тоже попингуют

Вам не кажется, что первое правило включает себя второе, по этому до второго очередь не дойдет?
При входе на сервер оно будет смотерть нат
Вот только почему icmp не сработает при нате - мне не известно.
Я не до конца понимаю алгоритм работы, когюда пакет приходит на НАТ и не находит таблицу соответствий. Что с ним тогда происходит?

На практике получается, что пакет попавший а IPFW-NAT и не нашедший себе записи в таблице преобразования адресов умирает не выходя из NAT.

Да уж...

[terminus]

Есть запись, меняем на нужный destination и отправляем по правилам, начиная со следующего(one_pass=1), нет записи - не меняем и снова в следующее правило той же очереди.

Есть запись, меняем на нужный destination и разрешаем - allow. пакет выходит из ipfw (one_pass=1), нет записи - не меняем и запрещаем - deny (deny_in).

Когда one_pass=0 то тогда уже после выхода из ната трафик пойдет по остальным правилам до конца.
Если выключить deny_in в настройках ната то он станет создавать новые записи в таблице ната если таких там нет.

[alx_nk]

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

${fw} add nat 1 ip from any to $inet_ip in via $inet_iface # Разнатить все что пришло откуда угодно на вход внешнего интерфейса с дистанейшеном внешнего ip   
...

${fw} add allow icmp from any to $inet_ip in via $inet_iface # ICMP для шлюза - можно, а вдруг нам ответят или тоже попингуют

Вам не кажется, что первое правило включает себя второе, по этому до второго очередь не дойдет?

Если я правильно понял, по выходу из NAT пакет должен попасть в тот же поток(вход или выход) но на следующее правило, таким образом, если пакет адресован самому шлюзу, то в NAT изменений в пакете не произведено и он очень даже попадает под второе правило.

Вот только почему icmp не сработает при нате - мне не известно.
Я не до конца понимаю алгоритм работы, когюда пакет приходит на НАТ и не находит таблицу соответствий. Что с ним тогда происходит?

Мне кажется не срабатывает IPFW-NAT, не возвращая не обработанные пакеты. Ведь конструкция:

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

${fw} add divert natd ip from $lan_ip_range to any out via $inet_iface
${fw} add divert natd ip from any to $iniet_ip in via $inet_iface
${fw} add allow ip from $inet_ip to any out via $inet_iface
${fw} add allow ip from any to $local_ip_range in via $inet_iface

работает.
Сразу оговорюсь правила стоящие после divert на поведение IPFW-NAT не влияют, ни теоретически, ни практически - проверил.
В общем шиза!

[terminus]

В общем шиза!

Небольшой тест на внимательность для самопроверки:

- На что влияет установка sysctl one_pass?
- Как работает директива deny_in в настройках ipfw nat?

Можете ответить?

[Gamerman]

Вопрос к автору руководства по ipfw nat.
Может я невнимательно читаю пример 1, а может там и нет такого, но хотелось бы получить описание, как себя будут вести пакеты, которые будут адресованы с инета на шлюз порт 80.
Если в руководстве этого действительно нету, то может стоит добавить этот случай?

[terminus]

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

add 1040 allow ip from any to any via fxp0

nat 1 config log ip 1.2.3.4 reset same_ports deny_in redirect_port tcp 1.2.3.4:6881 6881 redirect_port udp 1.2.3.4:4444 4444 redirect_port tcp 192.168.1.24:25 25

add 10130 nat 1 ip from any to any via em0

add 65534 deny all from any to any

Он дойдет до 10130, попадет в нат, в нате нет готового правила демаскировки (дырки) для 1.2.3.4:80, а кроме того включен параметр deny_in - следовательно пакет не может быть принят и для него не будет динамически создаваться новая дырка. Пакет будет убит. Если было бы еще одно правило redirect_port tcp 1.2.3.4:80 80 то пакет был бы принят и вышел бы из фаервола.

Если бы небыло deny_in то в таблице была бы создана новая дырка вида 1.2.3.4:80 <-> удаленныйIP:порт, пакет был бы принят и вышел бы из фаервола.

Если бы кроме отсутвия deny_in был бы так же выключен и one_pass то пакет бы вышел из nat и прошел бы по правилам ipfw до 65534 где был бы убит.

[Gamerman]

Спасибо.
У меня не было deny_in, по этому у меня на роутере все работает.

Если бы кроме отсутвия deny_in был бы так же выключен и one_pass то пакет бы вышел из nat и прошел бы по правилам ipfw до 65534 где был бы убит.

"прошел бы по правилам ipfw " начиная с начала или с номера после 10130?

[terminus_]

со следующего по номеру после 10130.

[alx_nk]

Есть запись, меняем на нужный destination и отправляем по правилам, начиная со следующего(one_pass=1), нет записи - не меняем и снова в следующее правило той же очереди.

Есть запись, меняем на нужный destination и разрешаем - allow. пакет выходит из ipfw (one_pass=1), нет записи - не меняем и запрещаем - deny (deny_in).

Когда one_pass=0 то тогда уже после выхода из ната трафик пойдет по остальным правилам до конца.
Если выключить deny_in в настройках ната то он станет создавать новые записи в таблице ната если таких там нет.

Немного поспорю, для порядка . Пакет после разрешения в нате выйдет из очереди только при one_pass=1, так написано в мане. Не знаю врут или не договаривают , но загоняя в журнал все пакеты можно увидеть, как после ната на внешнем интерфейсе он действительно прекращает движение по правилам, но только для внешнего интерфейса.Пакет всплывает на выходе внутреннего интрефейса, и только пройдя правила там покидает ipfw совсем . А вот если поставить 0, то после выхода из ната пакет действительно запускается в путь по правилам еще на внешнем интерфейсе.
Что касается deny_in - это похоже на запрет движения пакетов попавших в нат и не найденых в таблице преобразования адресов. Собственно запрет входящих соединений к шлюзу. Этакая черная дыра через нат Здесь, кстати УРА и спасибо. Все работает правильно если не ставить deny_in. И как уже многие писали перезапустить систему. Правила, те что писал в первый раз отлично справляются с задачей.
Пакеты идут и на сквозь и от шлюза и к нему. Конечно в логах видно сколько хлама в нат дополнительно летит, но здесь весь вопрос в наборе правил и надежности ядра(но мы-то во Фришке не сомневаемся )

Кроме того, подвергнуть сомнению Вашу трактовку deny_in. Почему без него должны создаваться новые записи в таблице преобразования адресов, если "натенье" (создание записей) происходит на выходе из интерфейса, "разначивание" на входе.Без включения опции reverse это не произойдет.

[terminus]

Немного поспорю, для порядка . Пакет после разрешения в нате выйдет из очереди только при one_pass=1, так написано в мане. Не знаю врут или не договаривают , но загоняя в журнал все пакеты можно увидеть, как после ната на внешнем интерфейсе он действительно прекращает движение по правилам, но только для внешнего интерфейса.Пакет всплывает на выходе внутреннего интрефейса, и только пройдя правила там покидает ipfw совсем . А вот если поставить 0, то после выхода из ната пакет действительно запускается в путь по правилам еще на внешнем интерфейсе.

Два интерфеса - значит два прохода. Проход IN на внешнем интерфейсе и проход OUT на внутреннем. Пакет пришедший из интернета, выйдя из ната при one_pass=1, попадет в проход OUT на внутреннем интерфейсе. Никаких чудес нет...

Что касается deny_in - это похоже на запрет движения пакетов попавших в нат и не найденых в таблице преобразования адресов. Собственно запрет входящих соединений к шлюзу. Этакая черная дыра через нат...

Кроме того, подвергнуть сомнению Вашу трактовку deny_in. Почему без него должны создаваться новые записи в таблице преобразования адресов, если "натенье" (создание записей) происходит на выходе из интерфейса, "разначивание" на входе.Без включения опции reverse это не произойдет.

Читайте ман по ipfw nat и по natd - я его в статье объеденил и перевел на русский. Там про deny_in написано:

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

     deny_in

        Параметр предписывает запрет пропускать через nat входящие пакеты для
	которых нет совпадения во внутренней таблице активных соединений,
	или же нет совпадения с другими правил демаскировки.

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

создание записи в таблице соответсвие не есть какая-то эксклюзивная операция доступная только для трафика уходящего в интернет и принятого натом из прохода OUT. Как видите предусмотрено, что новые записи могут создаваться динамически даже просто для неизвестного трафика.

Работа в режиме без deny_in равносильна открытому фаерволу - клиентская сеть 192.168.1.0 защишена натом, но внешний интерфейс самого ната нет - он принимает весь входящий трафик. Вам действительно нужен такой режим работы? Будете потом на отдельных правилах ipfw дополнительно прописывать запреты?

[alx_nk]

Два интерфеса - значит два прохода. Проход IN на внешнем интерфейсе и проход OUT на внутреннем. Пакет пришедший из интернета, выйдя из ната при one_pass=1, попадет в проход OUT на внутреннем интерфейсе. Никаких чудес нет...

Да, никаких чудес, я просто отметил, что приняв пакет в нат на входе мы не теряем возможности оперировать им на выходе;

Читайте ман по ipfw nat и по natd - я его в статье объеденил и перевел на русский. Там про deny_in написано:

В мане нет решений, есть лишь описание функционала, порой не полное. Но с deny_in оно верно в мане по IPFW
deny_in
Deny any incoming connection from outside world.
Запрет любых входящих соединение из внешнего мира.
Т.е. что в нат попало - то пропало, если его нельзя разнатить. Подход понятен, хотя нельзя считать его лучшим.

Работа в режиме без deny_in равносильна открытому фаерволу - клиентская сеть 192.168.1.0 защишена натом, но внешний интерфейс самого ната нет - он принимает весь входящий трафик. Вам действительно нужен такой режим работы? Будете потом на отдельных правилах ipfw дополнительно прописывать запреты?

Здесь вполне согласен - дуршлаг вместо фаервола мне не нужен, но во-первых deny all from any to any в конце скрипта очень не плохая мера, во-вторых, кроме нее любой нормальные админ порубит входящие из интернета пакеты с сорсом от частных сетей, в порядке стандартных мер по борьбе со спуффингом.Ну а если в добавок использовать опцию unreg_only можно вообще спать спокойно.
Но главное спасибо, многое прояснилось - как говорится в споре рождается истина

[vendigolio]

Подскажите, пожалуйста, чайнику.
Стандартная для многих ситуация. Провайдер предоставляет доступ к ресурсам локальной сети и к интернету через pppoe. Есть гейтвей с freebsd 7.2. Как сделать, чтобы пользователи домашней локалки могли одновременно пользоваться интернетом и ресурсами локальной сети провайдера? Т.е. пакеты из домашней сети должны натится и в локалку провайдера и в туннель интернета?
Спасибо!

[bwdude]

уже спрашивал, но не нашел ответа. Никак не получается.
есть шлюз:
10.0.0.1 - внутренний адрес;
1.2.3.4 - внешний адрес;
10.0.0.202 - адрес сервера который нужно открыть по порту 5222 (Jabber)
делаю следующее:
${FwCMD} nat 123 config redirect_port tcp 10.0.0.202:5222 1.2.3.4:5222
${FwCMD} add nat 123 log ip from any to 1.2.3.4 5222
${FwCMD} add nat 123 log tcp from 10.0.0.202 5222,5223 to any

При доступе к этой системе из интернет всё работает. А вот не работает в случае доступа из локальной сети к адресу 1.2.3.4
т.е. на ноуте (10.0.0.20) настроен Jabber клиент на адрес 1.2.3.4
Снаружи работает, а изнутри приходится адрес сервера менять на 10.0.0.202
Это частный случай. Jabber это не единственное что должно работать таким образом.
tcpdump при доступе из локалки выдает лишь как пакет с компа приходит на шлюз, а со шлюза на комп и так три раза.
Так вот как бы так сделать чтобы ip адрес в клиенте менять не приходилось.
Заранее огромное спасибо за варианты.

[BAV_Lug]

Сразу скажу - ОГРОМНОЕ спасибо за статью. Многие вещи стали понятней.
Прочитал статью и решил по ее мотивам переписать себе фаер.
Итак дано
Система FreeBSD 7.0
На машине крутиться почта, локальный ДНС + клетка с веб-сервером + она же выступает шлюзом в инет для юзеров.
Интерфейсы:
1. Внешний

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

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1460
        inet *.*.*.177 --> *.*.*.56 netmask 0xffffffff

2. Внутренний

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

re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:1b:fc:6e:b2:76
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        inet 192.168.0.13 netmask 0xffffffff broadcast 192.168.0.13
        inet 192.168.200.1 netmask 0xffffff00 broadcast 192.168.200.255

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

net.inet.ip.fw.one_pass=0

Вот собственно текст фаера для моего случая

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

#!/bin/sh

FwCMD="/sbin/ipfw -q "

LanOut_data="ng0"
IpOut_data="*.*.*.177"

${FwCMD} -f flush
${FwCMD} pipe flush


${FwCMD} add 100 allow ip from any to any via lo0
${FwCMD} add 200 deny ip from any to 127.0.0.0/8
${FwCMD} add 300 deny ip from 127.0.0.0/8 to any

#

${FwCMD} add 1010 deny ip from any to 192.168.0.0/16 in recv ${LanOut_data}
${FwCMD} add 1020 deny ip from 192.168.0.0/16 to any in recv ${LanOut_data}
${FwCMD} add 1030 deny ip from any to 172.16.0.0/12 in recv ${LanOut_data}
${FwCMD} add 1040 deny ip from 172.16.0.0/12 to any in recv ${LanOut_data}
${FwCMD} add 1050 deny ip from any to 10.0.0.0/8 in recv ${LanOut_data}
${FwCMD} add 1060 deny ip from 10.0.0.0/8 to any in recv ${LanOut_data}
${FwCMD} add 1070 deny ip from any to 169.254.0.0/16 in recv ${LanOut_data}
${FwCMD} add 1080 deny ip from 169.254.0.0/16 to any in recv ${LanOut_data}


#smtp.teleportsv.net
${FwCMD} add 1510 skipto 3000 ip from 192.168.0.0/16 to 193.41.48.230 25 via ${LanOut_data}
#mp.top-kniga.ru
${FwCMD} add 1520 skipto 3000 ip from 192.168.0.0/16 to 82.138.50.195 25 via ${LanOut_data}
#mx0.sovamnet.com
${FwCMD} add 1530 skipto 3000 ip from 192.168.0.0/16 to 80.249.226.24 25 via ${LanOut_data}
# deny 25
${FwCMD} add 1550 deny ip from 192.168.0.0/16 to any 25 via ${LanOut_data}

# Probros 80-go porta na 192.168.0.13 dlja vnutrennej setki
${FwCMD} add 2010 fwd 192.168.0.13,80 tcp from 192.168.0.0/16 to 192.168.0.1 80

# Probros 21-go porta na 192.168.0.13 dlja vnutrennej setki
${FwCMD} add 2020 fwd 192.168.0.13,21 tcp from 192.168.0.0/16 to 192.168.0.1 21

# Probros 3307-go porta na 192.168.0.13 dlja vnutrennej setki
${FwCMD} add 2030 fwd 192.168.0.13,3307 tcp from 192.168.0.0/16 to 192.168.0.1 3307

#
#
#
${FwCMD} nat 1 config log if ${LanOut_data} reset same_ports deny_in \
 redirect_port tcp 192.168.0.13:80 80 \
 redirect_port tcp 192.168.0.13:21 21 \
 redirect_port tcp ${IpOut_data}:25 25 \
 redirect_port tcp ${IpOut_data}:22 22 \
 redirect_port tcp ${IpOut_data}:110 110 \
 redirect_port tcp ${IpOut_data}:143 143 \
 redirect_port tcp ${IpOut_data}:81 81


# Speed
${FwCMD} pipe 1 config bw 2000Kbit/s queue 60 gred 0.002/10/30/0.1
${FwCMD} queue 1 config pipe 1 mask src-ip 0xffffffff queue 60 gred 0.002/10/30/0.1
${FwCMD} pipe 2 config bw 2000Kbit/s queue 60 gred 0.002/10/30/0.1
${FwCMD} queue 2 config pipe 2 mask src-ip 0xffffffff queue 60 gred 0.002/10/30/0.1

#Glavbuh - пускаем мимо трубы (прошлый раз когда я пытался загнать весь траф в трубу, гребаный клиент-банк отказывался работать)
${FwCMD} add 2999 skipto 3010 ip from 192.168.0.102 to any via ${LanOut_data}

${FwCMD} add 3000 queue 1 ip from any to any out xmit ${LanOut_data}
${FwCMD} add 3005 queue 2 ip from any to any in recv ${LanOut_data}

${FwCMD} add 3010 nat 1 ip from any to any via ${LanOut_data}

${FwCMD} add 10000 allow ip from any to any via ${LanIn}
#
${FwCMD} add 65534 allow all from any to any

По критикуйте плз. Особенно меня смущает последнее правило.
Да еще если бы кто объяснил про параметры труб (а то в инете ничего внятного не нашлось).

[FilosofBeer]

По примеру 6 все работает.
Осталось только запретить всем инет, а разрешить его только избранным, и то с ограничением по скорости в 16 Кб.
Что бы работала Гарена, Торент, Интернет, Аська, МаилАгент, и все остальное.
Сетевые vr0 - локалка, vr1 - на инет.
Вот ipfw:
add 1040 allow ip from any to any via vr0

add 1070 deny ip from any to 172.16.0.0/12 in recv vr1
add 1080 deny ip from 172.16.0.0/12 to any in recv vr1
add 1090 deny ip from any to 10.0.0.0/8 in recv vr1
add 10100 deny ip from 10.0.0.0/8 to any in recv vr1
add 10110 deny ip from any to 169.254.0.0/16 in recv vr1
add 10120 deny ip from 169.254.0.0/16 to any in recv vr1

nat 1 config if vr1 reset same_ports deny_in redirect_port tcp 192.168.1.3:6881
6881 redirect_port udp 192.168.1.3:4444 4444

add 10130 nat 1 tcp from any to any out xmit vr1 limit src-addr 80
add 10140 nat 1 ip from any to any out xmit vr1

add 10150 nat 1 ip from any to any in recv vr1

add 65534 deny all from any to any

[terminus]

Ну йохаиды! Там же все просто:

/etc/sysctl.conf

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

net.inet.ip.fw.one_pass=0

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

table 1 add  192.168.1.3/32
table 1 add  192.168.1.25/32
table 1 add  192.168.1.26/32

pipe 1 config bw 16Kbit/s mask src-ip 0xffffffff
pipe 2 config bw 16Kbit/s mask dst-ip 0xffffffff

add 1000 allow ip from table(1) to any via vr0
add 1001 allow ip from any to table(1) via vr0

add 1040 deny ip from any to any via vr0

add 1070 deny ip from any to 172.16.0.0/12 in recv vr1
add 1080 deny ip from 172.16.0.0/12 to any in recv vr1
add 1090 deny ip from any to 10.0.0.0/8 in recv vr1
add 10100 deny ip from 10.0.0.0/8 to any in recv vr1
add 10110 deny ip from any to 169.254.0.0/16 in recv vr1
add 10120 deny ip from 169.254.0.0/16 to any in recv vr1

nat 1 config if vr1 reset same_ports deny_in redirect_port tcp 192.168.1.3:6881
6881 redirect_port udp 192.168.1.3:4444 4444

add 10129 pipe 1 ip from any to any out xmit vr1
add 10130 nat 1 tcp from any to any out xmit vr1 limit src-addr 80
add 10131 allow all from any to any out xmit vr1

add 10140 nat 1 ip from any to any out xmit vr1

add 10150 nat 1 ip from any to any in recv vr1
add 10151 pipe 2 ip from any to any in recv vr1

add 10160 allow all from any to any

add 65534 deny all from any to any

[Гость]

Странно, но это не работает. ((