Приоритет маршрутизации
-
Добрый
@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-х лет.
