https://opennet.ru/openforum/vsluhforumID10/5457.html Добрый день.Начинаю изучать FreeBSD. Пытаюсь разобраться с принципами работы NAT, изучал схему прохождения пакета по стеку ipfw, если для самой машины все более менее ясно, то вот то, как работают правила для NAT я никак понять не могу. Вводные данные:<br>------------------<br>rc.conf<br>ifconfig_re0="inet 192.168.30.254 netmask 255.255.255.0" #Локальная сеть<br>ifconfig_re1="DHCP" #Интернет от провайдера работает только при получении настроек по DHCP" #Интернет<br>firewall_enable="YES"<br>firewall_script="/etc/rules.fw"<br>firewall_nat_enable="YES"<br>gateway_enable="YES"<br><br>-----------------<br>/etc/sysctl.conf<br>net.inet.ip.fw.one_pass=1<br>-----------------<br><br>rules.fw<br>fwcmd="ipfw -q add"<br>ipfw -q -f flush<br><br>$fwcmd 00001 allow all from any to any via re0<br>ipfw nat 1 config log if re1 reset same_ports deny_in<br>$fwcmd 00100 nat 1 ip from any to any via re1<br>-----------------------------------------------------------<br><br> <br>предположим я хочу пропинговать сервер гугла 8.8.8.8 c хоста из внутренней подсети.<br><br>Пакет с машины https://opennet.ru/openforum/vsluhforumID10/5457.html#14 Mon, 07 May 2018 22:22:09 GMT &gt;&gt;[оверквотинг удален] <br><br>Ваш подход "запретить все исход кроме исключений", конечно, похвальный. И понятно непонимание. ИМХО, большинство примеров - по построению пограничного маршрутизатора. И поскольку обычно строят его в гражданской конторе, смысла нет настолько жёстко контролировать исходящий трафик, не с гостайной работаем. <br><br>На самой системе, отправляющей данные, как-то можно ограничить потоки данных от разных программ, но если на маршрутизатор пришёл пакет с запросом на 80 порт - всё равно его нужно отправлять. И 53 нужно отправлять. И 443. Вот, собственно, даже этого хватит, чтобы вынести любую информацию с внутренней сети. (первые пол-года, когда домашний ПК подключили к выделенке на постоянку, под рукой всегда жил скрипт, удаляющий дефолтный маршрут. Перестраховка от вирусов такая - типа - замечу левую активность - отрублю. Теперь прошло.) Ну а кроме того, есть протоколы, которым нужны целые диапазоны (FTP, например, skype тот же), и заниматься мазохизмом, настраивая маршрутизатор для всего этого https://opennet.ru/openforum/vsluhforumID10/5457.html#13 Mon, 07 May 2018 19:22:53 GMT &gt;[оверквотинг удален]<br>&gt; Для "клиент" и "простой" примеры ниже должны быть настроены соответствующим образом.<br>&gt; [/code] <br>&gt; разумеется, если у вас не тривиальный случай, не типичный, а "атипичный )))" <br>&gt; вам это не подойдёт, но как за основу вполне <br>&gt; по поводу one_pass <br>&gt; опять же обратимся к первоисточнику <br>&gt; info ipfw &#124; grep -A4 "net.inet.ip.fw.one_pass: 1" <br>&gt; [code]"если установлено ... после выполнения действия, пакет повторно возвращается в брандмауэр <br>&gt; и обрабатывается последующим правилом"[/code] <br>&gt; такие дела <br><br> Да нет, у меня все типично, не типичны после винд шлюзов логика работы шлюзов на базе ipfw.<br> Например мне не привычно, что в большинстве примеров весь исходящий трафик по умолчанию открыт, я хотел <br> запретить все исход кроме исключений. Решить эту задачу помогает функция skipto которая позволяет "перепрыгнуть" разрешенным правилам через deny all from any to any. В виндовых шлюзах такой логики работы никогда не встречал, поэтому очень для меня не привычно. Опять таки зар https://opennet.ru/openforum/vsluhforumID10/5457.html#12 Mon, 07 May 2018 16:15:30 GMT fix<br> https://opennet.ru/openforum/vsluhforumID10/5457.html#11 Mon, 07 May 2018 16:14:44 GMT &gt;[оверквотинг удален]<br>&gt; Вот такая схема мне очень понятна.<br>&gt; Только один момент остался немного не ясен, опция one-pass <br>&gt; Если она выключена, то пакет после маскирования в нат снова <br>&gt; попадает на цепочку ipfw и каким образом при <br>&gt; повторном прохождении этой цепочки он снова не попадает в правило что все <br>&gt; заруливается в nat, а если не попадает, то какое правило после <br>&gt; нат выпускает наружу его. Вот в моей цепочке правида pass <br>&gt; all from any to any нет в конце, между тем все <br>&gt; рабоает очень корректно, по умолчанию сам ipfw правилом 65355 ставит all <br>&gt; deny. Как же после нат пакет попадает во внешку?<br><br>все велосипеды давным-давно изобретены, как впрочем и само колесо<br>но практически каждый начинающий "гонщик" начинает со своего "самоката" )))<br><br>ну в смысле - есть готовые несложные примеры ipfw правил<br>самые типичные и распространённые смотрим в /etc/rc.firewall<br>[code]<br>Определите тип брандмауэра в /etc/rc.conf. Допустимые значения:<br>open - открытый, разрешает входящий трафик любому https://opennet.ru/openforum/vsluhforumID10/5457.html#10 Sun, 06 May 2018 14:27:43 GMT &gt;&gt; тут как я вижу в основном используется разрешено все и вся, <br>&gt;&gt; и лишь фильтрами убирается запрещенное.<br>&gt;&gt; Какой подход более правильнй?<br>&gt; почитайте про открытый и закрытый тип брандмауэра, <br>&gt; уверяю вас, будет весьма интересно и весьма познавательно <br>&gt; http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html <br><br> Я уже разобрался), мне было важно Понять саму схему расстановки правил и заруливания пакетов в nat.<br> <br> базово выбрал для себя такую схему<br> первыми идут правила pass from any to any на lo0 и Lan<br>потом<br>1) заворачиваю в нат все входящие пакеты с in recv $inet<br>2) разрешающие правила на выход вида<br> add 10 skipto 1000 udp from x.x.x.x to x.x.x.x 53 xmit $inet<br>3) Блокирующее правило для всего прочего трафика <br> add 20 deny all from any to any<br>4) заворачиваю в нат все исходящие пакеты<br> add 1000 nat 1 all from any to any OUT<br> Вот такая схема мне очень понятна. <br> Только один момент остался немного не ясен, опция one-pass<br> Если она выключена, то пакет после маскирования в нат с https://opennet.ru/openforum/vsluhforumID10/5457.html#9 Sun, 06 May 2018 12:24:41 GMT &gt; тут как я вижу в основном используется разрешено все и вся,<br>&gt; и лишь фильтрами убирается запрещенное.<br>&gt; Какой подход более правильнй?<br><br>почитайте про открытый и закрытый тип брандмауэра,<br>уверяю вас, будет весьма интересно и весьма познавательно<br><br>http://www.g0l.ru/blog/htmls/BSDA-course/apes01.html<br><br> https://opennet.ru/openforum/vsluhforumID10/5457.html#8 Sat, 05 May 2018 19:41:41 GMT Попробовал прописать эту схему в лист IPFW, делаю на внутреннем хосте резолв имени, мониторю на внешнем интерфейсе, вижу что пакет из сети попал в нат, прошел с внутреннего на внешний интерфейс, запрос отправился, система получила ответ, но ответ на внутренний интерфейс уже не попал, остался на внешнем, почему так произошло?<br> https://opennet.ru/openforum/vsluhforumID10/5457.html#7 Sat, 05 May 2018 09:46:13 GMT И еще, можно пояснить по правилам 3000.<br><br>Насколько я понимаю 3000 и 3001 запрещают системе отвечать на icmp запросы по подозрительным пингам, разхрешая только простое эхо, и только затем все остальные пакеты заруливаются на входящий нат и идут по правилам IPFW. Видел примеры, где все IN пакеты по внешнему интерфейсу (кроме стандартных запрещающих правил для подсетей) заруливаются на нат первым же правилом. Насколько это принципиально и безопасно?<br><br> Получается, что есть фильтрация входящих до nat и после nat. <br> Правила 3010-40 запрещают вход на служебные порты роутера, разрешая только доступ на веб сервер на роутере, и после этих правил по сути все разрешено на роутер на вход.<br><br>$fwcmd 3999 allow all from any to any // inet in transit<br><br> Это правило разрешает весь трафик с инета в локалку после прохождения nat.<br>а эти правила разрешают свободный выход в сеть.<br> $fwcmd 5000 nat 1 all from any to any // inet out<br>$fwcmd 5010 allow all from any to any // inet out<br><br>Получается что клиент сети, может ин https://opennet.ru/openforum/vsluhforumID10/5457.html#6 Sat, 05 May 2018 05:18:36 GMT &gt;[оверквотинг удален]<br>&gt;&gt; Вот если убрать правило 110, то весь исходящий траф будет <br>&gt;&gt; порезан правилом 1999, который для правила 1000 режет все пакеты которые <br>&gt;&gt; не имели тега recv для интерфейсов инет и лан.<br>&gt; Да, верно, но только потому, что нет других правил между 110 и <br>&gt; 1000. Если бы были - о то оба нужны.<br>&gt; Напоминание по поводу NAT: для маршрутизатора в NAT нужно заворачивать весь трафик <br>&gt; - входящий, понятно, и так весь, но ошибочно делают NAT только <br>&gt; исходящего трафика других компов, а исходящий самого шлюза не делают, и <br>&gt; потом удивляются разным глюкам.<br>&gt; ipfw - это как ассемблер, too easy to shoot the leg.<br><br> А можно мне пояснить немного один момент. В русских мануалах по ipfw где разбирают схему прохождения пакета структура такая, что пакет дойдя до правила заворачивания в nat и пройдя процедуру маскирования (например для исходящих) вновь возвращается в скажем так в функцию ip_out и снова пробегает по цепочке правил для исходящих пакетов. Но опция <br><br># lan in<br>$fwcmd 4000 al