Zimbra Proxy - очень важный элемент Zimbra OSE, который выполняет целый ряд функций, связанных с безопасностью и быстродействием почтовой инфраструктуры. Именно на узле Zimbra Proxy происходит централизованная аутентификация пользователей и их перенаправление на соответствующий почтовый сервер, а также централизованный сбор логов. Кроме того, Zimbra Proxy выполняет функции балансировщика нагрузки и обратного прокси - скрывает от пользователей топологию и характеристики узлов инфраструктуры Zimbra OSE, что затрудняет проведение разного рода кибератак. Также на узле Zimbra Proxy происходит терминация SSL-соединения, что снижает нагрузку на остальные серверы инфраструктуры Zimbra OSE, и кэширование. Но главная ценность Zimbra Proxy заключается в том, что этот узел позволяет обеспечивать централизованный доступ к другим узлам инфраструктуры Zimbra OSE.

На самом сервере Zimbra Proxy устанавливаются такие компоненты как Nginx и memcached. Также на почтовых серверах Zimbra OSE устанавливаются обработчики маршрутизации запросов, который позволяет Zimbra Proxy корректно находить почтовый сервер при подключении пользователя. Всё это нужно для обеспечения централизованного доступа пользователей к серверам Zimbra OSE. Суть его заключается в том, что при подключении пользователя к узлу Zimbra Proxy он самостоятельно определяет, к какому почтовому серверу относится его учетная запись и перенаправляет подключение на нужный почтовый сервер, чтобы пользователь в итоге попал в свой почтовый ящик. То, что со стороны пользователя работает как магия, на самом деле является довольно сложным механизмом со множеством различных нюансов. О них мы расскажем в данной статье. 

Для корректной работы узла Zimbra Proxy следует открыть для внешних соединений следующие порты:

В том случае, если на узле с Zimbra Proxy вы используете Ubuntu, правило для UFW будет иметь следующий вид:

sudo ufw allow 22,25,80,110,143,443,465,587,993,995,9071/tcp

Подключение пользователей происходит следующим образом:

Клиенты подключаются к Zimbra Proxy по одному из указанных выше портов и проходит процедуру аутентификации. В случае успешного входа, Zimbra Proxy опрашивает memcached на предмет уже сохраненного маршрута для данного пользователя. Если маршрут действительно сохранен, Zimbra Proxy просто соединит пользователя с нужным почтовым сервером, за счет чего сэкономит часть вычислительных ресурсов. Если соответствующей записи в memcached нет или она просрочена, Zimbra Proxy отправляет запрос к доступным обработчикам маршрутизации запросов, чтобы найти почтовый сервер, на котором расположен почтовый ящик пользователя. Обработчик получает соответствующую запись из LDAP и возвращает данные Zimbra Proxy, которая, в свою очередь, создает соединение между пользователем и почтовым сервером, а также сохраняет информацию об использованном для создания подключения маршруте в memcached. Данный процесс происходит незаметно для пользователя и для него все выглядит так, будто бы он соединяется напрямую с почтовым сервером. Это позволяет добиться централизации аутентификации и собирать информацию о неуспешных попытках входа в едином лог-файле.

Еще одной важной функцией Zimbra Proxy является терминация SSL-соединения. Поскольку пользователи соединяются с инфраструктурой Zimbra OSE по зашифрованному каналу связи, данные передаются в зашифрованном виде и узлам инфраструктуры приходится тратить процессорное время на их расшифровку. Для того, чтобы ускорить передачу данных и снизить общую нагрузку, используется терминация SSL-соединения, которая подразумевает, что на сервере Zimbra Proxy происходит расшифровка переданных от пользователя данных, а внутренним узлам инфраструктуры они передаются уже в незашифрованном виде. Учитывая то, что все входящие электронные письма проходят проверку антивирусом и антиспамом, а также должны сохраняться в почтовый ящик, итоговая экономия ресурсов может быть достаточно солидной. 

Обратной стороной медали является снижение уровня безопасности сервера, так как появляется угроза перехвата трафика в результате атаки по модели MitM. Именно поэтому по умолчанию терминация SSL-соединения в Zimbra OSE отключена и если вы все же решите ее включить, обязательно удостоверьтесь в том, что перехват передаваемых данных в вашей инфраструктуре исключен, а также не забудьте предупредить об этом своих клиентов, которые практически наверняка уверены в том, что их данные защищены на всем пути от устройства до почтового ящика.

Чтобы включить терминацию SSL, необходимо изменить настройки zimbraReverseProxyMailMode, zimbraMailMode и zimbraReverseProxySSLToUpstreamEnabled, которые по умолчанию выставлены как https, https и TRUE. Для того, чтобы Zimbra Proxy устанавливали между собой незашифрованное соединение, нужно выставить следующие параметры на соответствующих серверах:

zmprov ms 'proxyhostname' zimbraReverseProxySSLToUpstreamEnabled FALSE
zmprov ms 'proxyhostname' zimbraReverseProxyMailMode both
zmprov ms 'mailboxhostname' zimbraMailMode both

Список почтовых серверов, которые будет опрашивать Zimbra Proxy после аутентификации пользователя находится в файле /opt/zimbra/conf/nginx/includes/nginx.conf.zmlookup. Записи о серверах представлены в виде zm_lookup_handlers https://mailbox.example.ru:7072/service/extension/nginx-lookup;

В списке должны быть перечислены только почтовые сервера. Попадание в него узлов MTA или LDAP грозит значительным замедлением процесса входа в учетную запись. Для того, чтобы исключить из списка лишние записи, введите следующую команду с указанием имени сервера, которого там быть не должно: zmprov ms mta.example.ru zimbraReverseProxyLookupTarget FALSE. В случае, если это не помогло, проверьте корректность глобальной настройки zmprov gcf zimbraReverseProxyLookupTarget

В случае, если почтовый сервер подвергается высоким нагрузкам, в определенные моменты пользователи могут сталкиваться с ошибкой 504 Gateway Timeout, которая связана с тем, что сервер просто не успевает обрабатывать запрос от пользователя. Для того, чтобы минимизировать вероятность появления такой ошибки, можно настроить ряд параметров при обращении к серверу. Среди них:

zmprov mcf zimbraMailProxyReconnectTimeout - время в миллисекундах, по истечении которого Zimbra Proxy будет предпринимать попытку повторного соединения с почтовым сервером в случае возникновения каких-либо проблем. Рекомендуется установить это значение на 125 миллисекунд.

zmprov mcf zimbraMailProxyMaxFails - максимальное количество допустимых ошибок при соединении с почтовым сервером. Рекомендуется установить это значение на 5 попыток. Таким образом Zimbra Proxy сообщит пользователю об ошибке лишь после пяти неудачных попыток подключения к почтовому серверу. 

После изменения этих значений, перезагрузите Zimbra Proxy с помощью команды zmproxyctl restart 

Отметим, что в инфраструктуру Zimbra OSE можно добавить несколько Zimbra Proxy. В таком случае перед ними необходимо устанавливать балансировщик нагрузки, который будет распределять запросы от клиентов на подключение к своим почтовым ящикам между различными узлами Zimbra Proxy. Также балансировщик нагрузки позволяет осуществлять терминацию SSL-соединения вместо Zimbra Proxy, однако подходить к его использованию надо с умом. Так, если вы используете облачные сервисы для балансировки нагрузки, то вам не следует включать на них терминацию SSL, так как это ставит под удар данные пользователей, которые будут передаваться на ваш сервер в открытом виде. В том же случае, если сервер с балансировщиком нагрузки находится на одной площадке с остальной инфраструктурой Zimbra OSE, можно включить на нем терминацию SSL-соединения, поскольку это не создаст дополнительных рисков по сравнению с использованием SSL-терминации на узлах Zimbra Proxy.

По всем вопросам, связанными c Zextras Suite и Team Pro вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com.