В этом разделе
Dr.Web MeshD играет роль посредника, обеспечивающего взаимодействие между узлом с установленным Dr.Web для почтовых серверов UNIX и другими узлами облака.
При работе Dr.Web MeshD использует подключения следующих типов:
•Клиентские (сервисные) используются Dr.Web MeshD для подключения к нему других узлов облака, являющимися клиентами услуг, предоставляемых данным узлом.
|
Компоненты Dr.Web для почтовых серверов UNIX, работающие на узле, и обращающиеся к услугам, представляемым облаком, через работающий на этом же узле Dr.Web MeshD, подключаются к нему через локальный UNIX-сокет. Клиентское подключение при этом не используется. |
•Партнерские (одноранговые) используются Dr.Web MeshD для взаимодействия с равноправными (в рамках некоторой услуги) узлами-партнерами облака. Обычно подобные горизонтальные связи используются для масштабирования и распределения нагрузки при взаимодействии с облаком, а также синхронизации состояния узлов облака.
•Восходящие используются Dr.Web MeshD для подключения данного узла в роли клиента к узлам облака, являющимися провайдерами услуг (например, распространение обновлений вирусных баз, передача файлов на проверку и т. п.).
Использование подключений всех трех типов настраивается для разных услуг облака независимо друг от друга. При этом один и тот же узел может быть настроен как сервер для обслуживания клиентских запросов в рамках одной услуги (например, для раздачи свежих обновлений), и как клиент — в рамках другой услуги (например, удаленного сканирования файлов).
В рамках облака узлы осуществляют взаимодействие по защищенному протоколу SSH, т. е. все стороны в рамках каждого межузлового взаимодействия всегда взаимно аутентифицированы. Для аутентификации используются узловые ключи (host keys) согласно RFC 4251. Клиентское подключение от локального компонента всегда считается доверенным.
Dr.Web MeshD может работать как в режиме демона, так и запускаться по запросам от других компонентов Dr.Web для почтовых серверов UNIX, расположенных на локальном узле. Если Dr.Web MeshD настроен на обслуживание клиентских подключений (параметр ListenAddress не пуст), и активирована возможность оказания хотя бы одной из услуг, Dr.Web MeshD стартует в роли демона и ждет подключения со стороны клиентов. Кроме того, Dr.Web MeshD может включиться по запросу на локальном узле, например при выполнении команды:
$ drweb-ctl update --local-cloud |
Если Dr.Web MeshD не настроен на обслуживание клиентских подключений (параметр ListenAddress пуст) и запросы к нему отсутствуют в течение периода времени, указанного в параметре IdleTimeLimit, работа компонента автоматически завершается.
Обмен обновлениями (Update)
Данная услуга позволяет узлу подписываться на обновления вирусных и иных баз, рассылать уведомления о наличии свежего обновления, загружать и раздавать файлы обновлений между узлами облака. Настройки использования данной услуги задаются параметрами Update*.
Стандартный сценарий использования услуги предполагает, что в локальной сети предприятия на некотором числе машин (исполняющих роль клиентов услуги) установлен Dr.Web MeshD со включенной функцией получения обновлений. Типовые настройки клиента следующие:
… |
На узле, выполняющем роль локального сервера распространения обновлений, заданы следующие настройки:
UpdateChannel = On |
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений.
Как только на каком-либо из узлов происходит обновление с серверов обновления (внешних по отношению к локальному облаку — серверов обновления ВСО Dr.Web или с сервера централизованной защиты), узел рассылает уведомление всем заинтересованным клиентам (если он настроен на работу в роли сервера услуги обмена обновлениями), а также сообщает серверному узлу новый список файлов, доступных для раздачи с этого узла. Получив это уведомление, клиентские узлы могут запросить загрузку обновленных файлов с сервера, который, в свою очередь, может запросить файлы у клиента, чтобы сохранить их у себя локально, либо отдать другому клиенту, который запросил эти файлы у сервера.
При использовании такой схемы обновление происходит с меньшей задержкой, поскольку клиенты опрашивают ВСО Dr.Web в различное время, и при этом первый обновившийся клиент сразу же раздает свежие файлы обновлений всем заинтересованным узлам облака. При этом также снижается количество передаваемого трафика и нагрузка на серверы ВСО Dr.Web.
|
Обратите внимание, что при использовании локального облака для распространения обновлений, на узлах помимо компонента Dr.Web MeshD должен присутствовать компонент обновления Dr.Web Updater. |
Удаленное сканирование файлов (Engine)
Данная услуга предназначена для предоставления возможности использования Dr.Web Scanning Engine для проверки удаленных файлов: узлы, работающие в роли клиентов, отправляют файлы на проверку на серверный узел, а серверные узлы предоставляют услугу по проверке файлов, отправленных клиентскими узлами. Типовые настройки клиента следующие:
… |
На узле, выполняющем роль локального сервера сканирования, заданы следующие настройки:
EngineChannel = On |
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений.
Передача файлов на проверку (File)
Данная функциональность не используется (функция удаленного сканирования оказывается в рамках услуги Engine).
Проверка URL (Url)
Данная услуга предназначена для проверки URL на принадлежность к потенциально опасным и нерекомендованным категориям: узлы, выступающие в роли клиентов, отправляют URL для проверки на серверный узел. Типовые настройки клиента следующие:
… |
На узле, выступающем в качестве сервера для проверки, заданы следующие настройки:
UrlChannel = On |
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений.