Главная Exchange/UC, Без рубрики, Новое Edge или не Edge, а если Edge, то как?
  • Edge или не Edge, а если Edge, то как?

    0На форумах часто можно встретить вопрос: «А нужен ли мне Exchange Edge-сервер? И если нужен, то зачем?» Вот именно на него, и не только, я и постараюсь ответить в этой статье.

    Позиция самой компании Microsoft заключается в том, что Edge-сервер нужен в обязательном порядке. И действительно, если вы имеете полностью Windows-ориентированную инфраструктуру, то в пользу внедрения сервера Exchange 2007/2010 Edge могут быть выдвинуты следующие утверждения:

    Exchange 2010 Edge позволяет уменьшить область атаки на организацию и сократить объем потенциально доступных злоумышленнику данных, просто потому, что он их не содержит;

    1. Exchange 2010 Edge содержит набор дополнительных транспортных агентов, которые отсутствуют на HUB-сервере;
    2. Exchange 2010 Edge тесно интегрируется с Microsoft Forefront Protection for Exchange 2010 (FPE);
    3. Простота администрирования сервера в целом, т.к. администратору придется управлять системой Windows Server 2008 и MS Exchange Server 2010 через уже знакомый интерфейс.

    Что касается вопроса отказа от установки Exchange 2010 Edge, то тут, на мой взгляд, может быть несколько вариантов:

    1. Прямая публикация сервера HUB. Крайне не рекомендуемый вариант;
    2. Фильтрация почты «на стороне», в результате которой на ваш внутренний HUB-сервер приходи уже «чистый» поток почты. Подобный вариант может быть реализован на базе услуг, предоставляемых вашим Интернет-провайдером, либо можно использовать облачный сервис компании Microsoft – cлужбу Forefront Online Security for Exchange;
    3. Использование в качестве пограничного почтового сервера альтернативного программного продукта. Например, Linux-подобных серверов. При этом нужно учитывать, что вам необходимо иметь в штате специалиста, способного управлять этим сервером.

    Очевидно, что к вопросу планирования инфраструктуры нужно подходить осознанно, взвесив все «за» и «против».

    Особенности сервера Edge Transport

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

    Отличительно особенностью роли Edge Transport является то, что она не может быть установлена совместно ни с какими другими ролями сервера Exchange, при этом, настоятельно рекомендуется сервер с этой ролью размещать в демилитаризованной зоне (DMZ) не включая его в центральный домен Active Directory. Кроме того, на сервере с ролью Edge Transport отсутствуют многие механизмы, работающие на других серверах Microsoft Exchange 2010, например, модель управления доступом на основе ролей (RBAC), удаленный доступ к PowerShell (Remote PowerShell), агенты расширения командлетов и т.д.

    Хранимая информация

    В целях безопасности, количество информации, хранимое на Edge сервере, сведено к минимуму. Здесь хранится только база данных с очередью сообщений и максимально урезанная копия базы данных Active Directory. Копия настолько урезана, что даже если злоумышленник получит к ней доступ, то он не может извлечь практически ни какой полезной информации, пожалуй, лишь только список пользователей, но без паролей. Информация из Active Directory необходима для обеспечения функции фильтрации получателей. С этой целью на Edge сервер, не включенный в домен, устанавливается служба облегченного доступа к каталогу (AD LDS).

    Сетевое взаимодействие

    Что касается сетевой безопасности, то Edge сервер должен быть изолирован как от внешней сети, так и от внутренней, брандмауэрами (firewall`ми). При этом на них достаточно открыть только следующие порты:

    Внешние:

    o 25 (в обе стороны) – Получение и отправка SMTP-почты;

    o 53 – разрешение имен при помощи внешнего DNS сервера.

    Внутренние:

    o 25 – Получение и отправка SMTP-почты через HUB сервер;

    o 50636 – Безопасные LDAP соединения с HUB сервером для обновления информации в AD LDS;

    o 3389 – RDP-подключения для удаленного управления сервером.

    Управление

    После установки роли Edge Transport устанавливается облегченная версия графической консоли управления (EMC), через которую доступен только минимально необходимый набор действий. При этом командная консоль (EMS) также содержит лишь малую часть существующих командлетов. Например, отсутствуют такие командлеты как Get-Mailbox и Set-MailboxDatabase просто потому, что нет необходимости выполнять подобные действия на пограничном сервере.

    На только что установленном сервере Edge Transport вы сможете найти уже созданный соединитель получения. Он конфигурируется во время установки таким образом, что позволяет принимать весь SMTP трафик со всех серверов, при этом анонимные подключения также доступны по умолчанию, в отличии от аналогичного соединителя на Hub`e.

    Конфигурирование потока почты

    Т.к. мы рассматриваем рекомендуемый компанией Microsoft сценарий, когда пограничный транспортный сервер не является членом основного домена Active Directory, а входит в рабочую группу, то для успешной обработки входящего и исходящего потока почты ему нужно быть особым образом сконфигурированным. Здесь есть два варианта:

    1. Ручное создание отправляющих и получающих соединителей, как на Edge-сервере, так и на Hub`e;
    2. Автоматическая настройка при помощи подписки (Edge Subscription) на транспортный сервер (Hub Transport) в основной организации Exchange.

    Что касается первого варианта, то это далеко не самый правильный подход и если коротко, то он будет заключаться в ручном создании следующих соединителей (см.рис.1):

    1. Получение внешней почты Edge сервером;
    2. Оправка почты с Edge-сервера на Hub-сервер;
    3. Получения Hud-сервером почты с Edge-сервера;
    4. Отправка локальной почты в Интернет через Edge-сервер;
    5. Прием Edge-сервером почты с Hub-сервера;
    6. Отправка Edge-сервером почты в Интернет.

    image

    Рис.1: Маршрутизация сообщений через Edge Transport.

    Как вы видите, дело весьма хлопотное, к тому же, лишающее нас некоторых «вкусностей», которые дает непосредственное подключение к базе данных Active Directory (например, функция фильтрации получателей). Следовательно, этим путем мы не пойдем, а сделаем все «по уму», для этого более подробно рассмотрим второй вариант.

    Edge Synchronization

    Edge Synchronization (EdgeSync) – это процесс синхронизации Edge-сервера с сайтом Active Directory, через сервер HUB Transport. Данный процесс устанавливается в ходе создание пограничной подписки (Edge Subscription). Полученную в ходе синхронизации информацию, сервер хранит в своей собственно базе данных, которой управляет служба облегченного доступа к каталогу AD LDS (Active Directory Lightweight Directory Service). База данных AD LDS работает на том же самом движке ESE (Extensible Storage Engine), что и «настоящая» база данных АД, и содержит в себе очень сильно урезанную её реплику.

    Примечание: Для изменения портов и каталогов, используемых службами AD LDS, можно воспользоваться поставляемым с Exchange 2010 сценарием ConfigureAdam.ps1

    Нужно заметить, что синхронизация носит отнюдь не односторонний характер. В процессе синхронизации, создается сопоставление членства пограничного транспортного сервера в сайте Active Directory, другими словами, для Edge-сервера создается отдельный объект в базе данных AD, одним из свойств которого является атрибут msExchServerSite равный имени сайта, в который входит Hub Transport, на который произведена подписка (см.рис.2). Это позволяет всем транспортным серверам организации, маршрутизировать сообщения до Edge`a при помощи внутренней таблицы маршрутизации, построенной на базе связей между сайтами Active directory (т.е. отдельный соединитель отправки с Hub`a на Edge не нужен!).

    image

    Рис.2: Объект пограничного транспортного сервера (Edge) в базе данных Active Directory.

    Подробнее про маршрутизацию сообщений между сайтами можно почитать в статье «Маршрутизация сообщений Microsoft Exchange 2010 в многосайтовой среде Active Directory»

    Примечание: К одному сайту может быть подключено несколько Edge-серверов, но один Edge-север может быть связан только с одним сайтом.

    Пограничная подписка (Edge Subscription)

    Пред конфигурированием подписки необходимо указать на Edge-сервере DNS-суффикс вашего домена!

    Создать и активировать подписку Edge сервера совсем не трудно, для этого нужно выполнить два несложных действия:

    1. Генерируем XML-файл подписки на Edge-севере при помощи команды:

    New-EdgeSubscription –FileName “c:\temp\Edge.xml”

    В результате сервер удалит свою конфигурацию маршрутизации (соединители отправки и обслуживаемые домена) и приготовится получить её с Hub Transport`a, также будет заблокирован ряд командлетов. Параметры, которые Edge получает c Hub Transport`a теперь нельзя будет изменять на нем, все настройки нужно будет делать на Hub`e и в ходе синхронизации они автоматически будут применены на Edge`e.

    2. Копируем XML-файл на HUB и активируем подписку. Это можно сделать либо через командлет New-EdgeSubscriprion, либо при помощи мастера (рис.3):

    image

    Рис.3: Активация подписки при помощи мастера.

    Примечание: Не забудьте оставить галочку «Автоматически создать соединитель отправки для этой пограничной подписки»!

    После того, как подписка будет создана, Hub Transport предпримет попытку создать защищенную LDAP сессию по TCP порту 50656 с Edge-сервером. Предварительно будет сгенерирован открытый ключ для шифрования LDAP сессии, и этот ключ будет помещен в атрибут msExchEdgeSyncCredential объекта сервера Hub Transport. Спустя непродолжительное время все сервера с ролью Hub Transport в сайте «узнают» из базы данных Active Directory о том, что сайт подключен к Edge-серверу и соответствующим образом изменят свои таблицы маршрутизации.

    Примечание: Подписка может быть создана между транспортными серверами с разной версией сервера Exchange (например Hub 2010, а Edge – 2007), но в таком случае каждый раз будет происходить полная синхронизация, а не передача дельты с изменениями.

    После завершения первой синхронизации на сервере Hub Transport будет создан специальный конфиг, в рамках которого Hub по расписанию будет синхронизировать изменения. Подробно конфигурацию синхронизации можно посмотреть при помощи команды:

    Get-EdgeSyncServiceConfig | FL

    4_

    Рис.4: Параметры синхронизации.

    Как мы видим из рис.4, при помощи командлета Set-EdgeSyncServiceConfig мы можем настроить много различных параметров, например, интервалы синхронизации для конфигурации и получателей (ConfigurationSyncInterval и RecipientSyncInterval), параметры монопольной блокировки прав синхронизации экземпляром службы EdgeSync (LockDuration и LockRenewalDuration) (блокировка делается с той целью, чтобы во время синхронизации никакая другая служба EdgeSync не смогла выполнять синхронизацию), а также включить ведение логов изменив значение LogLevel с None на Low, Medium или High и т.п.

    Проверка состояния подписки

    Первым признаком того, что подписка прошла удачно является появление соединителей отправки и обслуживаемых доменов на Edge-сервере.

    Чтобы форсировать процесс синхронизации вы можете в ручном режиме запустить командлет Start-EdgeSynchronization. Если у вас несколько серверов, то можно указать непосредственно, кого с кем синхронизировать, следующим образом:

    Start-EdgeSynchronization –TargetServer Edge1 –Server Hub1

    Если по каким-либо причинам синхронизация не прошла, то командлет Test-EdgeSynchronization поможет вам локализовать проблему. К нему также применимы различные параметры, подробнее о которых можно почитать в библиотеке TechNet`a (http://technet.microsoft.com/en-us/library/aa996925.aspx)

    Кроме того, можно просмотреть данные, которые находятся непосредственно в базе данных AD LDS на Edge-сервере. Для этого на Edge`e запустим оснастку ADSIEdit и подключимся к контексту Конфигурация. Для подключения к базе AD LDS нужно использовать порт 50389, так что настройки будут выглядеть следующим образом (рис.4):

    image

    Рис.5: Подключение к базе данных AD LDS на Edge-сервере.

    Аналогичным образом можно просмотреть и контекст именования (например, чтобы получить список реплицированных получателей), только тут подключаться придется к OU=MsExchangeGateway (рис.5):

    image

    Рис.6: Информация в реплике базы данных Active Directory в службе AD LDS.

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

    Маршрутизация почты через подписанный Edge Transport сервер

    Давайте вспомним рис.1, который утверждает, что для успешной отправки и получения писем через Edge Transport необходимо иметь минимум шесть соединителей. На самом деле так оно и есть, вот только после подписки пограничного транспортного сервера на сайт Active Directory ситуация несколько меняется и часть соединителей модифицируется во внутренние маршруты в таблицах маршрутизации серверов Hub Transport, а часть получают некоторые специфические настройки. Давайте рассмотрим их подробнее, согласно рис.1:

    1. Получение внешней почты Edge сервером – здесь остается «штатный» соединитель получения, который управляется непосредственно с Edge сервера и ни как не зависит от пограничной подписки.

    2. Оправка почты с Edge-сервера на Hub-сервер – соединитель EdgeSync – Inbound to Default-First-Site-Name создается и конфигурируется на Hub`e. Имеет весьма примечательное адресное пространство и промежуточный узел для маршрутизации. У него эти параметры равны двум минусам «» (см.рис.7). Такое адресное пространство используется только для соединителей отправки, настроенных на пограничных транспортных серверах (Edge) для отправки сообщений на транспортный сервер-концентратор (Hub). При использовании этого адресного пространства все сообщения, отправляемые в обслуживаемые домены, маршрутизируются через этот соединитель.

    image

    Рис.7: Соединитель отправки EdgeSync – Inbound to Default-First-Site-Name.

    3. Получение Hud-сервером почты с Edge-сервера происходит через «штатный» соединитель получения, созданный при начальной установке и не требующий дополнительного конфигурирования.

    4. Отправка локальной почты в Интернет с Hub`a через Edge-сервер – для отправки письма на Edge, Hub Transport пользуется внутренней таблицей маршрутизации, построенной на базе связей между сайтами.

    5. Прием Edge-сервером почты с Hub-сервера – получает почту Edge сервер через тот же соединитель получения, что используется и для входящей Интернет-почты.

    6. Отправка Edge-сервером почты в Интернет осуществляется через соединитель отправки EdgeSync – Default-First-Site-Name to Internet, который имеет классические настройки.

    Заключение

    На этом все, что я хотел рассказать про роль Edge Transport сервера Microsoft Exchange. Считаю, что данный сервер следует устанавливать в организации, т.к. конфигурирование его совсем не сложное, а вот пользы в плане борьбы со спамом и вирусами он может принести весьма много.

    Алексей Богомолов (Alexx), MVP
    http://alexxhost.ru

Комментарии

  1. а как же SBS 2011
    или от безысходности все на одном сервере ?

  2. А что SBS 2011? Ни кто вам не мешает поднять на соседнем сервере Edge и сделать подписку на HUB SBS`a. Не вижу причин по которым это не будет работать.
    ЗЫ Поднять Edge на одном сервере с SBS-ом по понятным причинам не получиться.
    ЗЫ2: В случае с SBS-ом возможно и будет достаточно активировать анти-спам агенты прямо на хабе, или воспользоваться подпиской на облако с Forefront Online Security for Exchange.

  3. мда… не густо, просто пересказ Technet. Ни тебе про агентов и порядок в котором они работают, ни про возможности фильтрации. Тупо next->next->finish

  4. to DenisO: Спасибо за Ваш отзыв.
    Нельзя все уместить в рамки одной статьи. Целью именно этой статьи является ознакомление читателя с Edge сервером как таковым и делается акцент на процессе синхронизации его с основной организацией Exchange, т.к. это первое, с чем сталкивается администратор при его внедрении.
    “Тупо next->next->finish” – это вы о чем? Статья более теоретическая, нежели чем практическая, она не описывает сам процесс создания подписки, т.к. он убирается в 2 строчки текста.

  5. «Тупо next->next->finish» — это вы о чем? Статья более теоретическая, нежели чем практическая

    А он ее не читал))))))

  6. Как-то мне приходилсоь настраивать Edge так, чтоб он мог быт промежуточным (relay) для другой почтовой системы со своим доменом, находящейся внутри сети. Решилось просто, но поиск решения был увлекателен.

    Не хотить статью дополнить этой инфрамацией?

  7. to Argon:
    Эту наверно уже не стоит раздувать, она и так не маленькая получилась, а вот ещё одну про Edge можно написать. Намекните, что вы сделали, мне на мыло alexey_b @ list dot ru, буду вам признателен.

  8. AD LDS (Active Directory Light Wight Service) наверно просто очепятка
    должно быть Active Directory Lightweight Directory Services (AD LDS)
    в остальном огромное спасибо за статью а так же за «Маршрутизация сообщений Microsoft Exchange 2010 в многосайтовой среде Active Directory» очень позновательно и освежает память 🙂 (добавил Ваш блог в Favorites)

  9. Ну да, конечно, опечаточка вышла 🙂 Спасибо за внимательность.

  10. Спасибо большое, отличная статья. Особенно понравилось описание коннекторов. Я в свое время с этим парился. Мне бы данная инфа пару лет назад сэкономила бы время весьма. Уверен, что кому-то сейчас сэкономит!

  11. Здравствуйте!

    Alexx, подскажите пожалуйста. Мне нужно опубликовать Exchange 2010 в интернет для удалённого доступа НЕКОТОРЫХ пользователей AD. С IMAP/POP3 всё понятно, разрешается в свойствах конкретной учётки, а как быть с SMTP? Фильтрация по IP неподходит, EDGE нет. Как отключить доступ по SMTP к Exchange 2010 для отдельных пользователей AD? Аутентификация SSL/TSL.

    Спасибо.