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

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

    Scheduled Pinned Locked Moved Russian
    45 Posts 5 Posters 10.1k 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.
    • S
      Scodezan
      last edited by

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

      
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

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

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

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

        1 Reply Last reply Reply Quote 0
        • werterW
          werter
          last edited by

          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

            Так ТС 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
            • werterW
              werter
              last edited by

              @pigbrother:

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

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

              1 Reply Last reply Reply Quote 0
              • G
                GSerg
                last edited by

                @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

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

                  1 Reply Last reply Reply Quote 0
                  • S
                    Scodezan
                    last edited by

                    @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

                      @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

                        @Scodezan:

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

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

                        1 Reply Last reply Reply Quote 0
                        • G
                          GSerg
                          last edited by

                          @Scodezan:

                          @GSerg:

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

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

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

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

                          1 Reply Last reply Reply Quote 0
                          • G
                            GSerg
                            last edited by

                            @Scodezan:

                            @GSerg:

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

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

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

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

                            1 Reply Last reply Reply Quote 0
                            • S
                              Scodezan
                              last edited by

                              @GSerg:

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

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

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

                              @GSerg:

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

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

                              1 Reply Last reply Reply Quote 0
                              • G
                                GSerg
                                last edited by

                                @Scodezan:

                                @GSerg:

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

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

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

                                1 Reply Last reply Reply Quote 0
                                • S
                                  Scodezan
                                  last edited by

                                  @GSerg:

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

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

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

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

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    GSerg
                                    last edited by

                                    @Scodezan:

                                    @GSerg:

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

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

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

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

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

                                    1 Reply Last reply Reply Quote 0
                                    • werterW
                                      werter
                                      last edited by

                                      @GSerg:

                                      @Scodezan:

                                      @GSerg:

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

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

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

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

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

                                      Если есть возможность, то настоятельно рекомендую перейти на IAX2. Намного упрощает жизнь. Хотя бы тем , что открывать прийдется всего лишь один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).

                                      1 Reply Last reply Reply Quote 0
                                      • G
                                        GSerg
                                        last edited by

                                        @werter:

                                        один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).

                                        Отличная рекомендация,спасибо!

                                        1 Reply Last reply Reply Quote 0
                                        • P
                                          pigbrother
                                          last edited by

                                          Присоединяюсь к благодарности за рекомендацию. Вот только полно железа, которое про IAX2 не слышало и не услышит.
                                          Как решение представляется некий прокси  IAX2->SIP
                                          https://groups.google.com/forum/#!topic/taug-archive/SR_VJK9tRko

                                          1 Reply Last reply Reply Quote 0
                                          • werterW
                                            werter
                                            last edited by

                                            2 pigbrother

                                            https://github.com/primuslabs/iaxproxy

                                            When an IAX2 end point connects to IAXProxy the endpoint information is looked up in Redis and assuming the IAX2 device passes authentication then a SIP Peer and SIP Registrar are created on the users behalf

                                            Мне кажется или оно для другого предназначено ? Т.е. у меня изначально есть iax2-уст-во и мне его надо подключить к только-sip-АТС ? Так asterisk и так iax2 прекрасно поддерживает.

                                            P.s. Сейчас даже недорогое железо поддерживает IAX2. Из ip-phone посмотрите в сторону ATCOM 610\620.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.