Настройка Vipnet Hw1000- Смена Канала Связи При Пропадании Одного Из Каналов Связи

[BitHunter]

Доброго времени суток!

Имеются:

1. ViPNet Coordinator HW 1000.

2. Сервер базы данных во внутренней сети (за ViPNet Coordinator HW 1000).

3. Два канала связи с двумя разными провайдерами- основной и резервный.

4. Туннели по которым удаленные клиенты обращаются к серверу во внутренней сети.

Задача:

1. Настроить ViPNet Coordinator HW 1000 таким образом, что бы при пропадании основного канала связи ViPNet Coordinator HW 1000 автоматически переключался на резервный.

Вопрос в следующем:

1. Каким образом настроить ViPNet Coordinator HW 1000 (если такое вообще возможно)

2. Как поведут себя ViPNet клиенты во внутренней сети и во внешней, сохранится ли связь, или придется перенастраивать всё вручную.

3. Как поведут себя туннели до сервера.

[BitHunter]

Приветствую!

Всем спасибо за активное участие в решении проблемы. Решилась проблема следующим образом. Два координатора были соединены в кластер failover (это конечно же побочная задача, по отношению к резервированию.) И было просто подключено по два канала связи к обоим координаторам, единственная проблема возникла с белыми IP адресами- для работы кластера нужно было по три белых IP от каждого провайдера. Далее, что бы не запариваться с метриками (так как кластер виден по двум белым IP и какой будет выбран это большой вопрос), резервный канал был отключен (просто отключен порт), а также настроено информирование о пропадании канала связи.

Переключение на резервный канал осуществляется в ручном режиме.

То есть логика какая... координатор в любом случае виден по обоим IP адресам, а удаленные клиенты работают с сервером по через туннель (либо по виртуальному IP, либо по реальному- разницы я так понял нет- всё равно связующее звено (удаленный координатор) знает все IP адреса нужного координатора). Смена канала на стороне клиента идёт автоматом- не доступен по одному IP, идёт попытка подключения через другой.

Может кому будет интересно.

[AnTonN(c)]

Приветствую!

Всем спасибо за активное участие в решении проблемы. Решилась проблема следующим образом. Два координатора были соединены в кластер failover (это конечно же побочная задача, по отношению к резервированию.) И было просто подключено по два канала связи к обоим координаторам, единственная проблема возникла с белыми IP адресами- для работы кластера нужно было по три белых IP от каждого провайдера. Далее, что бы не запариваться с метриками (так как кластер виден по двум белым IP и какой будет выбран это большой вопрос), резервный канал был отключен (просто отключен порт), а также настроено информирование о пропадании канала связи.

Переключение на резервный канал осуществляется в ручном режиме.

То есть логика какая... координатор в любом случае виден по обоим IP адресам, а удаленные клиенты работают с сервером по через туннель (либо по виртуальному IP, либо по реальному- разницы я так понял нет- всё равно связующее звено (удаленный координатор) знает все IP адреса нужного координатора). Смена канала на стороне клиента идёт автоматом- не доступен по одному IP, идёт попытка подключения через другой.

Может кому будет интересно.

HW не имеет функционала переключения канала. Только вручную. Можно конечно порт сразу настроить на "резерв" и положить его в down и при необходимости поднимать его. Также ее забудьте про маршрут по умолчанию при переключении!!!

...единственная проблема возникла с белыми IP адресами...

Для таких случаев есть выход. Описывать здесь не буду, но в последней версии документации на HW (2.3) есть пункт "Схема организации кластера горячего резервирования в условиях ограничений по выделению IP-адресов", который решит проблему выделения адресного пространства для failover. Единственная проблема при этом то, что failover пока нельзя поднять на алисасах, но это будет реализовано в 2.4.

...координатор в любом случае виден по обоим IP адресам...

Выставите в ЦУС ip-адреса доступа для Координатора: ip-адреса:ПОРТ. То есть у вас будут две сточки для доступа к координатору и эта информация попадет к клиенту через dst или справочники. Если будет недоступен "верхний" firewallip, то по timeout (по-моему 3 минуты), будет использоваться "нижний" и так далее.

...удаленные клиенты работают с сервером по через туннель (либо по виртуальному IP, либо по реальному- разницы я так понял нет...

С Клиента туннелируемый ресурс ВСЕГДА виден только под одним адресом либо реальным, либо виртуальным, и, как вы заметили раньше, разницы нет)), но это надо помнить...

[BitHunter]

HW не имеет функционала переключения канала. Только вручную. Можно конечно порт сразу настроить на "резерв" и положить его в down и при необходимости поднимать его. Также ее забудьте про маршрут по умолчанию при переключении!!!

Нам он в принципе и не нужен- кластер будет юзаться только для шифрованного трафика.

...единственная проблема возникла с белыми IP адресами...

Для таких случаев есть выход. Описывать здесь не буду, но в последней версии документации на HW (2.3) есть пункт "Схема организации кластера горячего резервирования в условиях ограничений по выделению IP-адресов", который решит проблему выделения адресного пространства для failover. Единственная проблема при этом то, что failover пока нельзя поднять на алисасах, но это будет реализовано в 2.4.

Будем ждать обновления, пригодится.

...координатор в любом случае виден по обоим IP адресам...

Выставите в ЦУС ip-адреса доступа для Координатора: ip-адреса:ПОРТ. То есть у вас будут две сточки для доступа к координатору и эта информация попадет к клиенту через dst или справочники. Если будет недоступен "верхний" firewallip, то по timeout (по-моему 3 минуты), будет использоваться "нижний" и так далее.

Это то сделано в первую очередь, вместе с туннелями

...удаленные клиенты работают с сервером по через туннель (либо по виртуальному IP, либо по реальному- разницы я так понял нет...

С Клиента туннелируемый ресурс ВСЕГДА виден только под одним адресом либо реальным, либо виртуальным, и, как вы заметили раньше, разницы нет)), но это надо помнить...

Если не запоминается никто не мешает записать