• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Настройка правил firewall на резервном канале

Scheduled Pinned Locked Moved Russian
45 Posts 5 Posters 9.2k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P
    pigbrother
    last edited by Jun 30, 2015, 1:07 PM Jun 30, 2015, 12:56 PM

    Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
    Поставьте  Default allow LAN to any rule последним, а свои правила - выше него.

    WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.

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

    Указание  поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.

    1 Reply Last reply Reply Quote 0
    • G
      GSerg
      last edited by Jun 30, 2015, 1:05 PM

      @pigbrother:

      Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
      Поставьте  Default allow LAN to any rule последним, а свои правила - выше него.

      WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.

      В реальности 4 версия IP,название просто осталось.Спасибо,сейчас попробую поменять правила местами.

      1 Reply Last reply Reply Quote 0
      • P
        pigbrother
        last edited by Jun 30, 2015, 1:21 PM Jun 30, 2015, 1:08 PM

        Спасибо,сейчас попробую поменять правила местами.

        В принципе правильно расположенное разрешающее правило с dst-портом 5060 с указанием шлюза OPT одновременно запретит такому трафику ходить через шлюз WAN

        Не забывать reset states или reboot.

        1 Reply Last reply Reply Quote 0
        • G
          GSerg
          last edited by Jul 1, 2015, 4:03 AM

          @pigbrother:

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

          Указание  поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.

          Увы,это иллюзия и нативными средствами pfsense 2.2.2 эту задачу решить не получится.Загвоздка в том,что правило разрешающее только  VOIP через определённый интерфейс должно работать только при условии , что другой интерфейс лежит . Остаётся только организовать кластер pfsens'ов,или писать скрипты.

          1 Reply Last reply Reply Quote 0
          • S
            Scodezan
            last edited by Jul 1, 2015, 5:29 AM Jul 1, 2015, 5:17 AM

            Не знаю что вы там городите, лично у меня последовательность

            
            allow IPv4 TCP 192.168.1.244 * *  Ports80443  GW_MARK  none  (Vahta)
            allow IPv4 TCP  LocalNet    * *  Ports80443  prio_mark  none  (MAIN ALLOW) 
            
            

            запрещает компьютеру 192.168.1.244 переходить на резервный канал. Где GW_MARK основной шлюз, prio_mark - фаловер.

            С VoIP, конечно немного сложнее…

            1 Reply Last reply Reply Quote 0
            • P
              pigbrother
              last edited by Jul 1, 2015, 6:30 AM

              только при условии , что другой интерфейс лежит.

              Да, в правилах нет возможности привязки к состоянию шлюза\интерфейса.
              А не поможет ли  Allow default gateway switching?

              https://forum.pfsense.org/index.php?topic=45081.0

              1 Reply Last reply Reply Quote 0
              • W
                werter
                last edited by Jul 1, 2015, 7:04 AM Jul 1, 2015, 6:59 AM

                1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

                2. block IPv4 UDP  LAN subnet *  **!**5060 (SIP) OPT1  none

                3. allow IPv4 * LAN subnet  * * *  WAN_GW none

                А не поможет ли  Allow default gateway switching?

                Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
                Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.

                1 Reply Last reply Reply Quote 0
                • P
                  pigbrother
                  last edited by Jul 1, 2015, 7:21 AM Jul 1, 2015, 7:17 AM

                  Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен\может блокировать.

                  _1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

                  2. block IPv4 UDP  LAN subnet *  !5060 (SIP) OPT1  none_

                  А эти правила не дублируют друг друга?

                  1 Reply Last reply Reply Quote 0
                  • W
                    werter
                    last edited by Jul 1, 2015, 7:18 AM

                    @pigbrother:

                    Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен блокировать.

                    Верно. Пускай ТС пробует.

                    1 Reply Last reply Reply Quote 0
                    • G
                      GSerg
                      last edited by Jul 1, 2015, 7:21 AM

                      @werter:

                      1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

                      2. block IPv4 UDP  LAN subnet *  **!**5060 (SIP) OPT1  none

                      3. allow IPv4 * LAN subnet  * * *  WAN_GW none

                      А не поможет ли  Allow default gateway switching?

                      Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
                      Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.

                      Если я верно понимаю,то первая строчка этого правила направит весь трафик SIP на OPT1 .Даже когда будет работать основной интерфейс. Это не совсем то,что нужно.

                      1 Reply Last reply Reply Quote 0
                      • G
                        GSerg
                        last edited by Jul 1, 2015, 7:55 AM

                        В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.Тему можно закрывать.

                        1 Reply Last reply Reply Quote 0
                        • S
                          Scodezan
                          last edited by Jul 1, 2015, 9:44 AM

                          @GSerg:

                          В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.

                          Так чтоб по типу надо смотреть в сторону L7, что кстати в 2.2.2 недоступно.
                          Доступно по номеру+типу порта, адресу источника запроса и адресу назначения.

                          @GSerg:

                          Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.

                          Верно, поэтому есть резервирование.

                          @GSerg:

                          Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.

                          В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.

                          @GSerg:

                          Тему можно закрывать.

                          DO IT)))

                          1 Reply Last reply Reply Quote 0
                          • S
                            Scodezan
                            last edited by Jul 1, 2015, 10:35 AM

                            @GSerg:

                            Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

                            Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

                            так пробовали?

                            ![2015-07-01 14-29-16 ???????? ??????.png](/public/imported_attachments/1/2015-07-01 14-29-16 ???????? ??????.png)
                            ![2015-07-01 14-29-16 ???????? ??????.png_thumb](/public/imported_attachments/1/2015-07-01 14-29-16 ???????? ??????.png_thumb)

                            1 Reply Last reply Reply Quote 0
                            • G
                              GSerg
                              last edited by Jul 1, 2015, 11:01 AM

                              @Scodezan:

                              В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.

                              Дело в том,что вкупе с SIP трафиком телефония использует непосредственно для передачи голоса rtp трафик.

                              1 Reply Last reply Reply Quote 0
                              • G
                                GSerg
                                last edited by Jul 1, 2015, 11:09 AM

                                @Scodezan:

                                @GSerg:

                                Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

                                Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

                                так пробовали?

                                По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
                                всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

                                1 Reply Last reply Reply Quote 0
                                • G
                                  GSerg
                                  last edited by Jul 1, 2015, 11:14 AM

                                  @Scodezan:

                                  @GSerg:

                                  Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

                                  Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

                                  так пробовали?

                                  Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    Scodezan
                                    last edited by Jul 1, 2015, 12:07 PM Jul 1, 2015, 11:59 AM

                                    @GSerg:

                                    По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
                                    всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

                                    Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что интерфейс шлюз будет другой. Всё зависит только от Вас.

                                    А первые два правила защищают от ошибок конфигурирования fw

                                    @GSerg:

                                    Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.

                                    ааа??? Ну что ж. Найдёте лучшее решение, добро пожаловать.

                                    1 Reply Last reply Reply Quote 0
                                    • G
                                      GSerg
                                      last edited by Jul 1, 2015, 12:15 PM

                                      @Scodezan:

                                      @GSerg:

                                      По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
                                      всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

                                      Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что интерфейс шлюз будет другой. Всё зависит только от Вас.

                                      Я интерпретировал Ваш пример применительно к своим условиям.В целом Ваш посыл понятен.
                                      Вы ведь не упускаете из виду,что моя задача состоит в том,чтобы через резервный OPT1 шёл только трафик voip и только когда лежит основной интерфейс?Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
                                      Если у Вас есть решение как сделать это pfsens'ом , сделайте милость,избавьте от необходимости искать лучшее решение. :)

                                      1 Reply Last reply Reply Quote 0
                                      • S
                                        Scodezan
                                        last edited by Jul 1, 2015, 1:21 PM

                                        @GSerg:

                                        Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.

                                        Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.

                                        Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.

                                        Кстати, на каких кодеках работаете?

                                        1 Reply Last reply Reply Quote 0
                                        • G
                                          GSerg
                                          last edited by Jul 1, 2015, 1:53 PM

                                          @Scodezan:

                                          @GSerg:

                                          Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.

                                          Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.

                                          Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.

                                          Кстати, на каких кодеках работаете?

                                          Телефонией занимаются другие,поэтому не знаю  :)
                                          Проглядел возможность указания в правилах фаервола группы шлюзов. Это выглядит как возможное решение.Буду пробовать.

                                          1 Reply Last reply Reply Quote 0
                                          36 out of 45
                                          • First post
                                            36/45
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                            This community forum collects and processes your personal information.
                                            consent.not_received