какой тип МСЭ выбрать?

[komtrud1174]

Здравствуйте, коллеги. У нас в госорганизации возник, как я считаю, весьма сложный и интересный вопрос.

У нас на сервере стоит серверное ПО, к которому подключается вся область средствами випнет. У людей в области стоят VipNet клиенты (в основном версии 3.2 и 4), а у нас программный координатор версии 3.1. Ежедневно подключены и работают одновременно около 150 клиентов.
Возникла необходимость перевести всю инфраструктуру випнет на версию 4.
Важное условие для нас - переходить плавно, незаметно для сотрудников.
1) Сначала мы пошли самым прямым путём. Установили программный координатор на новый железный сервер, подсунули dst-файл и в час X перетыкнули сетевые провода из координатора 3.1 в координатор 4.
Но вот беда, ресурс, к которому подключаются все эти 150 человек, является туннелируемым. Почему? Потому что были советы, что сервер и так весьма сильно нагружен, а установка випнет может ещё больше придушить его возможности.
На программном координаторе 3.1 (не знаю глюк это или норма) это решалось таким образом: 
а) все клиенты в области имеют виртуальные адреса для координатора, допустим с 11.0.0.1 по 11.0.1.255. И на координаторе прописано правило динамического NAT, типа "преобразовать все адреса с 11.0.0.1 по 11.0.1.255 в адрес 192.168.1.7".
б) Естественно туннелируемый ресурс прописан на координаторе 3.1.
Вот такая картина позволяет на сегодняшний день работать всем!
А на координаторе версии 4 возникли сложности типа "у вас не хватает лицензий на туннелирование" (А у нас есть лицензии на 30 туннелей!). Здесь мы имеем два предположения, как трактовать эту ситуацию: а) разработчики "пофиксили" этот баг в версиях выше 3.1 б) мы неправильно настраиваем NAT на координаторе версии 4, потому что там отличается принцип настройки.

2) Вариант с покупкой 100-200 туннелей мы отложили, как самый "лоховский".

3) Затем мы придумали такое решение: программный кординатор остаётся, но также мы подключаем ПАК HW1000 параллельно, который будет туннелировать все ресурсы, потому что мы знаем что ПАК может туннелировать практически без ограничений. Идея нам так понравилась, что мы активно принялись за её реализацию.
Но здесь тоже появились некоторые проблемы. Выбрать тип МСЭ для ПАК можно у нас по разному:
а) с динамической трансляцией, потому что уже есть сервер соединений - программный координатор.
б) тип МСЭ - за координатором, тоже возможно
в) со статической трансляцией, т.е. по такому же принципу, как и программный координатор. А программный координатор настроен так: на границе нашей сети стоит маршрутизатор с белым айпи, например 77.222.3.85 и прописано правило "если приходят пакеты udp у которых порт назначения = 55777, то направить их на программный координатор", ну и разумеется координатор подключен к маршрутизатору и они находятся в одной подсети, например 192.168.200.0/24. Соответственно для ПАК прописали тоже самое, но допустим порт 55796.
Все три варианта работают нестабильно. Самый стабильный был, наверное вариант (б) - за координатором. В чем выражается проблема: 
узел, находящийся в области поначалу видит оба координатора: программный и ПАК, т.е. они "доступны" в разделе "защищенная сеть" клиента. При этом программный координатор исполняет роль сервера соединений, а ПАК туннелирует нужные ресурсы. Как только клиент начинает подключаться к туннелируемым ресурсам, то первые секунд 20 связь всё ещё существует, но потом обрывается и ПАК уже недоступен!
Я читал в документации принцип "общения" узлов сети випнет, сначала они связываются через сервер соединений и первые, скажем так, "несколько пакетов" посылают через сервер соединений, а потом устанавливают связь напрямую, если это возможно. Т.е. интуитивно мой мозг приходит к выводу, что проблема где-то в этом моменте, т.е. первые секунды связь есть, потому что она есть через червер соединений, а в момент, когда предпринимается попытка "общения напрямую" - связь обрывается.
Более подробно я ещё напишу. Думаю, что уже на этом этапе объяснения проблемы, уже возникнет много тривиальных ответов.

[rfvbk]

21 час назад, komtrud1174 сказал:

Естественно туннелируемый ресурс прописан на координаторе 3.1.
Вот такая картина позволяет на сегодняшний день работать всем!
А на координаторе версии 4 возникли сложности типа "у вас не хватает лицензий на туннелирование" (А у нас есть лицензии на 30 туннелей!). Здесь мы имеем два предположения, как трактовать эту ситуацию: а) разработчики "пофиксили" этот баг в версиях выше 3.1 б) мы неправильно настраиваем NAT на координаторе версии 4, потому что там отличается принцип настройки.

А вы через веб интерфейс не пробовали прописать туннели и нат( и транзитные фильтры)? там интуитивно всё понятно. Я так понимаю что 30 лицензий это лицензии на 30 туннелируемых ресурсов(грубо говоря на 30 серваков в вашей сети), а не на 30 подключений(клиентов). Возможно я не прав.

ПС Это вроде не баг, так задумано. Я и на 3 версии делал и на 4 делаю.

[rfvbk]

21 час назад, komtrud1174 сказал:

Затем мы придумали такое решение: программный кординатор остаётся, но также мы подключаем ПАК HW1000 параллельно, который будет туннелировать все ресурсы, потому что мы знаем что ПАК может туннелировать практически без ограничений. Идея нам так понравилась, что мы активно принялись за её реализацию.

А зачем это всё? может проще заменить программный на hw1000, раз он у вас в наличии?

[zero]

В 28.03.2018 в 15:15, komtrud1174 сказал:

Как только клиент начинает подключаться к туннелируемым ресурсам, то первые секунд 20 связь всё ещё существует, но потом обрывается и ПАК уже недоступен!

 Смотрите журналы пакетов, куда идёт трафик, настройки на клиенте и координаторах, скорее всего настроили неправильно свой пограничный МЭ или в сети кольца. Но тут без схемы и полных конфигов с журналами пакетов никто не поможет. Тем более сетевые проблемы не решить настройкой типа МЭ на координаторе.