The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
IPFW NAT - порядок прохождения правил, !*! neekonoff, 17-Апр-17, 15:50  [смотреть все]
Друзья, прошу помощи.
FreeBSD 10.3.
Есть вот такой набор правил. По структуре - пример правил из хэндбука.
---------------------------------------------------------------------------------
#!/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

ipfw -q nat 1 config ip 1.2.3.4 same_ports reset deny_in \
                        redirect_port tcp 10.1.10.12:443 443 \
                        redirect_port tcp 10.1.10.12:25 25

$cmd 100 nat 1 ip from any to any in via em0
                        
$cmd 200 check-state

$cmd 300 skipto 800 tcp from 10.1.10.0/24 to any out via em0 setup keep-state

$cmd 400 deny all from any to any frag in via em0
$cmd 500 deny tcp from any to any established in via em0

$cmd 600 tcp from any to 10.1.10.12 25,443 in via em0 setup keep-state

$cmd 700 deny all from any to any via em0

$cmd 800 nat 1 ip from any to any out via em0

$cmd 900 allow all from any to any
$cmd 999 deny all from any to any

----------------------------------------------------------
sysctl net.inet.ip.fw.one_pass=0
----------------------------------------------------------------------------------
Подскажите, почему нет связи с 10.1.10.12 извне?

Ведь входящий трафик на внешний IP 1.2.3.4 на порт, например, 443:
На проходе IN:
1. Приходит на правило 100. Меняется адрес назначения (так как редирект_порт)
2. Далее выходит изната и, т.к. one_pass=0, доходит до правила 600 (в динамической таблице создается запись для пар адресов внутреннего и внешнего адреса), выходит из прохода IN и попадает в проход OUT.
На проходе OUT:
3. Доходит до правила 020 и отправляется на внутренний хост 10.1.10.12:443.

Ответный трафик от хоста 10.1.10.12
На проходе IN:
4. Доходит до правила 020, входит из прохода IN и попадает в проход OUT.
На проходе OUT:
5. Доходит до правила 200 и отправляется на внешний адрес (т.к. запись о соединении уже есть в динамической таблице).

Подскажите, где ошибка?

  • 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 - порядок прохождения правил, !*! михалыч, 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.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру