Пожелания к функциональным возможностям ПО ViPNet

[Stratos]

Пожелания к функциональным возможностям ПО ViPNet

[Гость Игорь Турикин]

Очень к стати был бы монитор сетевой активности в Персональном сетевом экране и возможность нарезать трафик.

Пример:

у пользователя на компьютере установлен FTP сервер, с него переодически сливают информацию, что не удобно для работы на самом компьютере (если этой информации много за один момент времени), понятно, что это можно настроить и в FTP сервере, но варианты применения могут быть разнообразными.

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

ЗЫЫ Очень приятно, что Российский производитель находится на таком высоком уровне.

ООО "Синергия Телеком" www.syntelecom.ru

[Greyman]

А планируется ли выпуск версии VipNet[Клиент] для КПК? Есть определенная необходимость работать во внутренней сети прямо со смартфонов (т. с. в полевых условиях). SaheDisk уже есть, а "клиент" намечается?

[Stratos]

Добрый день Greyman

Выпуск клиента под КПК намечен на конец года.

[crapaud]

Наконец-то появилась какая-никакая российская альтернатива всем известным winroute и wingate. Однако функционал OFFICE FIREWALL 3 (а я именно его имею в виду) во многом не дотягивает до своих западных конкурентов. И пока OF имеет по сравнению с ними лишь один плюс - сертификат ФСБ

В связи с этим вопросы:

1. Планируется ли оснащение пакета полноценным кеширующим прокси?

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

3. Создание и управление правами доступа клиентов сети (как отдельных, так и груп).

4. Возможность удаленного администрирования через интернет.

Вобщем это основное. Интерес не праздный, т.к. я являюсь сисадмином одного из многочисленных посольств РФ. Плюс в разных городах у меня еще есть консульские организации. И сейчас на всех их шлюзах стоит керио винрут 6 с антивирусным плагином Виснетик (исползует базы касперского). Вобще-то пока хватает, но для самоуспокоения (и успокоения органов )хотелось бы имети сертифицированный ФАПСИ аналог. Когда-то в МИДе хотели перейти на вашу разработку, да так все кажись и загнулось... Так что приходится защищаться своими силами ))).

Надеюсь на развернутый ответ :wink:

[MORO]

Не "смертельно", но, как показала практика, не помешала бы возможность включения запроса о прохождении транспортых пакетов (ДП в частности) между Клиентами по всем промежуточным Координаторам (аналогично тому, как это реализовано в Lotus).

Объясню почему. Когда речь идёт о юридически значимом ЭДО, тем паче со сторонними организациями, бывают прецеденты, когда сторона-отправитель клянётся, что отправила по ДП информацию, а на стороне-получателе её ещё не получили. При этом, отправитель и получатель - абоненты разных VPN и между ними находятся до 4-х промежуточных Координаторов, часть их которых - в зоне ответственности одной стороны, часть - в зоне ответственности другой. Так вот для того, чтобы точно установить "на чьём берегу застряли" транспортные пакеты необходимо чтобы админы обеих VPN просмотрели "Очереди" MFTP всех промежуточных Координаторов. Это нетрудно, конечно , но бывает, что документ по ДП идёт срочный, "горящий", а одного админа (или обоих) просто нет в данный момент на месте, у телефона, и возникает "напряг" :? .

Было бы неплохо, если бы каждый Координатор, получив пакет ДП и прокинув его дальше по цепочке (или по каким-либо причинам, не сумев этого сделать), отправлял получателю маленькую квитанцию о содеянном.

[Stratos]

MORO

Возможно фича и полезная, только вот какой трафик будет от этих квитанций?

Да и потом, зачем отправлять квитанции, кога на координаторе просто можно посмотреть журнал MFTP?

А если письмо где-то и "застряло", то это сигнализирует о проблемах в сети. В рабочей сетке таких симптомов наблюдаться не должно. "Застрять" письмо может только при условии очень большой очереди на координаторе.

[MORO]

Возможно фича и полезная, только вот какой трафик будет от этих квитанций?

Поверьте, намного мЕньший, нежели "судорожно-повторная" (и, порой, неоднократная) отправка ДП.

Да и потом, зачем отправлять квитанции, кога на координаторе просто можно посмотреть журнал MFTP?

А если письмо где-то и "застряло", то это сигнализирует о проблемах в сети. В рабочей сетке таких симптомов наблюдаться не должно. "Застрять" письмо может только при условии очень большой очереди на координаторе.

Я же не спорю с тем, что в идеальных условиях, как технических, так и кадровых, система должна работать, как швейцарсике часы.

Только я исхожу из реальной практики, а не из идеальных условий... :? Да и обсуждаемую функцию можно было бы сделать опциональной. И тогда админ каждой конкретной VPN мог бы, исходя, опять же из конкретных условий, решать - нужен ему этот лишний трафик или он - совсем не лишний .

Впрочем, я просто высказал своё пожелание разработчикам ПО ViPNet , а вовсе не собирался давать пищу для полемики.

Спасибо за ответ :wink: .

[Lvv]

Было бы очень удобно, если бы у указанных координаторов можно было включать режим синхронизации туннелируемых ресурсов (минуя ЦУС). По умолчанию он был бы отключен.

[Stratos]

Lvv

Прошу направить Ваше развернутое предложение на hotline@infotecs.ru.

Ваше предложение будет передано разработчикам.

[Ondatra]

Было бы полезным наличие в настройках vipnet-клиента галочки "зафиксировать IP и порт" в меню "защищенная сеть"-"координатор"-"межсетевой экран". Имею ряд ситуаций, в которых проверка соединения проходит, координатор сообщает пользователю свои настройки и клиент сам вышибает стул из под работающего соединения. Пример (один из) - клиент и координатор находятся внутри одной сети 10,0,0,0, при этом координатор сконфигурирован для работы через фаер с внешним ИП. Результат - чтобы клиент корректно с ним работал ему необходимо стучаться на внешний ИП (т.е. включать доступ к инету).

[Echo]

Было бы полезным наличие в настройках vipnet-клиента галочки "зафиксировать IP и порт" в меню "защищенная сеть"-"координатор"-"межсетевой экран".

Не очень понятен смысл такой опции. В Защищенной сети можно настроить вручную порт и IP точки доступа к Координатору Координатора. При правильных настройках маршрутизации принимающий узел сам определяет правильные значения и подставляет их в параметры настройки межсетевого экрана.

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

Клиент и Координатор, находящиеся в одном бродкастовом сегменте, автоматически начинают работать в рамках этой сети, и через Интернет соединяться даже не пытаются. По такой скудной информации трудно что-то рекомендовать. В типовом случае, если Координатор - сервер IP-адресов для Клиента, то Клиент должен быть в режиме межсетевого экрана ViPNet-координатор, Координатор - за статическим NAT.

За более подробным разбором лучше обратиться в службу поддержки на hotline@infotecs.ru, особенно, если у Вас есть договор на техподдержку. Потребуется следующая информация:

схема сети с Координатором и Клиентом ( настроенные IP, маски, шлюзы для всех интерфейсов в ОС), собственные настройки ViPNet, настройки в Защищенной сети друг для друга, версии и сборки ViPNet...

С уважением,

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

Было бы полезным наличие возможности отправки файла из конференции, праым щелчком по абоненту.