Приоритет маршрутизации
-
Есть такая схема сети.
Центральный в качестве главного фаервола где все правила кому, куда и что. Плюс там же еще OVPN клиенты, для них правила там же.
По тоннелям проброшены все сети соответсвенно.Хотелось бы сделать резервный центральный хаб с такой же схемой и чтобы он тоже постоянно работал, если что с первым то сразу трафик ходил бы по второму.
Но сейчас проблема, он кидает трафик то через один то через другой, причем частично может что-то через один, что-то через другой и постоянно то одни сервисы начинают отваливаться, то другие.
Пока его настроили так же как первый и тоннели выключили.Можно как то реализовать какой то приоритет использования?
Чтобы через второй трафик ходил только если первый недоступен?Да, на схеме везде офисы указаны, как pfSense, но есть и другие роутеры, где всего одна сеть в тоннеле.
Ну, а пока, вариант просто есть резервный готовый, если что на нем просто можно тоннели поднять вручную, это в общем то не долго.
-
@alex82
CARP в оф доке.
Но я бы не усложнял схему с кластеризацией без особой надобности.
На чем у вас пф живет? -
@werter
Центральный HUB на виртуалке.
Остальные, какие то тоже виртуалки, какие то железки (просто комп)
Резервный тоже виртуалка, но совсем в другом расположении от основного.
Я так понимаю, что тут CARP не особо как то...
Ну и видимо если других инструментов нет, то просто иметь резервный настроенный и если надо просто его включить, или точнее активировать тоннели. -
-
Добрый
@konstanti
Можно подробнее по вашей схеме? Как это поможет ТС? -
@alex82
Предложу еще вариант.Если железо норм (от 8гб ОЗУ и 2+ диска), то:
- развернул на обоих сперва proxmox ve (на zfs);
- на основном поднял в вирт. машине (ВМ) пф;
- настроил репликацию по расписанию ВМ с пф на резервный.
Итого. Имеем свежую копию ВМ с пф на резервной железке.
Если надумаете, контакты в ЛС. -
Хотелось бы сделать резервный центральный хаб с такой же схемой и чтобы он тоже постоянно работал, если что с первым то сразу трафик ходил бы по второму.
так как у ТС сейчас схема с IPSEC туннелями ,то можно от них отказаться в пользу динамической маршрутизации на основе протокола OSPF ( GRE over IPSEC + OSPF) .
Резервный выделенный маршрутизатор (backup designated router, BDR). Каждый маршрутизатор сети устанавливает отношения соседства не только с DR, но и BDR. DR и BDR также устанавливают отношения соседства и между собой. При выходе из строя DR, BDR становится DR и выполняет все его функции. Так как маршрутизаторы сети установили отношения соседства с BDR, время недоступности сети минимизируется.
-
Добрый
@konstanti
Тогда ему на резервном пф в Головном офисе понадобится ВАН + и постоянно поднятые линки от филиалов и до Основного и до Резервного пф-ов. Плюс настройка ospf на каждом из пф в Филиалах.
Похожая схема у меня была.
Но есть нюанс.
Резервный пф в Головном офисе должен быть еще и роутером для внутренней сети, а не только впн-хабом для филиальных пф. И вот тут без CARP не обойтись, но CARP усложнит и без того непростую схему. -
@alex82
Вы ЛС читаете хоть иногда? -
@werter
Сейчас на обоих серверах pfsense поднят в виртуализации.
Идея с репликацией не подходит, потому что оба pfsense должны быть запущены. К тому же скопированную репликацией машину не получится запустить без танцев, так как отличаются конфиги хостов, отличаются внутренние настройки сетей, отличаются wan адреса и т.д. -
@konstanti
идея состоит в том, чтобы иметь резервный канал у другого провайдера, в другом расположении, а не ставить второй маршрутизатор в точке hub1 -
Понятно
и чем мое предложение в данном случае не подходит ?К каждому офису настраивается 2 маршрутизируемых туннеля через каждого провайдера ( с приоритетом для основного канала ) .
В случае отказа основного канала , весь трафик начинает идти через резервный ( тут идея в том , что Вы отказываетесь от статической маршрутизации и от классического IPSEC в пользу динамической )
-
@konstanti Ну вообще изначально вопрос был на самом деле больше в том, вообще реализуемо ли то что мы хотим в рамках текущей схемы. :)
А так да, всю схему если переделывать то видимо разные варианты есть, как я понял.
Но честно говоря уже устоявшуюся, рабочую и понятную схему не хотелось бы конечно трогать, тем более, что практически нет окон для прерывания работы если что... -
@alex82
Я - не эксперт в ядре FreeBSD , но не совсем понимаю , как могут сосуществовать одновременно 2 IPsec туннеля с одинаковыми селекторами трафика ( насколько я понимаю , Ваша схема предполагает именно такой вариант для доп офисов). Те непонятно , в какой туннель будет отправлен тот или иной пакет -
@konstanti Ну это то да, вот как раз и хотелось понять, возможно как то это реализовать при текущей схеме или нет.
Кстати вроде бы нормально все работает, когда два тоннеля от удаленного PF одновременно подключены к хабу через двух провайдеров (ну на хабе соответственно тоже для них два ip) , если один отваливается то работает через второй. Хотя я в процессе работы особо хождение трафика не смотрел, может он и по одному и по второму гоняет, но вроде на работе это не сказывается :)
-
@alex82
Боюсь, что нет в Вашем конкретном случае . Поясню, почему так думаю. IPsec -достаточно сложная технология , работающая одновременно с множеством переменных на уровне ядра и реализовать кластеризацию непросто . У StrongSwan есть plug-in HA к, который предназначен для решения данной задачи
Но , есть 2 нюанса
1 strongswan должен быть собран с поддержкой этого модуля
2 эта технология реализована в ядре LinuxЯ бы , на Вашем месте , все-таки задумался о том , о чем я писал ранее. Плюсом , можно об’единить офисы такими же туннелями , если в этом есть необходимость и не гонять трафик через центральный хаб
-
Добрый
@alex82
Я сперва неверно понял. Подумал, что резервный пф должен выполнять не только роль впн-сервера, но и роль марш-ра в ЦО.
Перечитал дальнейшее общение.
Схема ув. @konstanti с ospf в таком случае более чем жизнеспособна:- поднимите на каждом из пф Филиалов по 2 ipsec vti-туннеля к обоим пф в ЦО;
- настройте ospf с этими туннелями.
Получите динамическое переключение с одного туннеля на др в случае падения.
У меня подобное работает на ovpn. Только не стал заморачиваться с 2-мя пф-а в ЦО, а просто завел 2-го провайдера на пф в ЦО и настроил связку ovpn + ospf.
Работает более 3-х лет.