Поток обработки почты при разной топологии Exchange 2013

Поток обработки почты при разной топологии Exchange 2013

www.microsoft.com

Поток обработки почты при разной топологии Exchange 2013 в некоторых случаях будет отличаться очень значительно, особенно при использовании пограничных транспортных серверов. При этом нужно понимать каким образом идет движение и обработка сообщений хотя бы для того, чтобы на нужном вам этапе знать log-записи каких служб/ролей отслеживать.

В этой статье я постараюсь дать краткие сведения о порядке движения сообщений при разных комбинациях ролей Exchange 2013. При этом я пока обойдусь без сложных топологий Active Directory с множеством сайтов и групп доступности баз данных (DAG) Exchange 2013.


Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.


Поток обработки почты при разной топологии Exchange 2013

Exchange 2013 имеет две основные роли — Client Access Server (CAS) и Mailbox Server (MBX) — и одну роль второго плана — Edge Server (добавлена в Exchange 2013 SP1). Роль пограничного транспортного сервера (Edge) всегда располагается на отдельном сервере, который при этом ещё и желательно размещать в демилитаризованной зоне, не вводя в домен. Сам факт наличия сервера Edge необязателен для работы почтового сервера Exchange 2013.

С двумя другими ролями все немного сложнее — они могут быть установлены как на одном, так и на разных серверах. В зависимости от того, какой вариант выбран, поток обработки почты будет отличаться. Сложности добавляет ещё и то, что присутствие Edge-сервера в цепочке обработки почты также вносит некоторые изменения в этот процесс. Попробуем разобраться как бегает почта от отправителя к получателям на примере разных топологий.

CAS и MBX на одном сервере, Edge отсутствует

Самый простой вариант, встречающийся в организациях малого и среднего размера. Позволяет экономить на лицензиях ОС и почтового сервера Exchange 2013, а также на необходимых серверных мощностях и системах хранения данных.

Предположим, что параметр FrontendProxyEnabled у единственного соединителя отправки установлен в значение $true (подробнее читайте в Exchange 2013 FrontEnd Transport). Это говорит о том, что вся исходящая наружу почта проходит через Транспортную службу внешнего интерфейса на сервере CAS. В этом случае порядок прохождения почты через транспортный конвейер будет выглядеть так 1:

mailflow 01

На рисунке слева от красной черты изображен путь движения сообщений, когда отправитель внутри организации посылает почту внешним получателем (черные стрелки вверх) в интернет и когда сам выступает в роли получателя от отправителей из интернета (черные стрелки вниз).

Справа от красной разделительной черты показан случай движения сообщений от внутреннего отправителя к внутреннему получателю.

CAS и MBX на одном сервере, почта через Edge

Этот вариант наиболее предпочтителен для небольших и средних организаций, которые очень внимательно относятся к вопросам безопасности. Edge-сервер является пограничным сервером, осуществляющим антивирусную защиту, а также защиту от спама. Поскольку он чаще всего не включен в домен, а находится в изолированной рабочей группе, это значительно меньше подвергает основные серверы Exchange 2013 возможности влияния злоумышленников. При этом роль Edge вполне может быть развернута на шлюзе Forefront TMG 2010, этот вариант официально поддерживается со стороны Microsoft и даже рекомендуется для экономии лицензий ОС.

Рассмотрим подробнее какой путь проделывает входящая и исходящая почта:

mailflow 02-1

Как можно заметить, получаемая от внешних отправителей почта все также проходит путь через Транспортную службу переднего плана (FrontEnd Transport на сервере CAS), только входной точкой является Транспортная служба на пограничных транспортных серверах (Edge Transport на сервере Edge).

При этом почта, отправленная изнутри организации внешним получателям, уже никогда не будет проходить через FrontEnd Transport на сервере CAS:

Если в сети периметра установлен пограничный транспортный сервер, сообщения, отправленные внешним получателям, никогда не направляются через транспортную службу внешнего интерфейса на сервере клиентского доступа. Сообщение направляется от транспортной службы на сервере почтовых ящиков в транспортную службу на пограничном транспортном сервере.

Поток почты от внутренних отправителей внутренним же получателям без изменения.

С этим вариантом разобрались, пришло время разделить роли CAS и MBX.

CAS и MBX на разных серверах, Edge отсутствует

Пока взглянем на вариант без Edge-сервера. По умолчанию при установке Exchange 2013 создаются 5 соединителей отправки, из которых 3 принадлежат роли CAS, а другие два роли MBX. При этом принимающий от внешних серверов почту коннектор находится именно на роли CAS и называется Default Frontend <Server Name>. Логично предположить, что вся входящая почта будет проходить именно через него, а реально обрабатываться уже на серверах MBX:

mailflow 04

Если параметр FrontendProxyEnabled на соединителях отправки все также установлен в значение $true, то исходящая почта будет проходить через серверы CAS. В противном случае почта может отправиться в интернет сразу с сервера MBX через Транспортную службу на серверах почтовых ящиков (Transport).

CAS и MBX на разных серверах, почта через Edge

Пожалуй, самый сложный вариант из всех рассматриваемых. Более актуален для крупных организаций, где востребованы фермы CAS-серверов для балансировки нагрузки и/или повышения уровня отказоустойчивости. Edge-сервер (или даже целый пул Edge-серверов) обеспечивает повышенную безопасность и устойчивость к атакам извне.

mailflow 03

В этом случае почта через серверы CAS не идет вообще никогда — ни при получении от внешних отправителей, ни при отправке внешним получателям. Сервер CAS в этом случае используется как точка входа для различных типов клиентов (Outlook, OWA, IMAP, POP и т.п.), а весь поток обработки почты идет через связку Транспортная служба на пограничных транспортных серверах — Транспортная служба на серверах почтовых ящиков и далее в базу данных с помощью MailBox Transport.

Надеюсь я внес ясность в сложный процесс обработки сообщений в Exchange 2013, а может быть и ещё больше вас запутал.

comments powered by HyperComments