- IPFW NAT - порядок прохождения правил, Аноним, 18:39 , 17-Апр-17 (1)
- IPFW NAT - порядок прохождения правил, Аноним, 18:41 , 17-Апр-17 (2)
- IPFW NAT - порядок прохождения правил, neekonoff, 19:02 , 17-Апр-17 (4)
>>> Подскажите, где ошибка? >> начнём с трbвиального: >> gateway_enable="YES" в /etc/rc.conf включил? >> на хосте 10.1.10.12 шлюзом машина с IPFW прописана? > $cmd 500 deny tcp from any to any established in via em0 > <- ХЕРНЯ Почему херня? Оно запрещает ACK пакеты, которые не соответствуют динамической таблице правил.
- IPFW NAT - порядок прохождения правил, neekonoff, 19:22 , 17-Апр-17 (5)
>>> Подскажите, где ошибка? >> начнём с трbвиального: >> gateway_enable="YES" в /etc/rc.conf включил? >> на хосте 10.1.10.12 шлюзом машина с IPFW прописана? > $cmd 500 deny tcp from any to any established in via em0 > <- ХЕРНЯ Ок. Отключил правило 500. Все равно болт..
- IPFW NAT - порядок прохождения правил, Pahanivo, 00:07 , 18-Апр-17 (6)
- IPFW NAT - порядок прохождения правил, neekonoff, 01:47 , 18-Апр-17 (7)
>[оверквотинг удален] > это не набор правил, а скрипт для их создания (конфигурации) > смотри рабочие правила, а не скрипт > а конфиг интерфейсов где? >> --------------------------------------------------------------------------------- >> #!/bin/sh >> ipfw -q -f flush >> cmd="ipfw -q add" >> $cmd 010 allow all from any to any via lo0 >> $cmd 020 allow all from any to any via fxp0 > fxp0 это типа внешний интерфейс??fxp0 - внутренний интерфейс 10.1.10.1 em0 - внешний 1.2.3.4 >> ---------------------------------------------------------- >> sysctl net.inet.ip.fw.one_pass=0 > нахуа?? Ну так ведь иначе после правила с NAT пакет не пойдет дальше по правилам. А структура этого конфига подразумевает как раз, чтобы пакет обрабатывался подходящим правилом после правила с NAT. Ну и в дальнейшем чтоб прикрутить пайпы и очереди. >> Подскажите, где ошибка? > ошибка в том что пакет пройдет фаер дважды (по кол-ву интерйефсов) Я понимаю, чтоб пакет пройдет фаер дважды. Но, покурив вот это http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/ , думал, что пакет пройдет фаер дважды по проходам IN и OUT, а не из-за количества интерфейсов. Объясните пжлста поподробней об "ошибка в том, что пакет пройдет фаер дважды (по кол-ву интерфейсов)"
- IPFW NAT - порядок прохождения правил, neekonoff, 19:00 , 17-Апр-17 (3)
>> Подскажите, где ошибка? > начнём с трbвиального: > gateway_enable="YES" в /etc/rc.conf включил? > на хосте 10.1.10.12 шлюзом машина с IPFW прописана?Да, конечно. И firewall_nat_enable.. Все это есть.
- IPFW NAT - порядок прохождения правил, Дум Дум, 14:48 , 18-Апр-17 (9)
- IPFW NAT - порядок прохождения правил, neekonoff, 16:12 , 18-Апр-17 (10)
>> ipfw -q nat 1 config ip 1.2.3.4 same_ports reset deny_in \ >> > Вспомнить бы про deny_in. Вроде, в нат попадёт входящий - ответ на > исходящий, но попытка установки соединения извне - нет...?Случайный трафик извне - нет. Но трафик на порт 80 - обработается, так как есть папаметр "redirect_port..".
- IPFW NAT - порядок прохождения правил, Дум Дум, 10:35 , 19-Апр-17 (12)
- IPFW NAT - порядок прохождения правил, neekonoff, 23:11 , 19-Апр-17 (15)
>>>Ответный трафик от хоста 10.1.10.12 >>>На проходе IN: >>>4. Доходит до правила 020, входит из прохода IN и попадает в проход OUT. >>>На проходе OUT: >>>5. Доходит до правила 200 и отправляется на внешний адрес (т.к. запись о соединении >>уже есть в динамической таблице). > Тогда на проходе OUT доходит до правила 200 и отправляется на внешний > адрес с адресом отправителя 10.1.10.12... ?Да, я этого не учел совсем.. Спасибо!
- IPFW NAT - порядок прохождения правил, михалыч, 11:54 , 19-Апр-17 (13)
- IPFW NAT - порядок прохождения правил, Pahanivo, 16:29 , 19-Апр-17 (14)
- IPFW NAT - порядок прохождения правил, neekonoff, 23:16 , 19-Апр-17 (16) –1
>[оверквотинг удален] > add 100 nat 1 all from any to any > ### конфигурируем nat 1 > nat 1 config redirect_port tcp 10.1.10.12:443 443 redirect_port tcp 10.1.10.12:25 25 > ### разрешаем всё и всем > add 200 allow all from any to any > 3. загружаем правила > # ipfw /etc/ipfw_test > 4. проверяем > если всё работает, то можно дополнять правилами фильтрации, > нарезать пайпы и очереди для изменения скорости Подозреваю, что покажется бредом, но мне нравится логика и/или структура (или как это правильно назвать) конфига из хэндбука (последний пример от на этой странице https://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/fire... ). И я хотел понять, возможно ли в к этой структуре прикрутить редирект. Ну и пайпы с очередями в дальнешем. Переделанный под ядерный нат пример из хэндбука у меня работает. Мне кажется, что я его раскурил таки. Понимаю, что скорее всего придется делать так, как вы говорите. Но все же :) Спасибо
- IPFW NAT - порядок прохождения правил, Аноним, 20:02 , 20-Апр-17 (17)
- IPFW NAT - порядок прохождения правил, neekonoff, 21:22 , 20-Апр-17 (19)
>[оверквотинг удален] > и мне нравится, иногда, при использовании динамических правил, > можно уложиться в меньшее количество этих самых правил > но надо быть очень внимательным, а то можно в системе > потенциальную дыру в безопасности создать и незаметить, > а оставив такую дыру последствия могут быть самыми печальными 😭 > динамические правила они сложнее для понимания, а написание правил с натом > и вовсе становится нетривиальной задачей > жаль, что ты сдался, надо приложить усилие чтобы разобраться > а хочешь, я вот возьму и напишу за тебя эти правила? > думаешь дядя шутит? нет, серьёзно, я могу, если действительно надо Сарказм detected ;)
- IPFW NAT - порядок прохождения правил, neekonoff, 21:22 , 20-Апр-17 (18)
Проблему я решил таким образом: (другие адреса и интерфейсы, мушто на типа "тестовом стенде" на hyper-v, но в остальном все идентично)#!/bin/sh ipfw -q -f flush cmd="ipfw -q add" eif="hn0" #внешний интерфейс iif="hn1" #внутренний интерфейс ip1="192.168.100.5" #типа белый ip на eif #ip2="192.168.100.6" #----------------------------------------------------------- $cmd 008 allow all from any to any via lo0 $cmd 010 allow all from any to any via $iif #-----------------------NAT config-------------------------- ipfw -q nat 1 config ip $ip1 same_ports reset deny_in redirect_port tcp 10.1.10.11:80 80 redirect_port tcp 192.168.100.5:22 22 #--------------------------NAT------------------------------ $cmd 100 nat 1 tcp from 10.1.10.11 80 to any out xmit $eif $cmd 102 nat 1 ip from any to $ip1 not 80 in recv $eif #----------------------------------------------------------- $cmd 111 check-state #------------------------Outgoing--------------------------- $cmd 210 skipto 820 tcp from 10.1.10.0/24 to any out via $eif setup keep-state $cmd 212 skipto 820 icmp from 10.1.10.0/24 to any out via $eif keep-state $cmd 330 deny all from any to any frag in via $eif $cmd 332 deny tcp from any to any established in via $eif #------------------------Incoming--------------------------- $cmd 350 skipto 850 tcp from any to $ip1 80 in recv $eif setup keep-state $cmd 380 allow tcp from any to me 22 in via $eif setup limit src-addr 2 #---------------------------Log----------------------------- $cmd 700 deny log all from any to any in via $eif $cmd 710 deny log all from any to any out via $eif #--------------------------Skipto--------------------------- $cmd 820 nat 1 ip from any to any out via $eif $cmd 850 nat 1 tcp from any to $ip1 in recv $eif $cmd 900 allow ip from any to any #----------------------------------------------------------- $cmd 999 deny log all from any to any #--------------------------------------- Таким образом получается, что: Трафик, приходящий извне на IP 192.168.100.5:80 На проходе IN 1. Доходит до правила 350 (в динамическую таблицу добалвяется запись вида 192.168.100.5:80<->"IP-адрес_инициатора:какой-то_порт") и "прыгает" на 850. 2. На правиле 850 адрес назначения заменяется с 192.168.100.5:80 на 10.1.10.11:80, далее выходит из NAT и, так как one_pass=0, доходит до правила 900 и выходит из прохода IN. На проходие OUT 1. Доходит до правила 010 и выпускается на машину с адресом 10.1.10.11:80 Ответный трафик от машины 10.1.10.11:80 На проходе IN 1. Доходит до правила 010, выходит из прохода IN и попадает в проход OUT На проходе OUT 1. Доходит до правила 100, заменяется адрес источника с 10.1.10.11:80 на 192.168.100.5:80, выходит из NAT и, так как one_pass=0, идет дальше до правила 111. 2. На правиле 111 проверяется динамическая таблица и, так как в ней уже присутствует запись вида 192.168.100.5:80<->"IP-адрес_инициатора:какой-то_порт", трафик выпускается наружу. Может быть кому-то пригодится. Отдельное спасибо Дум Дум за помосчь в рассуждениях! :)
- IPFW NAT - порядок прохождения правил, михалыч, 11:10 , 21-Апр-17 (20)
- IPFW NAT - порядок прохождения правил, neekonoff, 19:04 , 24-Апр-17 (25)
Я держал в уме то, что мне нужно будет транслировать трафик на порты 80 443 и 25 с одним внешним IP, а трафик, от подсети 10.1.10.0/24 - с другим. Да, соглашусь. Выглядит непонятно, запутанно.
- IPFW NAT - порядок прохождения правил, михалыч, 20:08 , 21-Апр-17 (21)
- IPFW NAT - порядок прохождения правил, neekonoff, 16:52 , 23-Апр-17 (22)
Я не поленислся и проверил то, что вы написали. Скажите, для чего вам правила 700-702, если до них дело даже не доходит?
- IPFW NAT - порядок прохождения правил, Аноним, 19:43 , 23-Апр-17 (23)
- IPFW NAT - порядок прохождения правил, neekonoff, 18:01 , 24-Апр-17 (24)
Ok, скажите, что у вас с переменной sysctl net.inet.ip.fw.one_pass (конкретно с kernel nat, natd меня не интересует)?
- IPFW NAT - порядок прохождения правил, михалыч, 19:55 , 24-Апр-17 (26)
- IPFW NAT - порядок прохождения правил, neekonoff, 00:17 , 25-Апр-17 (28)
> хм.. по идее эта переменная ни на что не влияет, кроме как > на пайпы dummynet и узлы ng_ipfw Эта переменная влияет на правила nat так же как и на правила dummynet. И эти правила с переменной sysctl net.inet.ip.fw.one_pass=1 работать у вас не будут, хотя вы сказали, что "проверено". > возможно я и сам тумана напустил в комментах в своём примере )) Что есть, то есть. И еще вы ни разу не разбирались в том, о чем писал я. > в данном листинге в конфигурации nat отсутствует deny_in > это принципиально, в противном случае не будет работать секция для входящего трафика > (не редиректа, он будет продолжать работать, как верно было подмечено выше) Секция для входящего трафика будет работать с параметром deny_in, если к конфигурации nat добавить параметр "redirect_port tcp 1.2.3.4:22 22 redirect_port tcp 1.2.3.4:80 80" и т.д... > если хочется сохранить deny_in то нужно секцию правил для входящего трафика (700-703) > разместить выше правила 300 для nat входящих пакетов > например под номерами 250-253 .. и не нужно будет портить структуру конфига > ограничение скорости лучше реализовать после того как будут отфильтрованы ненужные пакеты, > а уж потом нарезать полосы пропускания у оставшихся Ограничение скорости можно даже организовать в обе стороны. Структура конфига об этом "кричит". > можешь поиграться с net.inet.ip.fw.one_pass повключть и повыключать его прямо из листинга, > после сброса правил, > но повторюсь, без пайпов это ни на что не влияет Правила эти будут работать при условии, что переменная sysctl net.inet.ip.fw.one_pass=0. В оригинальном примере правил из хэндбука об этом ничего не говорится, т.к. там используется демон natd и не используется dummynet (который, к слову сказать, как и "ipfw nat", работает в ядре), а sysctl net.inet.ip.fw.one_pass дефолтно равна 1.
- IPFW NAT - порядок прохождения правил, Аноним, 20:33 , 24-Апр-17 (27)
- IPFW NAT - порядок прохождения правил, neekonoff, 00:22 , 25-Апр-17 (29)
> если используешь стенд с серыми адресами > убери все правила до 100 (если скопировал их из примера) > и убери из конфигурации нат unreg_only (опять же, если есть) Параметр unreg_only предписывает проводить маскировку только для тех исходящих пакетов, чей адрес отправителя находится в классах "незарегистрированных" IP адресов. Так что в данном случае можно смело использовать параметр unreg_only.
|