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

    Port Forward в Multiwan

    Scheduled Pinned Locked Moved Russian
    11 Posts 4 Posters 1.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.
    • X
      xxkxx
      last edited by

      Добрый день.Подскажите как правильно прокинуть порты что бы это было справедливо при переключении провайдера.В настройках fierwall-nat при создании правила можно выбрать только определенный сетевой интерфейс.

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

        Доброе.
        Опишите ТЗ подробнее, пож-та.

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

          В настройках fierwall-nat при создании правила можно выбрать только определенный сетевой интерфейс.
          Логично. Указать группу шлюзов можно только для исходящего (srcnat) трафика. Port Forward - это dstnat.

          Теоретически может помочь пакет haproxy.

          1 Reply Last reply Reply Quote 0
          • X
            xxkxx
            last edited by

            Спасибо за скорый ответ!!!

            ТЗ вкратце такое.
            Есть компьютер на котором работают сервисы. Сервисы должны быть всегда доступны,для этого предусмотрен резервный канал.
            Предположил что есть возможность указать проброс портов вне зависимости от используемого канала интернета,что бы не прописывать вручную на каждый канал

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

              _Предположил что есть возможность указать проброс портов вне зависимости от используемого канала интернета,что бы не прописывать вручную на каждый канал _

              Касательно port forward.
              Поймите простую вещь. Пробрасываемый порт привязан к конкретному шлюзу("провайдеру"). Упал линк этого провайдера - проброшенный порт недоступен. И это уже задача наружного клиента понять это и переключиться на второй канал.
              Варианты - отказоустойчивый VPN (OSPF, например) и обращение у ресурсу сети внутри сети через VPN по внутреннему IP.

              1 Reply Last reply Reply Quote 0
              • X
                xxkxx
                last edited by

                Мысль понял.
                Для справки добавлю что например в tl-r480t+ есть возможность выбрать wan-all для прокидывания портов.

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

                  @xxkxx:

                  Мысль понял.
                  Для справки добавлю что например в tl-r480t+ есть возможность выбрать wan-all для прокидывания портов.

                  Такое можно сделать и в pfSense, правда индивидуально для каждого WAN.
                  Но что это даст клиенту?

                  Еще раз.
                  Два провайдера. 2 ISP, выдающих pfSense 2 внешних IP - 1.1.1.1 и 2.2.2.2. На каждом из них настроен проброс, скажем, порта 1000.
                  Клиент коннектится к 1.1.1.1:1000.  Линк к провайдеру, выдающему 1.1.1.1 упал. Как клиент узнает, что нужно коннектиться к 2.2.2.2:1000?
                  Ни pfSense, ни любой другой роутер не обеспечат такой возможности используя механизм port forward, даже если в этом роутере
                  есть возможность выбрать wan-all для прокидывания портов
                  Которая для  для обеспечения отказоустойчивости внешних подключений бесполезна.

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

                    @pigbrother:

                    Такое можно сделать и в pfSense, правда индивидуально для каждого WAN.
                    Но что это даст клиенту?

                    Еще раз.
                    Как клиент узнает, что нужно коннектиться к 2.2.2.2:1000?

                    Если для подключения использовать dns имя, на котором прописаны оба провайдера, то современное ПО пытается разрешать такие проблемы.
                    На крайний случай ведь всегда есть DynDNS.

                    1 Reply Last reply Reply Quote 0
                    • X
                      xxkxx
                      last edited by

                      Есть сервер который принимает сигналы оборудования.
                      На оборудовании забивается два канала основной и резервный. Оборудование 1 передает на primer.ru на порт 1, если не доступен переключается на primer1.ru порт 1.
                      При таком раскладе насколько понимаю главное что бы не менялись адреса привязанные к портам,а источником для сигналов может быть любой интернет провайдер.

                      Спасибо за разъяснения,изначально интересовало,есть ли подобный механизм.Понял что прокинуть порты нужно на два wan интерфейса.

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

                        Доброе
                        2 xxkxx
                        Пакет haproxy-dev\haproxy, но он только для TCP, HTTP и HTTPS.

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

                          На оборудовании забивается два канала основной и резервный. Оборудование 1 передает на primer.ru на порт 1, если не доступен переключается на primer1.ru порт 1.

                          Замечательно, что это предусмотрено изготовителем.

                          источником для сигналов может быть любой интернет провайдер.

                          Да.

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