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

alex82

@werter
Центральный HUB на виртуалке.
Остальные, какие то тоже виртуалки, какие то железки (просто комп)
Резервный тоже виртуалка, но совсем в другом расположении от основного.
Я так понимаю, что тут CARP не особо как то...
Ну и видимо если других инструментов нет, то просто иметь резервный настроенный и если надо просто его включить, или точнее активировать тоннели.

Konstanti

@alex82

Здр

Я бы , на Вашем месте , рассмотрел вариант, например ,
GRE over IPSec + OSPF

werter

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

werter

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

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

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

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

Konstanti

@werter

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

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

Резервный выделенный маршрутизатор (backup designated 
router, BDR). Каждый маршрутизатор сети устанавливает 
отношения соседства не только с DR, но и BDR. DR и BDR 
также устанавливают отношения соседства и между собой. 
При выходе из строя DR, BDR становится DR и выполняет все 
его функции. Так как маршрутизаторы сети установили 
отношения соседства с BDR, время недоступности сети 
минимизируется.

werter

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

werter

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

dave.opc

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

dave.opc

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

Konstanti

@dave-opc

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

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

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

alex82

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

Konstanti

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

alex82

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

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

Konstanti

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

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

werter

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

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

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