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

    Приоритет маршрутизации

    Scheduled Pinned Locked Moved Russian
    17 Posts 4 Posters 1.4k 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 @Konstanti
      last edited by werter

      Добрый
      @konstanti
      Можно подробнее по вашей схеме? Как это поможет ТС?

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

        @alex82
        Предложу еще вариант.

        Если железо норм (от 8гб ОЗУ и 2+ диска), то:

        • развернул на обоих сперва proxmox ve (на zfs);
        • на основном поднял в вирт. машине (ВМ) пф;
        • настроил репликацию по расписанию ВМ с пф на резервный.

        Итого. Имеем свежую копию ВМ с пф на резервной железке.
        Если надумаете, контакты в ЛС.

        D 1 Reply Last reply Reply Quote 0
        • K
          Konstanti @werter
          last edited by Konstanti

          @werter

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

          так как у ТС сейчас схема с IPSEC туннелями ,то можно от них отказаться в пользу динамической маршрутизации на основе протокола OSPF ( GRE over IPSEC + OSPF) .

          Резервный выделенный маршрутизатор (backup designated 
          router, BDR). Каждый маршрутизатор сети устанавливает 
          отношения соседства не только с DR, но и BDR. DR и BDR 
          также устанавливают отношения соседства и между собой. 
          При выходе из строя DR, BDR становится DR и выполняет все 
          его функции. Так как маршрутизаторы сети установили 
          отношения соседства с BDR, время недоступности сети 
          минимизируется.
          
          
          werterW D 2 Replies Last reply Reply Quote 0
          • werterW
            werter @Konstanti
            last edited by werter

            Добрый
            @konstanti
            Тогда ему на резервном пф в Головном офисе понадобится ВАН + и постоянно поднятые линки от филиалов и до Основного и до Резервного пф-ов. Плюс настройка ospf на каждом из пф в Филиалах.
            Похожая схема у меня была.
            Но есть нюанс.
            Резервный пф в Головном офисе должен быть еще и роутером для внутренней сети, а не только впн-хабом для филиальных пф. И вот тут без CARP не обойтись, но CARP усложнит и без того непростую схему.

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

              @alex82
              Вы ЛС читаете хоть иногда?

              1 Reply Last reply Reply Quote 0
              • D
                dave.opc @werter
                last edited by

                @werter
                Сейчас на обоих серверах pfsense поднят в виртуализации.
                Идея с репликацией не подходит, потому что оба pfsense должны быть запущены. К тому же скопированную репликацией машину не получится запустить без танцев, так как отличаются конфиги хостов, отличаются внутренние настройки сетей, отличаются wan адреса и т.д.

                1 Reply Last reply Reply Quote 0
                • D
                  dave.opc @Konstanti
                  last edited by

                  @konstanti
                  идея состоит в том, чтобы иметь резервный канал у другого провайдера, в другом расположении, а не ставить второй маршрутизатор в точке hub1

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    Konstanti @dave.opc
                    last edited by

                    @dave-opc

                    Понятно
                    и чем мое предложение в данном случае не подходит ?

                    К каждому офису настраивается 2 маршрутизируемых туннеля через каждого провайдера ( с приоритетом для основного канала ) .

                    В случае отказа основного канала , весь трафик начинает идти через резервный ( тут идея в том , что Вы отказываетесь от статической маршрутизации и от классического IPSEC в пользу динамической )

                    A 1 Reply Last reply Reply Quote 0
                    • A
                      alex82 @Konstanti
                      last edited by

                      @konstanti Ну вообще изначально вопрос был на самом деле больше в том, вообще реализуемо ли то что мы хотим в рамках текущей схемы. :)
                      А так да, всю схему если переделывать то видимо разные варианты есть, как я понял.
                      Но честно говоря уже устоявшуюся, рабочую и понятную схему не хотелось бы конечно трогать, тем более, что практически нет окон для прерывания работы если что...

                      K 1 Reply Last reply Reply Quote 0
                      • K
                        Konstanti @alex82
                        last edited by

                        @alex82
                        Я - не эксперт в ядре FreeBSD , но не совсем понимаю , как могут сосуществовать одновременно 2 IPsec туннеля с одинаковыми селекторами трафика ( насколько я понимаю , Ваша схема предполагает именно такой вариант для доп офисов). Те непонятно , в какой туннель будет отправлен тот или иной пакет

                        A 1 Reply Last reply Reply Quote 0
                        • A
                          alex82 @Konstanti
                          last edited by

                          @konstanti Ну это то да, вот как раз и хотелось понять, возможно как то это реализовать при текущей схеме или нет.

                          Кстати вроде бы нормально все работает, когда два тоннеля от удаленного PF одновременно подключены к хабу через двух провайдеров (ну на хабе соответственно тоже для них два ip) , если один отваливается то работает через второй. Хотя я в процессе работы особо хождение трафика не смотрел, может он и по одному и по второму гоняет, но вроде на работе это не сказывается :)

                          K werterW 2 Replies Last reply Reply Quote 0
                          • K
                            Konstanti @alex82
                            last edited by Konstanti

                            @alex82
                            Боюсь, что нет в Вашем конкретном случае . Поясню, почему так думаю. IPsec -достаточно сложная технология , работающая одновременно с множеством переменных на уровне ядра и реализовать кластеризацию непросто . У StrongSwan есть plug-in HA к, который предназначен для решения данной задачи
                            Но , есть 2 нюанса
                            1 strongswan должен быть собран с поддержкой этого модуля
                            2 эта технология реализована в ядре Linux

                            Я бы , на Вашем месте , все-таки задумался о том , о чем я писал ранее. Плюсом , можно об’единить офисы такими же туннелями , если в этом есть необходимость и не гонять трафик через центральный хаб

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

                              Добрый
                              @alex82
                              Я сперва неверно понял. Подумал, что резервный пф должен выполнять не только роль впн-сервера, но и роль марш-ра в ЦО.
                              Перечитал дальнейшее общение.
                              Схема ув. @konstanti с ospf в таком случае более чем жизнеспособна:

                              • поднимите на каждом из пф Филиалов по 2 ipsec vti-туннеля к обоим пф в ЦО;
                              • настройте ospf с этими туннелями.

                              Получите динамическое переключение с одного туннеля на др в случае падения.
                              У меня подобное работает на ovpn. Только не стал заморачиваться с 2-мя пф-а в ЦО, а просто завел 2-го провайдера на пф в ЦО и настроил связку ovpn + ospf.
                              Работает более 3-х лет.

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