Использование прокси

Использование прокси, который входит в состав Dr.Web MailD, позволяет достичь нескольких целей:

1.Компоненты обработки почтового трафика (Receiver и Sender для входящего и исходящего трафика соответственно) и центральный компонент проверки почты MailD core распределяются по разным хостам, и между этими хостами с помощью компонентов проксирования настраивается взаимодействие. Это позволяет в ряде случаев добиться существенного повышения производительности программного комплекса.

2.Прокси поддерживает соединения по схеме N:M с балансировкой нагрузки, что позволяет оптимальным образом распределить ресурсы между различными узлами сети (здесь N - кол-во хостов, обрабатывающих почтовый трафик, M - кол-во хостов, проверяющих корреспонденцию на наличие вирусов и спама).

Следует учесть, что компонент MailD core (модуль drweb-maild) в настоящий момент не поддерживает кластерную реализацию и поэтому разные экземпляры этого модуля не могут обмениваться внутренней информацией друг с другом (статистикой, Карантином, настройками в базе данных и т.п.).

В результате для каждого из M компонентов MailD core будет своя статистика, свой Карантин, своя внутренняя база данных и свои настройки.

Прокси состоит из двух компонентов: Proxy client (модуль drweb-proxy-client) и Proxy server (модуль drweb-proxy-server).

•Proxy client работает на узле, где запущены компоненты Receiver и Sender, и запускается вместо компонента MailD core. Остальные компоненты воспринимают Proxy-client как MailD core, не имея никакого представления о существовании прокси.

•Proxy server работает на узле, где запущен основной компонент MailD core, и выполняет для него роль компонентов Receiver и Sender.

Оба компонента прокси взаимодействуют друг с другом, обеспечивая передачу оригинальных сообщений и их модификаций с целью обработки их другими компонентами Dr.Web MailD, расположенными на разных хостах.

Обратите внимание, что роль компонентов Sender и Receiver могут выполнять различные исполняемые модули (например, в качестве Receiver может выступать не только модуль drweb-receiver, но также drweb-milter, drweb-cgp-receiver, в зависимости от того, какой способ интеграции с MTA реализован при установке и настройке Dr.Web MailD).

Полный перечень модулей, и роли (Sender, Receiver), которые они исполняют с точки зрения Dr.Web MailD, перечислен в разделе Используемые модули.

Компоненты Dr.Web Notifier, Dr.Web Monitor и Dr.Web Agent работают на каждом из хостов.

Общая схема работы с использованием прокси выглядит следующим образом (N=2, M=3):

Рис. 18. Схема распределенной работы Dr.Web MailD с использованием прокси

Из данной схемы видно, что как Proxy client, так и Proxy server способны работать с произвольным числом экземпляров каждого. Обеспечивается это c помощью балансировки соединений через систему весов.

Каждому адресу сокета, указанному в значении параметров ProxyServersAddresses из секции [ProxyClient] и ProxyClientsAddresses из секции [ProxyServer] присваивается определенный вес. Соответственно, адреса задаются в следующем формате:

ADDRESS1 [WEIGHT1], ADDRESS2 [WEIGHT2] .. - где ADDRESS имеет стандартный тип адреса, а WEIGHT представляет собой необязательный вес этого адреса. Вес может принимать значения от 0 до 100 включительно. Он определяет относительную нагрузку на данный узел по сравнению с остальными узлами: чем больше вес, тем больше будет нагрузка на конкретный сервер.

В файлах конфигурации на каждом из серверов Server1, Server2 параметр ProxyServersAddresses из секции [ProxyClient] задает адреса серверов Server3, Server4, Server5 (см. схему), на которых работают компоненты Proxy server. В файлах конфигурации на каждом из серверов Server3, Server4, Server5 параметр ProxyClientsAddresses из секции [ProxyServer] задает адреса серверов Server1, Server2 (см. схему), на которых работают компоненты Proxy client.

В этом случае на адрес 10.3.0.73 будет отправляться, в среднем, в два раза больше писем, чем на адрес 10.3.0.72 (по 5 и по 10 из 15 соответственно).

Если вес адреса не указан, то он принимается по умолчанию равным 1. Если для адресов указан одинаковый вес, то они считаются полностью равноправными и получают одинаковый объем запросов. Если указан вес, равный 0, то адреса с этим весом считаются запасными (backup-адреса) и на них почта передается, только если не удалось отправить сообщение ни на один адрес с весом, большим или равным 1.

Общий алгоритм выбора адреса, на который будет осуществляться запрос, следующий:

1)Случайно выбирается адрес в соответствии с весами (чем больше вес адреса, тем вероятнее его выбор).

2)Производится попытка отправки сообщения на выбранный адрес.

3)Если сообщение было успешно отправлено, то конец. Если не удалось передать сообщение на выбранный адрес, то выбирается:

•либо другой адрес с тем же весом (если такие есть),

•либо следующий по весу адрес (его вес должен быть не менее 1),

и переход к пункту 2. Если доступных адресов с весом не менее 1 больше не осталось, то переход к пункту 4.

4)Производятся попытки отправить сообщение на backup-адреса (backup-адреса проверяются последовательно, в порядке их задания в списке). Если и backup-адреса недоступны, то возвращается ошибка.

Выбор веса следует осуществлять на основе имеющихся ресурсов на каждом из узлов, т.е. указывать большие веса тем узлам, которые мощнее.

Когда письма отправляются на проверку модулю MailD core и обрабатываются подключаемыми модулями из очереди BeforeQueue, то обработанная почта отправляется тому клиенту, от которого она была получена. Если письма обрабатываются подключаемыми модулями из очереди AfterQueue, то адрес клиента для отправки обработанной почты выбирается из ProxyClientsAddresses согласно заданным для адресов весам. Также клиенту из списка ProxyClientsAddresses отправляются клонированные письма (см. описание Правил обработки писем), и письма, сгенерированные самим MailD core (уведомления, отчеты) – независимо от того, в какой из очередей (BeforeQueueFilters или AfterQueueFilters) находятся подключаемые модули. При отправке почты клиентам из списка ProxyClientsAddresses будут учитываться настройки из Правил обработки писем (настройка SenderAddress).

Обратите внимание, что при использовании прокси вместе с почтовыми системами Qmail, Courier (и любыми почтовыми системами, использующими протокол Milter) нельзя помещать подключаемые модули в очередь AfterQueueFilters, т.к. в настоящий момент прокси не поддерживают callback-соединения с drweb-milter. Поэтому если ответ не возвращается сразу (а если подключаемый модуль помещен в AfterQueueFilters, то ответ и не может быть возвращен сразу, т.к. это асинхронный режим работы), то модуль drweb-milter завершит SMTP-сессию только по истечении периода времени, указанного в значении параметра ProcessingTimeout.

Ниже описана предпочтительная схема подключения прокси для случая, когда M=N=1. Предложенный порядок действий не является единственно возможным, но он позволяет с наибольшей вероятностью избежать различных ошибок настройки.

1.Установить и полностью настроить Dr.Web для почтовых серверов UNIX на Server1 (т.е. на том хосте, через который будет проходить проверяемый трафик и где будет располагаться компонент Proxy client). Проверить с помощью команды:

/etc/init.d/drweb-monitor check (для Linux и Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (для FreeBSD)

2.Запустить Dr.Web для почтовых серверов UNIX на Server1 и проверить, что почта корректно обрабатывается.

3.Установить Dr.Web для почтовых серверов UNIX на Server2 (т.е. на хост, где будет осуществляться фактическая проверка почты и располагаться компонент Proxy server). При установке можно не настраивать запуск модулей, исполняющих роли компонентов Receiver и Sender, поскольку они тут не понадобятся.

4.Настроить конфигурацию Server2 аналогично Server1.

5.На Server2 в файле mmc (из каталога %etc_dir/monitor) Dr.Web для почтовых серверов UNIX необходимо закомментировать запуск модулей, исполняющих роли компонентов Receiver и Sender и раскомментировать запуск модуля компонента Proxy server (drweb-proxy-server).

6.На Server2 в конфигурационном файле Dr.Web для почтовых серверов UNIX надо задать значение параметра ProxyClientsAddresse из секции [ProxyServer], указав в нем IP-адрес Server1, на который будет отправляться почта (тот же, что и в значении параметра Address секции [ProxyClient]).

7.Проверить корректность настройки на хосте Server2 с помощью команды:

/etc/init.d/drweb-monitor check (для Linux и Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (для FreeBSD)

Если все нормально, то можно запускать комплекс. Теперь Server2 полностью настроен и готов к работе.

8.На Server1 в конфигурационном файле Dr.Web для почтовых серверов UNIX надо задать значение параметра ProxyServersAddresses из секции [ProxyClient], указав в нем IP-адрес Server2, на который будут отправляться запросы на проверку сообщений (тот же, что и в значении параметра Address секции [ProxyServer]).

9.На Server1 в файле mmc Dr.Web для почтовых серверов UNIX необходимо закомментировать запуск компонента MailD core (модуль drweb-maild). Там же надо раскомментировать запуск компонента Proxy client (модуль drweb-proxy-client).

Пожалуйста, обратите внимание, что при попытке одновременно запустить на одном хосте модули drweb-proxy-client и drweb-maild, то компонент Dr.Web Monitor завершит свою работу и никакие компоненты не будут запущены. Информация об ошибке будет выведена в журнал компонента Dr.Web Monitor.

10.Проверить корректность настройки на хосте Server1 с помощью команды:

/etc/init.d/drweb-monitor check (для Linux и Solaris)
/usr/local/etc/rc.d/00.drweb-monitor.sh check (для FreeBSD)

Если все нормально, то можно перезапустить комплекс и, в результате, вся почта для проверки будет переправляться на Server2.

11.Опционально на Server1 теперь можно отключить запуск модуля компонента Dr.Web Daemon (drwebd) и расписание запуска компонента обновления Dr.Web Updater (если на данном хосте нет других продуктов Dr.Web), так как они больше там не нужны.

Масштабирование для случаев, когда M и/или N больше 1, выполняется аналогично: достаточно подключить дополнительные узлы, как было описано выше, и отредактировать соответствующие значения параметров ProxyClientsAddresses секции [ProxyServer] и ProxyServersAddresses секции [ProxyClient] на уже настроенных узлах, установив каждому адресу веса в соответствии с ресурсами узлов.

Обратите внимание на особенность функционирования прокси в случае если прокси-клиентов (т.е. узлов, на которых функционирует компонент Proxy client) более одного, и на каком-либо из прокси-клиентов компонент Receiver имеет настройку ReturnReject = No.

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

В связи с этим следует избегать использования настройки ReturnReject = No при конфигурациях проксирования, имеющих более одного прокси-клиента, если прокси-клиенты обслуживают разные сегменты сети и возможна потенциальная недоставка DSN отправителям писем.