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

    Два WAN с одним и тем же шлюзом

    Scheduled Pinned Locked Moved Russian
    14 Posts 6 Posters 4.5k 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.
    • werterW
      werter
      last edited by

      Пробуйте, должно работать.

      1 Reply Last reply Reply Quote 0
      • Q
        QWERTik
        last edited by

        Забыл указать, что это 2 х ПППоЕ.

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

          У вас один и тот же провайдер на обоих WAN?

          1 Reply Last reply Reply Quote 0
          • Q
            QWERTik
            last edited by

            Да. И выдаёт хоть и разные подсети, но общий шлюз. Отсюда и сомнение, будет ли такая связка работать в pfsense.

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

              Как вариант - мониторить тот же 8.8.8.8 в кач-ве адреса для failover на обоих интерфейсах.

              P.s. А какой смысл иметь два канала у одного и того же пров-ра? В кач-ве failover - оч. сомнительно. Разве что типы подключения разные (ethernet и wi-fi, например).

              1 Reply Last reply Reply Quote 0
              • N
                netormoz
                last edited by

                @QWERTik:

                Вопрос к гуру: научился ли pfsense 2.0.3 разруливать два WAN подключения (подсети разные), имеющие общий шлюз, т.е. балансировка и отказоустойчивость? Более ранние версии, вроде как не умели.

                У меня вопрос ламмера!!!  как это машины из разных посетей на один шлюз ходят? У шлюза маска шире масок хостов?

                1 Reply Last reply Reply Quote 0
                • W
                  WY6EPT
                  last edited by

                  я кстати таким же вопросом задаюсь- как они это делают?

                  я в рртр так же хочу со статику из одной подсети, динамику из родной.

                  поидее это приколюхи именно тоннельных соединений. сегодня попробую.

                  Авопрос автор задавал из соображений расширить каналю, подозреваю.

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

                  1 Reply Last reply Reply Quote 0
                  • Q
                    QWERTik
                    last edited by

                    Да, именно для расширения полосы, хотя бывает и они придурковывают, так что, фэйловер к ним то же актуален, от того и задал вопрос.
                    2 netormoz:
                    А всё выглядит так: это 2 адсл (pppoe) канала от РТ, белые адреса вида a.b.c.d/24 и a.b.e.f./24, при этом шлюз g.h.i.j. Прикольно, правда? Так что, как то маршрутизируют, а у меня от этого головная боль. Сейчас у меня на шлюзе стоит китайская железка, которая разруливает это дело не задавая вопросов (модемы в режиме моста, ПППоЕ сессию поднимает и контролирует сама). Но она офигенно тупенькая во всём остальном, да и с приходом 100 Мбит/с канала, со всем этим ей уже не справиться - решил менять на сенс.

                    1 Reply Last reply Reply Quote 0
                    • R
                      rubic
                      last edited by

                      @netormoz:

                      У меня вопрос ламмера!!!  как это машины из разных посетей на один шлюз ходят? У шлюза маска шире масок хостов?

                      В соединениях точка-точка понятие маски подсети не имеет смысла. Если вы попробуете настроить PPPoE сервер на pfSense, то увидите, что адрес шлюза отдаваемый клиентам - это просто собственный адрес pfSense на lo0 интерфейсе, который вам предстоит выдумать в ходе настройки (Server address) и который не должен совпадать ни с одним другим адресом настроенным на pfSense, а так же ни с одним из адресов PPPoE клиентов. Провайдер же просто берет неиспользуемый адрес из своего диапазона и назначает его PPPoE серверу.

                      1 Reply Last reply Reply Quote 0
                      • N
                        netormoz
                        last edited by

                        @QWERTik:

                        Да, именно для расширения полосы, хотя бывает и они придурковывают, так что, фэйловер к ним то же актуален, от того и задал вопрос.
                        2 netormoz:
                        А всё выглядит так: это 2 адсл (pppoe) канала от РТ, белые адреса вида a.b.c.d/24 и a.b.e.f./24, при этом шлюз g.h.i.j. Прикольно, правда? Так что, как то маршрутизируют, а у меня от этого головная боль. Сейчас у меня на шлюзе стоит китайская железка, которая разруливает это дело не задавая вопросов (модемы в режиме моста, ПППоЕ сессию поднимает и контролирует сама). Но она офигенно тупенькая во всём остальном, да и с приходом 100 Мбит/с канала, со всем этим ей уже не справиться - решил менять на сенс.

                        Ethernet порт к провайдеру один или два?

                        1 Reply Last reply Reply Quote 0
                        • N
                          netormoz
                          last edited by

                          @rubic:

                          @netormoz:

                          У меня вопрос ламмера!!!  как это машины из разных посетей на один шлюз ходят? У шлюза маска шире масок хостов?

                          В соединениях точка-точка понятие маски подсети не имеет смысла. Если вы попробуете настроить PPPoE сервер на pfSense, то увидите, что адрес шлюза отдаваемый клиентам - это просто собственный адрес pfSense на lo0 интерфейсе, который вам предстоит выдумать в ходе настройки (Server address) и который не должен совпадать ни с одним другим адресом настроенным на pfSense, а так же ни с одним из адресов PPPoE клиентов. Провайдер же просто берет неиспользуемый адрес из своего диапазона и назначает его PPPoE серверу.

                          Просмотрел я про ppoe когда спрашивал. тогда все ясно

                          1 Reply Last reply Reply Quote 0
                          • N
                            nomeron
                            last edited by

                            Не будет эта схема работать. Подключения поднимутся, но трафик будет идти по одному.
                            Но у RT могут быть разные шлюзы, если выдается несколько пулов адресов.
                            Еще придется физически делить подключения. У PF прекрасно получается затрамбовать два ПППоЕ в один модем в бридже.
                            И если поднят Captive Portal, то он на L2 пропускает ПППоЕ от пользователей через NAT и у сильно умных получаются петли.

                            1 Reply Last reply Reply Quote 0
                            • Q
                              QWERTik
                              last edited by

                              @netormoz:

                              @QWERTik:

                              Да, именно для расширения полосы, хотя бывает и они придурковывают, так что, фэйловер к ним то же актуален, от того и задал вопрос.
                              2 netormoz:
                              А всё выглядит так: это 2 адсл (pppoe) канала от РТ, белые адреса вида a.b.c.d/24 и a.b.e.f./24, при этом шлюз g.h.i.j. Прикольно, правда? Так что, как то маршрутизируют, а у меня от этого головная боль. Сейчас у меня на шлюзе стоит китайская железка, которая разруливает это дело не задавая вопросов (модемы в режиме моста, ПППоЕ сессию поднимает и контролирует сама). Но она офигенно тупенькая во всём остальном, да и с приходом 100 Мбит/с канала, со всем этим ей уже не справиться - решил менять на сенс.

                              Ethernet порт к провайдеру один или два?

                              Два.

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