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

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

    Scheduled Pinned Locked Moved Russian
    45 Posts 5 Posters 9.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.
    • 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
                          • P
                            pigbrother
                            last edited by

                            Софт по ссылке, как я понял, позволяет использовать IAX2-оборудование с провайдером, поддерживающим только SIP, без необходимости разворачивать для этого отдельный\промежуточный Asterisk.
                            Проект, похоже, заброшен:
                            23 Nov 2012 — Initial Public Release (version 0.2.1.3, Blue Moon release) - первый и единственный релиз.

                            P.s. Сейчас даже недорогое железо поддерживает IAX2.
                            То, что у меня уже работает, о IAX2 ничего не знает. Теперь, при покупке нового, на поддержку IAX2 обращать внимание буду обязательно.  Спасибо.

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

                              @pigbrother:

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

                              А это значение этого поля является условием,на соответствие которому проверяется очередной пакет трафика,или же указанием,на какой интерфейс должен идти трафик соответствующий всем остальным полям данного правила?

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

                                Вероятно - не является.
                                В самом пакете нет упоминания о том, через какой шлюз он должен уйти.

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

                                  Спасибо.

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

                                    Был несколько невнимателен, дополню. Назначение шлюза - не условие выполнения правила, а именно его указание, если соблюдаются заданные в правиле условия.

                                    Т.е. если пакет соответствует набору условий то ему назначается шлюз.

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