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

MultiWan не работает без Reset States

Scheduled Pinned Locked Moved Russian
15 Posts 6 Posters 3.0k 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 Aug 25, 2014, 10:21 AM

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

    Multi-WAN in pfSense 2.1 works just like Multi-WAN on 2.0.x so the basics are all identical.

    The main difference is that with 2.1 you can setup Multi-WAN for IPv6.

    In the default configuration on pfSense 2.1, "State Killing on Gateway Failure" is not active. Because of this, Multi-WAN may not work ideally out of the box. For example, if you want to force connections to failover from WAN1 to WAN2, you will want to enable the option. It can be found under System > Advanced on the Miscellaneous tab, under Load Balancing.

    И в той же закладке поиграйте с

    Allow default gateway switching

    1 Reply Last reply Reply Quote 0
    • T
      ton
      last edited by Aug 26, 2014, 1:38 AM

      Снятие галки State Killing on Gateway Failure помогло! После пропадания основного канала, через три потерянных пакета, пинг возобновляется через резервный канал сам! Спасибо большое!
      Allow default gateway switching я ставил еще в начале, когда всё делал по инструкции из ссылки в первом посте.
      Но столкнулся с новой неприятностью:
      При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как сделать, что бы это работало и в обратную сторону?

      1 Reply Last reply Reply Quote 0
      • P
        pigbrother
        last edited by Aug 26, 2014, 7:51 AM Aug 26, 2014, 7:47 AM

        Снятие галки State Killing on Gateway Failure помогло!

        Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.

        По крайней мере в 2.0.3 failower корректно отрабатывает, настройки State Killing on Gateway Failure в 2.0.3 вообще нет.

        При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?

        Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.

        А как\чем  вы смотрите, с какого шлюза идет пинг?

        1 Reply Last reply Reply Quote 0
        • T
          ton
          last edited by Aug 26, 2014, 8:07 AM

          @pigbrother:

          Снятие галки State Killing on Gateway Failure помогло!

          Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.

          У меня в версии 2.1.4 эта галка была по умолчанию, и именно после её снятия заработало как надо.

          @pigbrother:

          А как\чем  вы смотрите, с какого шлюза идет пинг?

          Я делаю трасерт во втором окне параллельно и вижу, что трасерт проходит по старом маршруту.
          После Reset States начитнает работать по правльному.

          1 Reply Last reply Reply Quote 0
          • P
            pigbrother
            last edited by Aug 26, 2014, 9:04 AM

            У меня в версии 2.1.4 эта галка была по умолчанию, и именно после её снятия заработало как надо.

            Вероятно авторы pfSense перепутали поведение\описание этой настройки.

            1 Reply Last reply Reply Quote 0
            • T
              ton
              last edited by Aug 27, 2014, 2:14 AM

              @pigbrother:

              При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?

              Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.

              Так как решить проблему без ручного сброса states? Хотелось бы автоматическую систему =(

              1 Reply Last reply Reply Quote 0
              • W
                werter
                last edited by Aug 28, 2014, 1:59 PM

                Бредовая идея, но :
                1. Делаем reset states руками.
                2. Возвращаем "галку" на State Killing on Gateway Failure.
                3. Снова делаем reset states руками.
                4. Проверяем работу failover.

                Почему ? Потому что именно включение этой опции заставляет корректно работать failover.

                P.s. Отпишитесь разработчикам pfsense, если все же проблема не решается. Этим поможете многим (тысячам) :)
                Заранее благодарен.

                1 Reply Last reply Reply Quote 0
                • T
                  ton
                  last edited by Sep 12, 2014, 9:31 AM Sep 12, 2014, 9:27 AM

                  @werter:

                  Бредовая идея, но :
                  1. Делаем reset states руками.
                  2. Возвращаем "галку" на State Killing on Gateway Failure.
                  3. Снова делаем reset states руками.
                  4. Проверяем работу failover.

                  Почему ? Потому что именно включение этой опции заставляет корректно работать failover.

                  Попробовал по вашей схеме. Не помогло.
                  Затем вчитался в коммент к галочке:
                  The monitoring process will flush states for a gateway that goes down if this box is not checked. Check this box to disable this behavior.
                  Выходит галочки не должно быть, что бы работало. Ну и ладно, без неё работает переключение хорошо.
                  Но проблема при возврате на основной интернет канал остаётся! Reset states не происходит! Новые соединения работают по основному каналу, а старые, продолжают работать по резервному! Как это победить?
                  Перешел даже на последнюю версию 2.1.5. Полностью переустановил всё с форматированием. Та же проблема.

                  1 Reply Last reply Reply Quote 0
                  • B
                    bill_open
                    last edited by Sep 14, 2014, 6:22 PM Sep 14, 2014, 6:05 PM

                    В 2.1.2 все работает норм. Странно, но галочка state killing
                    Стоит по умолчанию. В начале у меня были траблы с переключением при падении, но проблема решилась галкой Allow default gateway switching. По поводу возврата на основной шлюз, я считаю, да так и есть в моей реализации, что переключение обратно должно произойти по закрытию старых сессий, то есть все новые сессии будут открываться на восстановившемся канале.
                    Такой способ правильнее для конечного сайта(ресурса).
                    И вот еще, 30 сек на самом деле долго для переключения, скорее всего из за dhcp на wan, хоть и наверняка у твоего провайдера твой мак уже сопоставлен с ip. Попробуй сделать default gateway интерфейс со статикой и протестировать схему.

                    1 Reply Last reply Reply Quote 0
                    • T
                      ton
                      last edited by Oct 2, 2014, 2:39 AM

                      Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
                      Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
                      как сделать?

                      1 Reply Last reply Reply Quote 0
                      • B
                        bill_open
                        last edited by Oct 2, 2014, 6:04 PM

                        Извини, но я хз.

                        1 Reply Last reply Reply Quote 0
                        • D
                          dvserg
                          last edited by Oct 2, 2014, 8:03 PM

                          @ton:

                          Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
                          Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
                          как сделать?

                          В опциях правил, разрешающих телефонный трафик, есть опция, управляющая поведением этого трафика в States. По умолчанию там Keep state. Может быть поменять его на другую опцию - no-state ?

                          SquidGuardDoc EN  RU Tutorial
                          Localization ru_PFSense

                          1 Reply Last reply Reply Quote 0
                          • T
                            ton
                            last edited by Oct 17, 2014, 8:33 AM

                            Проблема была в том, что был выключен мониторинг маршрута резервного канала, который должен пинговать шлюз на доступность.
                            Всем спасибо за страдания! =)

                            1 Reply Last reply Reply Quote 0
                            • D
                              derwin
                              last edited by Oct 24, 2014, 1:38 AM

                              @ton:

                              Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
                              Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
                              как сделать?

                              В телефонном оборудовании (как правило сервер) есть опция, которая постоянно посылает пакеты. Изза того, что state всегда поддерживается - мы видим то, что траффик не уходит в новый маршрут. Я сделал на своём астериске  quality =60000 и всё стало норм.

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