Xayk Опубликовано 28 Сентября 2012 Жалоба Поделиться Опубликовано 28 Сентября 2012 Есть две локальных сети. В ЛВС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-адреса туннелируемых ресурсов вручную? И есть ли решение без ввода в работу дополнительного координатора? Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 28 Сентября 2012 Жалоба Поделиться Опубликовано 28 Сентября 2012 Есть две локальных сети. В ЛВС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 Cluster. Напрямую без координатора могут себе позволить обмениваться узлы с VipNet Client в одной ЛВС (второй вариант решения проблемы, но дорогой и неоправданный). Что касается туннелируемых узлов, то у них шлюз - координатор. Вы, конечно, можете прописать иные маршруты, но на 500 компьютерах это делать, мягко говоря, неинтересно. Не знаю как у Вас построена ЛВС, но это можно сделать не на каждом компьютере, а на маршрутизаторах, чтобы трафик на Вас контроллер домена шёл без петли на координатор (третий вариант решения проблемы).Немного не понял про прописывание туннелируемых адресов вручную. Это же делается в ЦУСе, где можно задать диапазон адресов сразу и разослать просто справочники с таблицами машрутизации на координаторы.И, кстати, если у Вас контроллер домена находится в той же подсети и не выделен физически канал к нему, то через координатор (шлюз) трафик идти и не должен. Всё-таки более подробно схему нарисуйте. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Xayk Опубликовано 1 Октября 2012 Автор Жалоба Поделиться Опубликовано 1 Октября 2012 Если у Вас огромная нагрузка на координатор получается, то есть решение - VipNet Cluster. Напрямую без координатора могут себе позволить обмениваться узлы с VipNet Client в одной ЛВС (второй вариант решения проблемы, но дорогой и неоправданный). Что касается туннелируемых узлов, то у них шлюз - координатор. Вы, конечно, можете прописать иные маршруты, но на 500 компьютерах это делать, мягко говоря, неинтересно. Не знаю как у Вас построена ЛВС, но это можно сделать не на каждом компьютере, а на маршрутизаторах, чтобы трафик на Вас контроллер домена шёл без петли на координатор (третий вариант решения проблемы).Немного не понял про прописывание туннелируемых адресов вручную. Это же делается в ЦУСе, где можно задать диапазон адресов сразу и разослать просто справочники с таблицами машрутизации на координаторы.И, кстати, если у Вас контроллер домена находится в той же подсети и не выделен физически канал к нему, то через координатор (шлюз) трафик идти и не должен. Всё-таки более подробно схему нарисуйте.В том-то и проблема, что если прописать все туннелируемые ресурсы для VipNet Координатор1 в ЦУСе, тогда все клиенты (и в ЛВС1 в том числе) будут ходить через этот координатор. Этого-то мы и пытаемся избежать: чтобы клиенты ЛВС1 "общались" с контроллером домена без участия Координатора1, по открытой сети. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
slavanchuk Опубликовано 1 Октября 2012 Жалоба Поделиться Опубликовано 1 Октября 2012 В том-то и проблема, что если прописать все туннелируемые ресурсы для VipNet Координатор1 в ЦУСе, тогда все клиенты (и в ЛВС1 в том числе) будут ходить через этот координатор. Этого-то мы и пытаемся избежать: чтобы клиенты ЛВС1 "общались" с контроллером домена без участия Координатора1, по открытой сети.Только никак не пойму причём тут туннелирование и хождение через координатор. Не зная Вашу топологию сети сложно сказать. Тем не менее, если вы просто в ЦУСе пропишете туннели, то ничего не изменится. Всё зависит от того, какая у Вас маршрутизация была до этого. Цитата Ссылка на комментарий Поделиться на других сайтах Прочее
Рекомендуемые сообщения
Присоединиться к обсуждению
Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.