Резервирование связи между 3 и более филиалами

[nucleon]

Имеются 3 работающих удаленных друг от друга филиала одной организации...
планируется объединить их через OpenVPN
попутно встает вопрос резервирования связи филлиалов между собой...

                 локальный;  внешний;
Филиал А - 192.168.1.1; xxx.xxx.xxx.xxx;
Филиал B - 192.168.2.1; yyy.yyy.yyy.yyy;
Филиал C - 192.168.3.1; zzz.zzz.zzz.zzz;

хочется организовать связь таким образом, чтобы в случае, если связь между xxx.xxx.xxx.xxx и yyy.yyy.yyy.yyy обрывалась, трафик между ними шел через шлюз zzz.zzz.zzz.zzz...
ну и собственно аналогично для других филиалов также

Вопрос как это делать?

я предполагал, что для этого необходимо будет поднять на всех шлюзах по 2 интерфейса tun/tap; т.е. подключить независимо друг от друга каждый филиал к двум другим...
но вот дальше необходимо как-то настроить автоматическое переключение трафика от одного интерфейса на другой, а на соответствующем шлюзе автоматическое добавление маршрута...

но может быть умные головы уже придумали более элегантное решение? через агрегацию сетевых интерфейсов  к примеру?

[xeon_greg]

это все есть в стандартных средствах openvpn указываешь несколько серверов на каждом из клиентов, как только свзяь с одним потеряется он сам переконнектится к другому ну а маршрутизация тоже описываетсяв самом openvpn конфигах каждого сервера

[nucleon]

а можно немножко более подробно, или ссылочку на пример

[xeon_greg]

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

[nucleon]

это я знаю...
меня интересует сама реализация ...

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

просто если не возвращать в исходное состояние, может быть ситуация при которой при двух последовательных сбоях трафик будут гонять через 2ной ВПН оба филиала

[shumtest]

Да все легко и просто.
У меня так: ВПНы поднимаются через ппп, потому

/etc/ppp/ip-down.d/z-z-z

скрипт который проверят что его вызвали из-за падения впн1 и поднимает впн2. ну и еще зуммер включает, отсюда название

/etc/ppp/ip-up.d/stop-z-z-z

скрипт который проверяет что его вызвали при поднятии впн1 и отключает впн2. ну и зуммер выключает тоже

впн1 и впн2 настроены с опциями defaultroute и replacedefaultroute

[fisher74]

Вмешаюсь в дисскуссию с вопросом: А то что филиалы В и С сетками пересекаются - не рассматривается?

[nucleon]

Вмешаюсь в дисскуссию с вопросом: А то что филиалы В и С сетками пересекаются - не рассматривается?

поясни пожалуйста

[Гарри Кашпировский]

поясни пожалуйста

Филиал B - 192.168.2.1; yyy.yyy.yyy.yyy;
Филиал C - 192.168.2.1; zzz.zzz.zzz.zzz;

[nucleon]

а сори тут опечатка... Филиал C - 192.168.3.1; zzz.zzz.zzz.zzz;

[fisher74]

Что-то как-то сложно...

Я бы, наверное, просто в каждом оффисе добавил бы по одному маршруту на каждую соседнюю сеть с толстой метрикой через другого соседа.
Если линк на соседа есть, то отрабатывает более короткая метрика. Линк падает - короткий маршрут игнорируется и выбирается более длинный путь.
Пользователь решил продолжить мысль 18 Марта 2011, 17:01:10:А можно и более красивше и интересатее (хоть и заморочнее) использовать динамическую маршрутизацию, например RIP или OSPF

[nucleon]

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

А можно и более красивше и интересатее (хоть и заморочнее) использовать динамическую маршрутизацию, например RIP или OSPF

а по подробнее можно?... первый вариант

[shumtest]

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

Тоже хороший вариант, но в этом случае придется постоянно держать поднятыми резервные каналы. В некоторых случаях может быть неприемлемо.

[antaeus]

еще можно использовать vtun или eoip (собирается под линукс), соединяешь все между собой, выставляешь метрики на статические маршруты и все.

[drako]

Что-то как-то сложно...

Я бы, наверное, просто в каждом оффисе добавил бы по одному маршруту на каждую соседнюю сеть с толстой метрикой через другого соседа.
Если линк на соседа есть, то отрабатывает более короткая метрика. Линк падает - короткий маршрут игнорируется и выбирается более длинный путь.
Пользователь решил продолжить мысль 18 Марта 2011, 17:01:10:А можно и более красивше и интересатее (хоть и заморочнее) использовать динамическую маршрутизацию, например RIP или OSPF

Поддерживаю, только сделал бы все на ipsec, будет больше пространства в выборе "железа".