Jump to content

Recommended Posts

Есть две локальных сети. В ЛВС1 (172.23.*.*) более 500 клиентов, в ЛВС2(192.168.*.*) – только 30.

В каждой сети есть туннелируемые ресурсы:

1. ЛВС1: контроллер домена и несколько других незащищенных VipNet`ом ресурсов;

2. ЛВС2: два сервера, несколько незащищенных VipNet`ом ПК.

Чтобы все клиенты ЛВС2 видели контроллер домена, необходимо в свойствах туннелирующего координатора (Координатор1) указать его ip.

Чтобы сервера ЛВС2 увидели контроллер домена, необходимо вторым координатором туннелировать эти сервера.

Организовать доступ серверам второй ЛВС к контроллеру домена не проблема: если прописать в ЦУСе туннели для Координатора2, все клиенты ЛВС 2 будут ходить на сервера через этот координатор.

Организовать доступ к контроллеру домена для клиентов ЛВС2 оказалось сложнее: если для Координатора1 указать туннелируемые ресурсы (ip контроллера домена), все клиенты ЛВС1 сразу начнут ходить к контроллеру домена через этот координатор. Проблема в том, что нагрузка на него резко возрастет и надежность сети вообще резко снизится.

Как временное решение прописали туннели на всех VipNet клиентах в ЛВС2.

Появляется вопрос: как организовать взаимодействие сетей ЛВС1 и ЛВС2, чтобы не пришлось прописывать ip-адреса туннелируемых ресурсов вручную? И есть ли решение без ввода в работу дополнительного координатора?

VipNet.jpg

Share this post


Link to post
Share on other sites

Есть две локальных сети. В ЛВС1 (172.23.*.*) более 500 клиентов, в ЛВС2(192.168.*.*) – только 30.

В каждой сети есть туннелируемые ресурсы:

1. ЛВС1: контроллер домена и несколько других незащищенных VipNet`ом ресурсов;

2. ЛВС2: два сервера, несколько незащищенных VipNet`ом ПК.

Чтобы все клиенты ЛВС2 видели контроллер домена, необходимо в свойствах туннелирующего координатора (Координатор1) указать его ip.

Чтобы сервера ЛВС2 увидели контроллер домена, необходимо вторым координатором туннелировать эти сервера.

Организовать доступ серверам второй ЛВС к контроллеру домена не проблема: если прописать в ЦУСе туннели для Координатора2, все клиенты ЛВС 2 будут ходить на сервера через этот координатор.

Организовать доступ к контроллеру домена для клиентов ЛВС2 оказалось сложнее: если для Координатора1 указать туннелируемые ресурсы (ip контроллера домена), все клиенты ЛВС1 сразу начнут ходить к контроллеру домена через этот координатор. Проблема в том, что нагрузка на него резко возрастет и надежность сети вообще резко снизится.

Как временное решение прописали туннели на всех VipNet клиентах в ЛВС2.

Появляется вопрос: как организовать взаимодействие сетей ЛВС1 и ЛВС2, чтобы не пришлось прописывать ip-адреса туннелируемых ресурсов вручную? И есть ли решение без ввода в работу дополнительного координатора?

VipNet.jpg

Если у Вас огромная нагрузка на координатор получается, то есть решение - VipNet Cluster. Напрямую без координатора могут себе позволить обмениваться узлы с VipNet Client в одной ЛВС (второй вариант решения проблемы, но дорогой и неоправданный). Что касается туннелируемых узлов, то у них шлюз - координатор. Вы, конечно, можете прописать иные маршруты, но на 500 компьютерах это делать, мягко говоря, неинтересно. Не знаю как у Вас построена ЛВС, но это можно сделать не на каждом компьютере, а на маршрутизаторах, чтобы трафик на Вас контроллер домена шёл без петли на координатор (третий вариант решения проблемы).

Немного не понял про прописывание туннелируемых адресов вручную. Это же делается в ЦУСе, где можно задать диапазон адресов сразу и разослать просто справочники с таблицами машрутизации на координаторы.

И, кстати, если у Вас контроллер домена находится в той же подсети и не выделен физически канал к нему, то через координатор (шлюз) трафик идти и не должен. Всё-таки более подробно схему нарисуйте.

Share this post


Link to post
Share on other sites

Если у Вас огромная нагрузка на координатор получается, то есть решение - VipNet Cluster. Напрямую без координатора могут себе позволить обмениваться узлы с VipNet Client в одной ЛВС (второй вариант решения проблемы, но дорогой и неоправданный). Что касается туннелируемых узлов, то у них шлюз - координатор. Вы, конечно, можете прописать иные маршруты, но на 500 компьютерах это делать, мягко говоря, неинтересно. Не знаю как у Вас построена ЛВС, но это можно сделать не на каждом компьютере, а на маршрутизаторах, чтобы трафик на Вас контроллер домена шёл без петли на координатор (третий вариант решения проблемы).

Немного не понял про прописывание туннелируемых адресов вручную. Это же делается в ЦУСе, где можно задать диапазон адресов сразу и разослать просто справочники с таблицами машрутизации на координаторы.

И, кстати, если у Вас контроллер домена находится в той же подсети и не выделен физически канал к нему, то через координатор (шлюз) трафик идти и не должен. Всё-таки более подробно схему нарисуйте.

В том-то и проблема, что если прописать все туннелируемые ресурсы для VipNet Координатор1 в ЦУСе, тогда все клиенты (и в ЛВС1 в том числе) будут ходить через этот координатор. Этого-то мы и пытаемся избежать: чтобы клиенты ЛВС1 "общались" с контроллером домена без участия Координатора1, по открытой сети.

Share this post


Link to post
Share on other sites

В том-то и проблема, что если прописать все туннелируемые ресурсы для VipNet Координатор1 в ЦУСе, тогда все клиенты (и в ЛВС1 в том числе) будут ходить через этот координатор. Этого-то мы и пытаемся избежать: чтобы клиенты ЛВС1 "общались" с контроллером домена без участия Координатора1, по открытой сети.

Только никак не пойму причём тут туннелирование и хождение через координатор. Не зная Вашу топологию сети сложно сказать. Тем не менее, если вы просто в ЦУСе пропишете туннели, то ничего не изменится. Всё зависит от того, какая у Вас маршрутизация была до этого.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.