Принципы работы |
Dr.Web MeshD играет роль посредника, обеспечивающего взаимодействие между узлом, на котором установлен Dr.Web Mail Security Suite, и другими узлами облака. При работе Dr.Web MeshD использует подключения следующих типов: •Клиентские (сервисные) используются Dr.Web MeshD для подключения к нему других узлов облака, которые являются клиентами услуг, предоставляемых данным узлом.
•Партнерские (одноранговые) используются Dr.Web MeshD для взаимодействия с равноправными (в рамках некоторой услуги) узлами-партнерами облака. Обычно подобные горизонтальные связи используются для масштабирования и распределения нагрузки при взаимодействии с облаком, а также синхронизации состояния узлов облака. •Восходящие используются Dr.Web MeshD для подключения данного узла в роли клиента к узлам облака, предоставляющим услуги (например, распространение обновлений вирусных баз, передача файлов на проверку и т. д.). Использование подключений всех трех типов настраивается для разных услуг облака независимо друг от друга. При этом один и тот же узел может быть настроен как сервер для обслуживания клиентских запросов в рамках одной услуги (например, для раздачи свежих обновлений) и как клиент — в рамках другой услуги (например, удаленного сканирования файлов). В рамках облака узлы осуществляют взаимодействие по защищенному протоколу SSH, т. е. все стороны в рамках каждого межузлового взаимодействия всегда взаимно аутентифицированы. Для аутентификации используются узловые ключи (host keys) согласно RFC 4251. Клиентское подключение от локального компонента всегда считается доверенным. Dr.Web MeshD может работать как в режиме демона, так и запускаться по запросам от других компонентов Dr.Web Mail Security Suite, расположенных на локальном узле. Если Dr.Web MeshD настроен на обслуживание клиентских подключений (параметр ListenAddress не пуст) и активирована возможность оказания хотя бы одной из услуг, Dr.Web MeshD запускается как демон и ждет подключения со стороны клиентов. Если Dr.Web MeshD не настроен на обслуживание клиентских подключений (параметр ListenAddress пуст) и запросы к нему отсутствуют в течение периода времени, указанного в параметре IdleTimeLimit, работа компонента автоматически завершается. Данная услуга позволяет узлу подписываться на обновления вирусных и иных баз, рассылать уведомления о наличии свежего обновления, загружать и раздавать файлы обновлений между узлами облака. Настройки использования данной услуги задаются параметрами Update*. Стандартный сценарий использования услуги предполагает, что в локальной сети предприятия на некотором числе машин (исполняющих роль клиентов услуги) установлен Dr.Web MeshD со включенной функцией получения обновлений. Типовые настройки клиента следующие:
На узле, выполняющем роль локального сервера распространения обновлений, заданы следующие настройки:
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений. Как только на каком-либо из узлов происходит обновление с серверов обновления (внешних по отношению к локальному облаку — серверов обновления ВСО Dr.Web или с сервера централизованной защиты), узел рассылает уведомление всем заинтересованным клиентам (если он настроен на работу в роли сервера услуги обмена обновлениями), а также сообщает серверному узлу новый список файлов, доступных для раздачи с этого узла. Получив это уведомление, клиентские узлы могут запросить загрузку обновленных файлов с сервера, который, в свою очередь, может запросить файлы у клиента, чтобы сохранить их у себя локально, либо отдать другому клиенту, который запросил эти файлы у сервера. При использовании такой схемы обновление происходит с меньшей задержкой, поскольку клиенты опрашивают ВСО Dr.Web в разное время, и при этом первый обновившийся клиент сразу же раздает свежие файлы обновлений всем заинтересованным узлам облака. При этом также снижается количество передаваемого трафика и нагрузка на серверы ВСО Dr.Web.
Данная услуга позволяет использовать Dr.Web Scanning Engine для проверки удаленных файлов: узлы, работающие в роли клиентов, отправляют файлы на проверку на серверный узел, а серверные узлы предоставляют услугу по проверке файлов, отправленных клиентскими узлами. Типовые настройки клиента следующие:
На узле, выполняющем роль локального сервера сканирования, заданы следующие настройки:
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений. Данная функциональность не используется (функция удаленного сканирования оказывается в рамках услуги Engine). Данная услуга предназначена для проверки URL на принадлежность к потенциально опасным и нежелательным категориям: узлы, выступающие в роли клиентов, отправляют URL для проверки на серверный узел. Типовые настройки клиента следующие:
На узле, выступающем в качестве сервера для проверки URL, заданы следующие настройки:
Здесь <адрес сервера> в восходящем соединении клиента должен указывать на те <адрес> и <порт>, которые используются серверным узлом для организации клиентских подключений. |