Туннелируемые адреса на ViPNet клиенте

[arahnid]

На данный момент все туннелируемые IP адреса задаются только на координаторе S:192.168.1.1

когда такая возможность появиться для записи АП?

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

[intellegent]

На данный момент все туннелируемые IP адреса задаются только на координаторе S:192.168.1.1

когда такая возможность появиться для записи АП?

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

Никогда! Координатор для того и существует, чтобы шифровать трафик от тех узлов сети, на которые нельзя поставить ПО ViPNet Client. Вообще, где логика, зачем клиенту еще шифровать трафик от каких-то других хостов.

[arahnid]

На данный момент все туннелируемые IP адреса задаются только на координаторе S:192.168.1.1

когда такая возможность появиться для записи АП?

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

Никогда! Координатор для того и существует, чтобы шифровать трафик от тех узлов сети, на которые нельзя поставить ПО ViPNet Client. Вообще, где логика, зачем клиенту еще шифровать трафик от каких-то других хостов.

Ты не понял вопроса

Вопрос с в том что на координаторе я настроил определенные адреса для туннелирования, просто я хочу что бы одни пользователи с установленным клиентом могли к одним адресам внутри сети обращаться а другие к другим

:evil:

[Stratos]

arahnid

Эту проблему можно решить прописыванием определенных фильтров на этих двух типах клиентов.

Либо ставить два координатора и "разводить" туннельные адреса.

[arahnid]

arahnid

Эту проблему можно решить прописыванием определенных фильтров на этих двух типах клиентов.

Либо ставить два координатора и "разводить" туннельные адреса.

1. про фильтры по подробнее?

2. про два куда не шло а про три четыре координатора это круто

народу сильно много, нужны записи туннелируемых адресов для АП!!!!

[intellegent]

arahnid

Эту проблему можно решить прописыванием определенных фильтров на этих двух типах клиентов.

Либо ставить два координатора и "разводить" туннельные адреса.

Может проще настроить фильтры на самом координаторе? Мне кажется что в данном случае так будет проще. Предлагаю сделать так - на интерфесе, смотрящем в сторону туннелируемых адресов, настроить разрешающие правила для необходимого Вам трафика, идущего от туннелей в сторону клиентов. Таким образом координатор будет шифровать только тот трафик, который Вы разрешите. И еще этот позволит минимизировать трудозатраты, т.к. проще все настроить в одном месте, чем скакать всему офису

[arahnid]

arahnid

Эту проблему можно решить прописыванием определенных фильтров на этих двух типах клиентов.

Либо ставить два координатора и "разводить" туннельные адреса.

Может проще настроить фильтры на самом координаторе? Мне кажется что в данном случае так будет проще. Предлагаю сделать так - на интерфесе, смотрящем в сторону туннелируемых адресов, настроить разрешающие правила для необходимого Вам трафика, идущего от туннелей в сторону клиентов. Таким образом координатор будет шифровать только тот трафик, который Вы разрешите. И еще этот позволит минимизировать трудозатраты, т.к. проще все настроить в одном месте, чем скакать всему офису

Помоему проще задать туннелируевые адреса для конкретного пользователя в ЦУСе, как для координатора. Тогда пользователь установит у себя клиента у него уже они будут прописаны, а не те которые заданы для координатора. потому как групп сильно много чтобы разруливать каждую группу через координатор

[Stratos]

arahnid

Для конктреного пользоваетля в ЦУСе задать совй туннелируемый адрес нельзя.

Т.е. если Вы зададите в ЦУСе тун. адреса для координатора они будут видны всем узлам, которые имеют связь с этим координатором.

Тот функционал, который необходим Вам в настоящее время отсутствует. Но работы в этом направлении ведутся.

[arahnid]

arahnid

Для конктреного пользоваетля в ЦУСе задать совй туннелируемый адрес нельзя.

Т.е. если Вы зададите в ЦУСе тун. адреса для координатора они будут видны всем узлам, которые имеют связь с этим координатором.

Тот функционал, который необходим Вам в настоящее время отсутствует. Но работы в этом направлении ведутся.

это крута!!! надеюсь в 3 версии наконецто это будет! 8)

[Сергей Якунин]

Помоему проще задать туннелируевые адреса для конкретного пользователя в ЦУСе, как для координатора. Тогда пользователь установит у себя клиента у него уже они будут прописаны, а не те которые заданы для координатора. потому как групп сильно много чтобы разруливать каждую группу через координатор

Дело еще в том, что пользователь видит и что он может. С точки зрения безопасности правильнее производить запреты именно на координаторе, так как именно он выполняет функции СМ и МФ. Хотя дополнительно "убрать" лишние упоминания (и возможности) из интерфейса клиента не помешало бы.

[Stratos]

Этот вопрос решается ограничением интерфейса пользователя.

[Сергей Якунин]

Пока нет удаленного управления клиентом это не очень удобно. Но верно.

[datn]

Этот вопрос решается ограничением интерфейса пользователя.

А как быть, если туннелирующий Координатор связан с АП чужой сети (через межсетевое взаимодействие) :?:

Все-таки, принципиально - именно Координатор должен решать - кому отдавать на растерзание беззащитную туннелируемую тачку :oops: , а кому нет (и даже не говорить о ее существовании в правилах доступа на закладке Туннель) :!:

Все-таки в ЦУС было бы это логичнее делать.

[Stratos]

datn

В ЦУСе было бы логичным много чего сделать

Но, к сожалению, пока не хватает ни времени ни ресурсов на доработки.