Випнет монитор что это такое. Обзор возможностей VipNet Client

ViPNet Client (Клиент)

ViPNet Client (Клиент) — это программный комплекс для защиты рабочих мест пользователей.
1) ViPNet Monitor (Монитор) – отвечает за реализацию функций:

Персонального сетевого экрана – накрепко защищает рабочую станцию/сервер от вероятных сетевых атак, как из глобальной, так и из локальной сети. При этом: осуществляется фильтрация защищенного и открытого трафиков по множеству характеристик («белый» и «черный» списки IP-адресов, порты, протоколы, типы сервисов и приложений); реализуется режим «stealth» (режим инициативных соединений), позволяющий сделать невидимым комп защищенной сети из открытой сети; имеет встроенную систему обнаружения вторжений (IDS); обеспечивает мониторинг сетевой активности приложений, позволяющий найти и перекрыть несанкционированную активность программ-«троянцев».
Шифратора TCP/IP трафика – обеспечивает защиту (конфиденциальность, подлинность и целостность) хоть какого вида трафика (приложений, систем управления и служебного трафика ОС), передаваемого меж хоть какими объектами защищенной сети, будь-то рабочие станции, информационные серверы, серверы приложений, сетевые устройства и узлы. Высочайшая производительность шифрующего драйвера дозволяет в настоящем времени защищать трафик служб голосовой и видеосвязи в сетях TCP/IP. Поддерживается прозрачная работа через устройства статической и динамической NAT/PAT маршрутизации.
Чат-клиента – дозволяет воспользоваться услугами сервиса обмена защищенными сообщениями и организации чат-конференций меж объектами защищенной сети ViPNet , на которых установлены ViPNet Client либо ViPNet Coordinator ( Windows ).
Клиента службы обмена файлами – дозволяет обмениваться меж объектами защищенной сети ViPNet хоть какими файлами без установки доп ПО (например, FTP -сервера/клиента) либо использования функций ОС по общему доступу к файлам через сеть. Обмен файлами делается через защищенную транспортную сеть ViPNet с гарантированной доставкой и «докачкой» файлов при обрыве связи.

2) ViPNet Application Control (Контроль приложений) – программный модуль – дозволяет контролировать сетевую активность приложений и компонент операционной системы. При этом можно сформировывать «черный» и «белый» списки приложений, которым запрещено либо разрешено работать в сети, а также задавать реакцию на сетевую активность неизвестных приложений. В большинстве случаев это дозволяет предотвратить несанкционированную сетевую активность вредного ПО, к примеру, программ-«троянцев».

3) ViPNet Business Mail (Деловая Почта) – программный модуль – выполняет функции почтового клиента защищенной почтовой службы, функционирующей в рамках защищенной сети ViPNet , и позволяет:

Формировать и отсылать письма адресатам защищенной сети через обычный графический интерфейс юзера. Возможна многоадресная рассылка;
Использовать интегрированные механизмы ЭЦП для подписи, в том числе множественной, текста письма и его вложений;
Контролировать все этапы «жизни» письма благодаря встроенному механизму неотклонимого квитирования писем. Можно постоянно убедиться, что письмо было доставлено, прочитано, открыты вложения. Квитанции о этих событиях могут автоматом подписывать ЭЦП получателя;
Благодаря интегрированной функции аудита иметь доступ к истории удаления писем;
Вести архивы писем и при необходимости просто переключаться меж текущим хранилищем писем и этими архивами;
Употреблять мощнейший механизм автоматической обработки входящих писем и файлов – задавать правила обработки входящих писем, а также правила по автоматическому формированию и отправке писем с данными файлами.
Деловая Почта свободна от спама! Хоть какой отправитель ненужной корреспонденции может быть однозначно установлен. Потому этот сервис ViPNet является безупречным решением для внутрикорпоративного обмена документами и письмами.

4) Криптопровайдер (CSP) – ViPNet Client содержит интегрированный криптопровайдер, реализующий обычный для разрабов прикладных систем под ОС Windows интерфейс Microsoft Crypto API 2.0. При этом дополнительно предоставляется СОМ-интерфейс для вызова криптографических функций и их использования Web приложениями, а также низкоуровневый С-интерфейс к функциям СКЗИ «Домен-К» для встраивания в приложения заказчика.

Спецы отдела электронного документооборота ООО «Стандарт безопасности», устанавливающие и настраивающие ПО ViPNet, являются сертифицированными админами системы защиты инфы ОАО «Инфотекс».

Оформите заявку на веб-сайте, мы свяжемся с вами в наиблежайшее время и ответим на все интересующие вопросы.

ViPNet в деталях: разбираемся с чертами криптошлюза

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не возник сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задачка не из легких. Отлично, ежели это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с наиболее экзотичными решениями на базе собственных протоколов шифрования, к примеру, «Континент» (от «Кода Безопасности») либо ViPNet Coordinator HW (от «Инфотекса»)? В данной статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и поведать, с какими неуввязками столкнулся сам и как их решал.

Сразу оговорюсь, что мы побеседуем о сертифицированной на сейчас ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х возникло много увлекательного, к примеру, DGD (Dead Gateway Detection) и модифицированный механизм кластеризации, обеспечивающий фактически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на главных командах и переменных, а подробное описание по сиим «ключам» можно будет отыскать в документации.

Читайте также  Как установить антенну мтс самому. Самостоятельно устанавливаем тарелку МТС ТВ и настраиваем антенну на спутник без прибора

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-1-х, это криптошлюз (КШ), который дозволяет воплотить как Site-to-site, так и RA VPN. Во-2-х, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) либо данные клиентских приложений (файловый обмен, деловая почта). Кстати, конкретно в справочниках хранятся файлы, содержащие информацию о объектах сети ViPNet, в том числе о их именах, идентификаторах, адресах, связях. Координатор также является источником служебной инфы для собственных клиентов.

Помимо этого, он может туннелировать трафик от компов сети, где не установлено ПО ViPNet. Кстати, спецы, работающие с сиим решением, нередко именуют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к иным VPN-решениям, где под туннелем предполагают PtP-соединение меж КШ.

В качестве протокола шифрования в ViPNet употребляется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика используются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).

В концепции построения защищенных соединений лежат так именуемые «связи», которые бывают 2-ух типов. 1-ые (на уровне узлов) необходимы для построения защищенного соединения меж узлами, 2-ые (на уровне пользователей) нужны для работы клиентских приложений. Но есть исключение: узлы админа сети ViPNet требуют обоих типов связи.

Что же может в данной схеме пойти не так? Как указывает практика, особенностей работы вправду много, и далековато не все препядствия можно решить интуитивно, без «помощи зала», а что-то необходимо просто принять как данность.

Координатор недоступен

«У нас недоступен координатор/клиент/туннель. Что делать?» – самый нередкий вопросец, с которым приходят новенькие при настройке ViPNet. Единственно верное действие в таковой ситуации – включать регистрацию всего трафика на координаторах и глядеть в журнальчик IP-пакетов, который является важным инвентарем траблшутинга различных сетевых заморочек. Этот метод выручает в 80% случаев. Работа с журнальчиком IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.

Конверт не доставлен

Но журнальчик IP-пакетов, как досадно бы это не звучало, бесполезен, когда речь входит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть собственный журнальчик и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и дальше по межсерверным каналам, которые настроены меж координаторами (то есть не впрямую по защищенному каналу). Означает, ежели вы захотите выслать письмо по деловой почте, то клиент упакует его в конверт и вышлет поначалу на собственный координатор. Дальше на пути могут быть еще несколько координаторов, и лишь опосля этого конверт попадет на узел адресата.

Из этого следуют два вывода. Во-1-х, меж клиентами не непременно обязана проверяться связь (по нажатию на F5 и соответственной иконки в меню) для доставки конвертов. Во-2-х, ежели связь межу ними все-же проверяется, это не гарантирует доставку, так как неувязка может быть в одном из межсерверных каналов.

Диагностировать прохождение конвертов межсерверным каналам либо меж клиентом и координатором в неочевидных вариантах можно с помощью журнальчика и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку либо SMTP/POP3 (но это совершенно экзотичный вариант). Погружаться в эти опции мы не будем.

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старенькых железок, которые долго лежали, к примеру, в качестве ЗИП. В процессе может показаться ошибка «unsupported hardware», которая докладывает или о том, что у вас вправду неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), или о дилеммах в настройке BIOS либо в неправильной инфы, зашитой в DMI. Править ли без помощи других DMI, каждый решает для себя сам, так как есть риск перевоплотить оборудование в бесполезный «кирпич». С BIOS чуток проще: неправильные опции системы заключаются в выключенной функции HT (Hyper Threading) либо выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтоб не гадать, в чем непосредственно неувязка, можно обратиться к флешке, с которой делается прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. К примеру, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], быстрее всего, докладывает о выключенном HT. Кстати, перепрошивку нередко путают с обновлением, но это различные процессы. При обновлении сохраняются все опции, а характеристики, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Читайте также  Как поставить на макбук виндовс. Установка Windows 10 на компьютере Mac с помощью приложения «Ассистент Boot Camp»

Неинформативные конфиги

Основным конфигурационным файлом HW является «iplir.conf», но он не постоянно отражает текущие характеристики. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в согласовании с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверное знают о существовании команды «iplirdiag», которая показывает текущие опции узлов, прогруженные в драйвер. В HW эта команда также находится в режиме «admin escape».

Самые популярные выводы это:
iplirdiag -s ipsettings –node-info <идентификатор узла> ##отображение инфы о узле
iplirdiag -s ipsettings –v-tun-table ##отображение всех загруженных в драйвер туннелей

Немного остановимся на режиме «admin escape». По сущности это выход из ViPNet shell в bash. Здесь я солидарен с вендором, который советует применять данный режим лишь для диагностики и вносить какие-либо модификации лишь под присмотром техподдержки вендора. Это для вас не обыденный Debian, тут хоть какое неосторожное движение может вывести из строя ОС, защитные механизмы которой примут вашу «самодеятельность» как потенциальную опасность. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.

(Un)split tunneling

Еще один факт, который знают далековато не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует разработка «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»). Почти все неверно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с таковой функцией, создается два набора предустановленных фильтров. 1-ый разрешает взаимодействие лишь с самим координатором и его туннелями, 2-ой – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. При этом, согласно концепции вендора, в первом случае координатор должен или туннелировать прокси-сервер, или сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в хоть какой конфигурации.

Служебные порты и TCP-туннель

Однажды я столкнулся с приложением, которое ни в какую не желало работать через координатор. Так я вызнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без способности какой-нибудь опции. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Здесь подвела функции TCP-туннеля. Не секрет, что провайдеры обожают фильтровать высочайшие порты UDP, потому админы, стремясь сделать лучше доступность собственных КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом стают недосягаемы. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регится в журнальчике IP-пакетов, как как будто его совсем нет.

Замена координатора

Рано либо поздно встает вопросец о подмене координатора на наиболее производительный либо временный вариант. К примеру, подмена HW1000 на HW2000 либо программного координатора – на ПАК и напротив. Сложность заключается в том, что у каждого выполнения своя «роль» в ЦУС (Центре управления сетью). Как верно поменять роль, не утратив связность? Поначалу в ЦУС меняем роль на новейшую, формируем справочники, но не отправляем(!) их. Потом в УКЦ выпускаем новейший DST-файл и проводим инициализацию новейшего Координатора. Опосля производим подмену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв – это must have для хоть какой большой площадки, потому на их постоянно закупался кластер старших моделей (HW1000, HW2000, HW5000). Но создание кластера из наиболее малогабаритных криптошлюзов (HW50 и HW100) было нереально из-за лицензионной политики вендора. В итоге обладателям маленьких площадок приходилось серьезно переплачивать и брать HW1000 (ну, либо никакой отказоустойчивости). В этом году вендор, в конце концов, сделал доп лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x возникла возможность собирать в кластер и их.

При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме профессионалы либо командами CLI. Можно сходу вчеркивать нужные адреса в конфигурационный файл кластера (failover config edit), лишь не забудьте указать маски. При запуске беса failover в кластерном режиме он сам назначит адреса на надлежащие интерфейсы. Почти все при этом боятся останавливать бес, предполагая, что адреса сменяются на пассивные либо адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.

В кластерном выполнении существует две всераспространенные проблемы: повторяющаяся перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтоб осознать сущность этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, ежели за отведенное время пакетов нет, посылает пинг на testip. Ежели пинг проходит, то счетчик запускается поновой, ежели не проходит, то регится отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом посылает постоянные ARP-запросы на всех интерфейсах, обрисованных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые воспринимает активная и пассивная ноды). Ежели ARP-запись хоть 1-го адреса теряется, то пассивная нода переключается в активный режим.

Читайте также  Лицензия есет нод 32 бесплатно. Свежие ключи для Нод 32 на 2020 год

Вернемся к кластерным дилеммам. Начну с обычного – неперключение в активный режим. В случае ежели активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще находится, нужно идти к админам коммутаторов (либо так настроен ARP-кэш, или это некий сбой). С повторяющейся перезагрузкой пассивной ноды мало труднее. Происходит это из-за того, что пассивная не лицезреет ARP-записи активной, перебегает в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода соображает, что что-то не так, раз появился конфликт состояний, и уходит в перезагрузку. Так длится до бесконечности. В случае появления данной задачи нужно проверить опции IP-адресов в failover.ini и коммутацию. Ежели все опции на координаторе верны, то пришло время подключить к вопросцу сетевых инженеров.

Пересечения адресов

В нашей практике часто встречается пересечение туннелируемых адресов за различными координаторами.

Именно для таковых случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это типичный NAT без контроля состояния соединения один к одному либо спектр в спектр. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы сможете отыскать в iplir.conf в строке «tunnel» опосля «to» в секциях примыкающих координаторов. Для того, чтоб включить виртуализацию глобально для всего перечня, нужно в секции [visibility] поменять параметр «tunneldefault» на «virtual». Ежели же желаете включить для определенного соседа, то нужно в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment нужно перевести в режим «manual». На противоположной стороне необходимо выполнить подобные деяния. За опции туннелей также отвечают характеристики «usetunnel» и «exclude_from_tunnels». Итог выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.

Конечно, виртуальные адреса приносят некие неудобства, потому админы инфраструктуры предпочитают минимизировать их внедрение. К примеру, при подключении организаций к информационным системам (ИС) неких госорганов сиим организациям выдается DST-файл c фиксированным спектром туннелей из адресного плана ИС. Как мы лицезреем, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новейшую адресацию, а кто-то употребляет SNAT на пути от хостов к координатору. Не секрет, что некие админы используют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такового «лайфхака», но не стоит забывать, что производительность самих платформ все-же имеет предел, и при перегрузке начнется деградация свойства канала связи.

Невозможность работы GRE

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Довольно раздражающей неувязкой является невозможность работы GRE (и протоколов, которые его используют) от пары источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к общественному адресу банка. Неувязка в том, что протокол GRE не употребляет порты, потому опосля прохождения трафика через NAT, socketpair такового трафика становится схожим (адрес назначения у нас однообразный, протокол тоже, а трансляцию адреса источника мы лишь что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Смотрится это так:

Поэтому, ежели вы используете множественные GRE-подключения, нужно избегать внедрения NAT к сиим подключениям. В последнем случае делать трансляцию 1:1 (правда, при использовании общественных адресов это довольно непрактичное решение).

Не забываем про время

Тему блокировок продолжаем событием номер 4 – IP packet timeout. Здесь все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени меж узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW наибольшая разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в данной статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, может быть, собьет с толку инженера, привыкшего к «обычным» HW.

Нешифрованный трафик заместо зашифрованного

Новичкам бывает трудно осознать природу 22 действия – Non-encrypted IP Packet from network node – в…

Оставьте комментарий