В статье Служба Exchange 2013 Transport вы найдете краткую информацию о принципе функционирования одной из основных служб транспортного конвейера Exchange 2013 – Транспортной службы на серверах с ролью MBX. Помимо внутреннего устройства службы, я расскажу о соединителях отправки и соединителях получения, связанных с Microsoft Exchange Transport.
Это вторая статья из серии, посвященной принципам работы служб транспортного конвейера Exchange 2013, а вот полный список:
- Служба Exchange 2013 FrontEnd Transport
- Служба Exchange 2013 Transport
- Служба Exchange 2013 Mailbox Transport
- Служба Exchange 2013 Edge Transport
А также статьи по управлению логированием этих служб:
- Логи Exchange 2013 FrontEnd Transport
- Логи Exchange 2013 Transport
- Логи Exchange 2013 Mailbox Transport
- Логи Exchange 2013 Edge Transport
Не забывайте об официальной документации.
Найти больше информации по настройке и администрированию Exchange 2013 на моем блоге вы сможете в основной статье тематики — Exchange 2013 — Установка, настройка, администрирование.
Содержание
Exchange 2013 Transport
Так уж получилось, что теперь в сервере Exchange 2013 существует достаточно много служб транспорта, имеющих схожие название, но фундаментально отличающиеся по назначению и принципу работу. Вот полный список этих служб:
- Транспортная служба переднего плана на серверах клиентского доступа (Отображаемое имя — Microsoft Exchange FrontEnd Transport, сокращенное — MSExchangeFrontEndTransport);
- Транспортная служба на серверах почтовых ящиков (Отображаемое имя — Microsoft Exchange Transport, сокращенное — MSExchangeTransport);
- Транспортная служба почтовых ящиков на серверах почтовых ящиков (Реально включает в себя две службы — Microsoft Exchange Mailbox Transport Delivery и Microsoft Exchange Mailbox Transport Submission, сокращенные имена — MSExchangeDelivery и MSExchangeSubmission соответственно);
- Транспортная служба на пограничных транспортных серверах (Отображаемое имя — Microsoft Exchange Transport, сокращенное — MSExchangeTransport).
При этом сопоставимый функционал выполняют только вторая и четвертая служба, остальные отличаются принципиально. Вместе все они образуют транспортный конвейер, являющийся сердцем почтового сервера. В этой статье речь пойдет о Транспортной службе на серверах почтовых ящиков.
Транспортный конвейер
В прошлой статье я рассматривал первый компонент транспортного конвейера Exchange 2013 – службу FrontEnd Transport (Транспортная служба переднего плана) на серверах клиентского доступа. Сейчас пришло время перейти ко второму компоненту – службе Microsoft Exchange Transport (Транспортная служба) на серверах почтовых ящиков. Напоминаю, что в общем плане транспортный конвейер 1 выглядит следующим образом:
В контексте данной статьи нас будет интересовать роль Сервер почтовых ящиков (MBX или MailBox Server) и конкретно одна служба этой роли – на рисунке выше ей дали имя Служба передачи. В реальности же она называется Microsoft Exchange Transport. Не заостряя внимание на Транспортной службе почтовых ящиков, получаем схему:
Именно в этом компоненте нам и предстоит разобраться.
Принцип работы
Хочу напомнить, что всего у Exchange 2013 есть три серверные роли – CAS, MBX и Edge (добавлена в Exchange Server 2013 SP1). При этом Транспортная служба присутствует на двух ролях – MBX и Edge – и обладает примерно одинаковым функционалом и возможностями. Некоторые отличия все же есть, но они сведены к минимуму. Конечно о них стоит рассказать, но сделаю это я вероятнее всего в отдельной статье.
По сравнению с Транспортной службой переднего плана на серверах CAS, схема Транспортной службы на MBX-серверах уже выглядит значительно сложнее и этому есть объяснение. Дело в том, что вся основная обработка почтовых данных происходит именно на Транспортной службе. Любое сообщение, отправленное или полученное, в любом случае пройдет через Транспортную службу на серверах почтовых ящиков, в отличие от Транспортной службы переднего плана (подробнее о потоке почты в зависимости от разной топологии Exchange читайте в статье Поток обработки почты при разной топологии Exchange 2013).
Итак, ниже описан порядок прохождения сообщений через определенные обработчики Транспортной службы на серверах почтовых ящиков:
1. Первым делом сообщения проходят через агенты транспорта 2 (на рисунке Агенты протокола), которые проводят фильтрацию по заданным критериям. Агенты могут быть как встроенными в Exchange Server 2013 (системными), так и написанными сторонними разработчиками ПО или даже администраторами организаций. Агенты позволяют расширять функционал почтового сервера Exchange путем добавления в логику обработки сообщений собственный код. Вызов агентов происходит при возникновении событий SMTP;
2. На предыдущем этапе отсеялись все лишние сообщения – зараженные письма, спам и т.п. – и сейчас пришло время поставить сообщения в очередь 3 отправки, после чего они будут переданы классификатору. В отличие от Транспортной службы переднего плана на серверах CAS, Транспортная служба серверов MBX и Edge уже сохраняет данные на сервере, пусть и только в виде различных очередей;
Сообщения также могут попасть сразу в очередь через каталоги раскладки и преобразования 4:
Каталог раскладки используется администраторами для проверки потока сообщений или приложениями, которые создают и отправляют собственные сообщения. Каталог преобразования получает сообщения с серверов внешних шлюзов и может использоваться для передачи сообщений, экспортированных администраторами из очередей серверов Exchange.
Главное назначение этих каталогов – передать сообщения классификатору, минуя агентов транспорта (к этому моменту для определенных сообщений может отсутствовать необходимость прохождения через агентов транспорта, например когда сообщение уже прошло через них на другом сервере MBX. Зачем делать одну и ту же работу дважды?);
3. Сообщения из очереди отправки попадают в классификатор, который определяет что необходимо сделать с сообщением на основе данных о его месте назначения 5. Через этот этап проходят любые сообщения, неважно каким способом и от кого они были получены. Как только определено конечное место назначения для обрабатываемого сообщения, идет поиск оптимального маршрута.
Казалось бы, чего тут думать – принял сообщение и сразу отправил его в базу данных на этом же сервере. Но на деле все функционирует значительно сложнее. Начнем с того, что Транспортная служба на серверах MBX вообще не занимается доставкой сообщений в базу (да, это действительно так. Сообщения в БД отправляет Транспортная служба почтовых ящиков на серверах MBX). Кроме того, конфигурация Exchange 2013 может быть очень сложной и иметь множество групп доступности баз данных (DAG) на разных серверах, да ещё и расположенных на разных сайтах AD или даже в разных лесах;
4. Пришло время снова поместить сообщения в очередь, но теперь уже в очередь доставки. В эту очередь попадают сообщения, для которых определен маршрут и известно место назначения. Стоит отметить, что в конкретный момент времени могут существовать несколько очередей в зависимости от количества мест доставки. Очереди динамически создаются при необходимости и удаляются, когда истекает срок их жизни (3 минуты по умолчанию) или когда становятся пустыми (то есть когда в них заканчиваются сообщения);
5. Последний этап – отправка сообщений в место назначения. Самое близкое назначение – Транспортная служба почтовых ящиков на этом же сервере MBX, но существует также огромное множество различных вариантов, подробнее читайте в официальной документации.
Пришло время рассмотреть каким образом сообщения попадают к Транспортной службе.
Соединители приема и соединители отправки
Транспортная служба на серверах MBX прослушивает различные порты для приема сообщений, в том числе от Транспортной службы переднего плана на CAS-серверах даже в том случае, если обе роли (MBX+CAS) установлены на одном и том же сервере. Для более наглядного представления предлагаю обратиться к иллюстрации:
Хочу отметить, что в соединителях отправки у меня активировано (имеет значение $true) свойство FrontendProxyEnabled. Этот параметр определяет поведение Транспортной службы MBX-сервера при отправке почты внешним отправителем – значение $true говорит о том, что почта наружу будет всегда уходить через сервер CAS (не считая случаев, когда используется сервер Edge. Подробнее читайте в статье Поток обработки почты при разной топологии Exchange 2013). В противном случае MBX-сервер может самостоятельно отправлять почту внешним получателям, минуя роль CAS.
Теперь разберемся какие соединители на каких портах работают.
По умолчанию при установке роли MBX создается два соединителя получения. Этими соединителями могут управлять системные администраторы, они доступны в EAC и PowerShell:
Помимо этих двух соединителей получения, существует также один скрытый соединитель отправки:
- Intra-Organization SMTP Send Connector (SMTP 25/2525 в Транспортную службу на других серверах почтовых ящиков)
В русскоязычной версии этот соединитель будет иметь имя Отправляющий соединитель SMTP Intra-Organization.
UPD: 12.06.2016: Судя по всему, соединитель Отправляющий соединитель SMTP Intra-Organization используется для двух задач:
- Отправка по SMTP на порт 2525 к Транспортной службе на других серверах почтовых ящиков;
- Отправка по SMTP на порт 475 к Транспортной службе почтовых ящиках на локальном сервере или на других серверах почтовых ящиков.
В принципе это логично и даже в некоторой степени вытекает из обозначений на иллюстрации транспортного конвейера из официальной документации. Тем не менее все равно странно, почему один соединитель отвечает за отправку сразу по двум портам. В любом случае логи подтверждают это предположение:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
192.168.1.7:10195,192.168.1.7:475,*,,Sending blob EPROP-1.2.0.0 192.168.1.7:10195,192.168.1.7:475,<,"250 2.6.0 CHUNK received OK, 1759 octets", 192.168.1.7:10195,192.168.1.7:475,>,BDAT 9409 LAST, 192.168.1.7:10195,192.168.1.7:475,<,250 2.0.0 OK, 192.168.1.7:10195,192.168.1.7:475,>,QUIT, 192.168.1.7:10195,192.168.1.7:475,<,221 2.0.0 Service closing transmission channel, 192.168.1.7:10195,192.168.1.7:475,-,,Local 192.168.1.5:2525,*,,attempting to connect 192.168.1.7:10215,192.168.1.5:2525,+,, 192.168.1.7:10215,192.168.1.5:2525,<,"220 EXCH02.sc.local Microsoft ESMTP MAIL Service ready at Thu, 9 Jun 2016 17:17:35 +0300", 192.168.1.7:10215,192.168.1.5:2525,>,EHLO EXCH01.sc.local, 192.168.1.7:10215,192.168.1.5:2525,<,250-EXCH02.sc.local Hello [192.168.1.7], 192.168.1.7:10215,192.168.1.5:2525,<,250-SIZE, 192.168.1.7:10215,192.168.1.5:2525,<,250-PIPELINING, 192.168.1.7:10215,192.168.1.5:2525,<,250-DSN, 192.168.1.7:10215,192.168.1.5:2525,<,250-ENHANCEDSTATUSCODES, 192.168.1.7:10215,192.168.1.5:2525,<,250-STARTTLS, |
Вывод немного сокращен – я убрал информацию о датах и названии соединителя, поскольку она дублируется от записи к записи (можете посмотреть полный кусок лога – transport service. Просматривайте лучше в Notepad ++). Тем не менее все записи относятся к соединителю Отправляющий соединитель SMTP Intra-Organization и идут под ряд!
Ещё из этого куска логов видно, что на 475 порт сервер отправляет сам себе (трафик идет от Транспортной службы к Транспортной службе почтовых ящиков на этом же сервере), но есть и примеры, когда отправка идет на другой сервер (оба в DAG):
1 2 3 4 |
192.168.1.7:10285,192.168.1.5:475,<,250-EXCH02.sc.local Hello [192.168.1.7], 192.168.1.7:10285,192.168.1.5:475,<,250-SIZE 36700160, 192.168.1.7:10285,192.168.1.5:475,<,250-PIPELINING, 192.168.1.7:10285,192.168.1.5:475,<,250-DSN, |
То есть отправка идет от Транспортной службы сервера 192.168.1.7 к Транспортной службе почтовых ящиков на сервере 192.168.1.5.
Такая вот история.
В процессе транспорта также участвуют соединители отправки, созданные вручную администраторами. Для отправки почты в интернет минимум необходим один такой соединитель. Без него почта будет бегать только внутри вашей организации Exchange (см. статью Соединители отправки Exchange 2013). Итак, сведем все в отдельную таблицу:
Название | Назначение | Порт | Направление |
Default <Server Name> | Прием | 25/2525 | От других MBX-серверов в организации |
Client Proxy <Server Name> | Прием | 465 | Трафик, который принимают CAS-серверы на 587 порт |
Intra-Organization SMTP Send Connector | Отправка | 25/2525 | На другие серверы MBX в организации |
Созданный вручную соединитель отправки | Отправка | 717 | На внешние серверы |
В соответствии с данными таблицы получаем схему соединителей для Транспортной службы на серверах почтовых ящиков:
На этом краткий обзор Транспортной службы серверов Exchange 2013 с ролью MBX завершен.