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

[tired]

ну у меня это работает так: пакет для которого есть запись свободно проходит как на allow, а вот пакет для которого записи нет при установленном deny_in просто выбрасывается, если же deny_in не установлен пакет проходит как на allow, не преобразуется, а просто проходит, но поскольку его ни кто не запрашивал он теряется, а я же хочу чтобы эти пакеты возвращались в файерволл и продолжали идти по правилам.

[Хостинг 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/

[ktulkhu]

а если при этом выставить one_pass=0?
я так понял, в этом случае пакет должен в любом случае будет вернуться в файрволл после ната, даже если при этом найдено совпадение в таблице ната?
мне логика работы с тем поведением one_pass, при котором происходит возврат к правилам файрволла кажется более логичным

[tired]

а если при этом выставить one_pass=0?
я так понял, в этом случае пакет должен в любом случае будет вернуться в файрволл после ната, даже если при этом найдено совпадение в таблице ната?
мне логика работы с тем поведением one_pass, при котором происходит возврат к правилам файрволла кажется более логичным

Вы правы наверно я остановлюсь на значении one_pass=0, но в таком случае после pipe также придётся дописывать разрешающие правила и это ещё немного запутает логику правил. дело в том что у меня довольно сложная сеть и при составлении правил я постоянно запутываюсь какие пакеты куда идут, приходится сидеть смотреть на правила и мысленно прокладывать путь пакетам из одной точки в другую. поэтому one_pass=1 уменьшает количество правил и упрощает логику.
p.s Моя точка зрения.

[ktulkhu]

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

Я на фрю только пришел, поэтому для меня после iptables тут вообще все необычно и запутанно . Поэтому я когда разбираюсь с правилами, я ненамеренно сравниваю логику работы iptables и логику работы ipfw.. Поведение с one_pass=0 мне кажется более правильным и логичным, возможно, потому, что так ipfw становится максимально приближен по логике к iptables. Но это мне. Вам, как фришнику, возможно гораздо более логично поведение, при котором после nat правила не передаются на дальнейшую обработку в файерволл, а сразу считаются allow. Тем более, когда это полезно для таких механизмов как pipe. Надо пользоваться по максимуму всеми предоставляемыми возможностями. Просто для меня это пока кажется путанным

[ktulkhu]

при котором после nat пакеты не передаются на дальнейшую обработку в файерволл.. конечно не правила

[Leviafan]

Решил не создавать новую тему, т.к. почти на 100% уверен что проблема в IPFW
Вообщем пров раздает инет по VPN. ПОднял я клиент на фряхе, работает инет.
Иду дальше... Подключаю ноут к серваку, прописываю IP сеть работает, инет не работает. Ну естественно ведь у меня нету правила на divert от\на интерфейс ng0. Но что туда прописать не могу понять.
Вот конфиг моего фаера (копипастил и настраивал по мануалу на данном ресурсе)

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

#!/bin/sh
FwCMD="/sbin/ipfw"
LanOut="vr0"            # внешний интерфейс
LanIn="rl0"            # внутренний интерфейс
IpOut="10.10.3.210" # внешний IP адрес машины
IpIn="10.10.100.1"   # внутренний IP машины
NetMask="24"            
NetIn="10.10.100.0"    # Внутренняя сеть
${FwCMD} -f flush
${FwCMD} add check-state
${FwCMD} add divert natd ip from ${NetIn}/${NetMask} to any out via ${LanOut}
${FwCMD} add divert natd ip from any to ${IpOut} any via ${LanOut}
#${fwcmd} add pass udp from any to any 53
#${fwcmd} add pass udp from any 53 to any 
${FwCMD} add allow ip from any to any

Вообщем обобщаю вопрос: как реализовать раздачу инета для компов подключенных по интерфейсу rl0 ? а именно какое правило на диверт прописать.

[ktulkhu]

Решил не создавать новую тему, т.к. почти на 100% уверен что проблема в IPFW

а ядро собрано с поддержкой divert?
а режим маршрутизации включен?

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

gateway_enable="YES"

а файерволл включен?

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

firewall_enable="YES"

а natd включен?

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

natd_enable="YES"

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

natd_interface="vr0"

а на вот эту строчку не поругалось при запуске?

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

${FwCMD} add divert natd ip from any to ${IpOut} any via ${LanOut}

и зачем там впереди планеты всей у вас

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

${FwCMD} add check-state

?
если вы его не используете..

[vadim64]

В FreeBSD 8.1 поломали sysctl one_pass, поэтому для того чтобы трафик после ната уходил в интернет надо такую фигню ставить. Так как нат запущен с deny_in то из интернета ничего лишнего не прилетит.

Актуально?

[Tommy]

Напишите в статье что во фря 8.1 сломали one_pass 1
два дня пытался понять почему не работает.
а вот с allow ip from any to any рабоатет.

[Tommy]

Блять нашел. но в самом низу. наверх надо

[pom]

Почему может не работать redirect_port ?
Все работает, ipfw nat работает, ipfw nat 1 show выводит адекватный результат, а порты не перебрасываются, ответа на них нет.
В какую сторону копать?
И кстати, в статье нет примера для ограничения доступа к перебрасываемым портам, при установке ограничений как для natd на порты вообще никого не пускает.

[ADRE]

Почему может не работать redirect_port ?
Все работает, ipfw nat работает, ipfw nat 1 show выводит адекватный результат, а порты не перебрасываются, ответа на них нет.
В какую сторону копать?
И кстати, в статье нет примера для ограничения доступа к перебрасываемым портам, при установке ограничений как для natd на порты вообще никого не пускает.

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

[densan]

Подскажите как в настройках ната в redirect_port в remoteIP указать таблицу?

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

        ${fw} nat 1 config log if $oif reset same_ports deny_in redirect_port tcp 192.168.0.5:22 22 xxx.xxx.xxx.xxx

т.е. в описании ната вместо xxx.xxx.xxx.xxx указать несколько адресов

нужно дать доступ по ssh с нескольких внешних ип.

[terminus]

что-то я сильно сомневаюсь что здесь где-то можно прицепить table(1).
Не проще завести перед натом отдельное правило разрешаюшее доступ таблице и запрещающее всем другим?

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

ipfw add 100 allow tcp from table(1) to me 22 in
ipfw add 200 deny tcp from any to me 22 in
ipfw add 300 nat 1 all from any to any via $oif

[densan]

Спасибо, так и сделал.
Возник один вопрос, прошу помощи в составлении правил для ipfw. Freebsd 8.1
В роутере 2 сетевых: одна подключена к провайдеру, вторая в свою локальную сеть (192.168.0.x). Аналог примера 1 в статье.
rc.conf

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

gateway_enable="YES"
ifconfig_vr0="inet xxx.xxx.xxx.xxx  netmask 255.255.255.252 -rxcsum"
ifconfig_sk0="inet 192.168.0.1  netmask 255.255.255.0"
defaultrouter="yyy.yyy.yyy.yyy"
hostname="gate.firma.local"

firewall_enable="YES"
firewall_logging="YES"
firewall_script="/etc/firewall4"

ядро собрано с опциями

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

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=50
options         IPFIREWALL_NAT
options         IPFIREWALL_FORWARD
options         LIBALIAS
options         ROUTETABLES=2
options         DUMMYNET
options         HZ="1000"

правила

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

#!/bin/sh

fw="/sbin/ipfw -q"
fwadd="/sbin/ipfw -q add"
oif="vr0"
iif="sk0"
oip="xxx.xxx.xxx.xxx"
iip="192.168.0.1"
        ${fw} -f flush
        ${fw} -f pipe flush
        ${fw} -f queue flush
# allow SSH
        ${fw} -f table 0 flush
        ${fw} table 0 add 123.123.123
        ${fw} table 0 add 456.456.456
# allow www table
        ${fw} -f table 1 flush
        ${fw} table 1 add 789.789.789
# разрешаем все через интерфейс локальной сети
        ${fwadd} 10 allow ip from any to any via $iif
# трафик через локальный интерфейс lo0
        ${fwadd} 100 allow ip from any to any via lo0
        ${fwadd} 200 deny ip from any to 127.0.0.0/8
        ${fwadd} 300 deny ip from 127.0.0.0/8 to any
# боимся непонятного
        ${fwadd} 1050 deny ip from any to 192.168.0.0/16 in recv $oif
        ${fwadd} 1060 deny ip from 192.168.0.0/16 to any in recv $oif
        ${fwadd} 1070 deny ip from any to 172.16.0.0/12 in recv $oif
        ${fwadd} 1080 deny ip from 172.16.0.0/12 to any in recv $oif
        ${fwadd} 1090 deny ip from any to 10.0.0.0/8 in recv $oif
        ${fwadd} 10100 deny ip from 10.0.0.0/8 to any in recv $oif
        ${fwadd} 10110 deny ip from any to 169.254.0.0/16 in recv $oif
# - разрешаем SSH доступ к серверу, но только для хостов, внесенных в table(0)
        ${fwadd} 20010 allow log tcp from table\(0\) to ${oip} 22 in via ${oif}
# - разрешаем WWW доступ к серверу, но только для хостов, внесенных в table(1)
        ${fwadd} 20020 allow log tcp from table\(1\) to ${oip} 80 in via ${oif}
# даем доступ к 23 порту, который будет пробрасываться только с ИП из таблицы 0
        ${fwadd} 20030 skipto 20510 log tcp from table\(0\) to ${oip} 23 in via ${oif}
        ${fwadd} 20050 deny log tcp from any to ${oip} 23 in via ${oif}
# настройка ната с пробросом SSH
        ${fw} nat 1 config log if $oif reset same_ports deny_in redirect_port tcp 192.168.0.5:22 23
# заварачиваем все что проходит через внешний интерфейс в нат
        ${fwadd} 20510 nat 1 ip from any to any via $oif
        ${fwadd} 20520 allow  all from any to any
# боимся непонятного
        ${fwadd} 65534 deny log all from any to any

Правила

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

ipfw show
00010  1166  147594 allow ip from any to any via sk0
00100  1678  115834 allow ip from any to any via lo0
00200     0       0 deny ip from any to 127.0.0.0/8
00300     0       0 deny ip from 127.0.0.0/8 to any
01050     0       0 deny ip from any to 192.168.0.0/16 in recv vr0
01060     0       0 deny ip from 192.168.0.0/16 to any in recv vr0
01070     0       0 deny ip from any to 172.16.0.0/12 in recv vr0
01080     0       0 deny ip from 172.16.0.0/12 to any in recv vr0
01090     0       0 deny ip from any to 10.0.0.0/8 in recv vr0
10100     0       0 deny ip from 10.0.0.0/8 to any in recv vr0
10110     0       0 deny ip from any to 169.254.0.0/16 in recv vr0
20010     0       0 allow log logamount 50 tcp from table(0) to xxx.xxx.xxx.xxx dst-port 22 in via vr0
20020     0       0 allow log logamount 50 tcp from table(1) to xxx.xxx.xxx.xxx dst-port 80 in via vr0
20030     0       0 skipto 20510 log logamount 50 tcp from table(0) to xxx.xxx.xxx.xxx dst-port 23 in via vr0
20050     0       0 deny log logamount 50 tcp from any to xxx.xxx.xxx.xxx dst-port 23 in via vr0
20510  4582  780333 nat 1 ip from any to any via vr0
20520 11478 1687931 allow ip from any to any
65534     0       0 deny log logamount 50 ip from any to any
65535     0       0 deny ip from any to any

добавил еще одну сетевую для другой локальной сети, для которой нужно раздавать интернет
в rc.conf добавил

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

ifconfig_vr1="inet 192.168.3.1  netmask 255.255.255.0"

в правилах ничего не менял.
Работает: из своей локальной сети не видно другую локальную сеть и обратно, в другую локальную сеть раздается интернет.

Не могу понять:
1. почему раздается интернет в другую локальную сеть.
2. как разрешить трафик между локальными сетями.

[terminus]

1. почему раздается интернет в другую локальную сеть.

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

20520 11478 1687931 allow ip from any to any

2. как разрешить трафик между локальными сетями.

все уже должно быть - проверяйте пингом

так красивее будет:

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

# разрешаем все через интерфейсы локальной сети
        ${fwadd} 10 allow ip from any to any via $iif
        ${fwadd} 11 allow ip from any to any via vr1

[densan]

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

[Batonius]

Автору огромное спасибо за статью. Но возник вопрос.

Делаю распределение трафика по примеру 5 (за исключением труб - они пока не нужны) и для локальной сети все работает отлично. Если НАТить, то запросы уходят-приходят через оба внешние интерфейсы поочередно.
Но как быть с самим роутером и распределением трафика от него? На нем стоит Squid и при попытке завести в него пользователей весь трафик идет через шлюз по умолчанию. По аналогии попытался добавить такую конструкцию:

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

${fwcmd} add 1100 prob 0.5 skipto 1160 log tcp from me to any 80,8080 out setup
${fwcmd} add 1140 setfib 0 log tcp from me to any 80,8080 out
${fwcmd} add 1150 allow log tcp from me to any 80,8080 out ${ks}
${fwcmd} add 1160 setfib 1 log tcp from me to any 80,8080 out
${fwcmd} add 1170 allow log tcp from me to any 80,8080 out ${ks}

Не работает. Получается какая-то ерунда, которую даже описать трудно.

Похоже, я чего-то не догоняю. Подскажите, плз, куда копать.

[terminus]

Тут проблема - действие setfib работает только на проходе IN и повесить его мы можем только на трафик входящий из локальной сети. А трафик самого рутера это сразу же проход OUT и тут оно не срабатывает...

У nuclight'a было руководство как с помощью патчей заставить работать keep-state + fwd.
http://nuclight.livejournal.com/124348.html

2. Динамические правила и ipfw fwd; теги.

Приведенный в посте пример того, как на динамических правилах сделать аналог reply-to в pf, на самом деле, не работает. В исходниках был обнаружен запрет специально именно этого случая в мохнатом 2000 году из-за какой-то паники ядра на тех версиях. Что давно уже не актуально, но это, конечно же, поправить забыли. Патчится одной строчкой - открываете /sys/netinet/ip_fw2.c, находите слова case O_FORWARD_IP: (конкретный патч не приведу, зависит от версии системы). И вот там чуть ниже в строчке кусок

if (!q || dyn_dir == MATCH_FORWARD)

надо заменить на

if (sa->sin_port && (!q || dyn_dir == MATCH_FORWARD))

Еще, кстати, не стоит забывать, что все имеющиеся на пакетах теги, будь то метаинформация самой системы (от того же IPSEC и много чего еще) или явно навешенные теги ipfw/pf - существуют только внутри ядра. То есть, если вывести пакет из ядра через divert, они потеряются.

Это пока единственный вариант как сделать PBR для трафика самого рутера.

[Batonius]

Тут проблема - действие setfib работает только на проходе IN и повесить его мы можем только на трафик входящий из локальной сети. А трафик самого рутера это сразу же проход OUT и тут оно не срабатывает...

Вот оно! Все странности сразу становятся понятны. Было ощущение чего-то такого подобного.

У nuclight'a было руководство как с помощью патчей заставить работать keep-state + fwd.
http://nuclight.livejournal.com/124348.html

Спасибо за наводку. Не совсем удобно, конечно. Обновился и опять голову ломаешь, почему работает неправильно.
Попробую - отпишусь.

[ADRE]

А что не получиться заюзать: ${skip} all from me to any out via ${outif}
где skip=" skipto 60000" (допустим) далее fwd куда надо и ожидание запроса

[terminus]

Там вопрос в том, чтобы сделать динамическое PRB между несколькими подключениями на связке fwd + keep-state.

[icb]

Из статьи (про самый просто вариант)

Трафик дойдет до правила 1040 после чего выйдет из прохода IN фаервола, и попадет обратно в ip_input() где будет принято решение о том, что он предназначен не нам, а следовательно должен быть направлен в точку (4), в функцию ip_forward().

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

add 1040 allow ip from any to any via fxp0

Разве это правило говорит о том, что пакет предназначен не нам?
Получается, что к серверу даже по SSH не подключиться что ли?

[vadim64]

Из статьи (про самый просто вариант)

Трафик дойдет до правила 1040 после чего выйдет из прохода IN фаервола, и попадет обратно в ip_input() где будет принято решение о том, что он предназначен не нам, а следовательно должен быть направлен в точку (4), в функцию ip_forward().

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

add 1040 allow ip from any to any via fxp0

Разве это правило говорит о том, что пакет предназначен не нам?
Получается, что к серверу даже по SSH не подключиться что ли?

читайте внимательнее, этот текст относится к разделу примера под заглавием "Для сети 192.168.1.0/24:"

[icb]

этот текст относится к разделу примера под заглавием "Для сети 192.168.1.0/24:"

Я имею ввиду, что подключение к серверу по SSH в том числе и из сети 192.168.1.0/24