Реклама

Exchange + pfsense

В этой статье подробное разберём, как установить exchange server в организации, безопасно выпустить его в интернет через pfsense, и сделать так, что бы все сторонние почтовые сервера доверяли нашему серверу.

Что у нас должно быть? Как минимум, active directory.

Особенности при установке первого сервера AD – не рекомендую называть домен реально существующим именем, то есть если у Вас уже существует сайт в интернете, который называется contora.tld не стоит также именовать внутренний домен. Почему? Потому что кроме роли контроллера домена сервер также установит роль DNS сервера. Что произойдёт в этом случае? На сервере DNS автоматически будет зарегистрирована зона contora.tld. При обращении к любым ресурсам в этой зоне, например к сайту который расположен у внешнего хостера, мы получим ответ что такой сайт не существует. Так как сервер ответственный за эту зону он справедливо полагает, что знает о ней всё. Можно конечно прописать IP сайта вручную, но для дальнейшего разделения интранета и интернета (внешней и внутренней сети) желательно использовать имя например contora.internal (или local, хотя периодически встречаются рекомендации не использовать данное имя, я за свою практику с проблемами не сталкивался).

В качестве DNS используйте только внутренние сервера.

Установка exchange на контроллер домена хоть и поддерживается, но не рекомендуется. Оба продукта весьма самодостаточны, и для дальнейшей бесперебойной работы крайне рекомендуется использовать два разных сервера. В рамках виртуальных машин труда это не составит, так как лицензия windows server позволяет запускать две копии операционной системы в рамках одного физического сервера.

Для баз и журналов exchange server необходимо выделить отдельный диск на сервере, это также упростит администрирование в дальнейшем. Планируйте размер баз заранее, исходить надо из того, сколько времени вы готовы затратить на восстановление базы из бекапа, при непредвиденной ситуации. Согласитесь, восстановить 100ГБ будет быстрее, через 1TB.

Продумайте, чем будете выполнять бекап – в софте обязательно должна быть поддержка exchange server. В этом случае база будет корректно заархивирована, а журналы БД удалены. Самый простой способ использовать windows backup.

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

https://docs.microsoft.com/ru-ru/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2019

Предварительные требования для установки можно найти по запросу exchange server prerequisites, подставьте свою версию сервера, в примере требования для exchange 2016:

https://docs.microsoft.com/ru-ru/exchange/plan-and-deploy/prerequisites?view=exchserver-2016

Далее, можно запускать мастер установки. Если предварительные требования соблюдены – проблем при установке не возникнет, мастер сам подготовит active directory для установки, установит необходимые компоненты.  Подготовка заключается в расширении схемы AD – то есть добавление классов и атрибутов в схему и создание контейнеров и объектов для хранения информации. Эти действия выполняет команда /PrepareAD. Мастер запустит её автоматически, единственное что от вас потребуется это ввести organization name – имя контейнера в котором будут хранится все настройки сервера. Найти и посмотреть что создалось можно через утилиту ADSIedit.

Для этого нужна открыть раздел AD конфигурация:

И по такому пути:

CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local

Мы увидим все настройки нашей организации exchange. Менять что либо вручную сильно не рекомендуется. Использовать можно для поиска проблем в сложных ситуациях, и когда есть четкое понимание что и для чего используется.

После установки и перезагрузки сервера мы получаем условно рабочий вариант. В данный момент нам доступно: https://localhost/owa – веб интерфейс пользователя.

https://localhost/ecp – интерфейс администратора и командная оболочка exchange management shell.

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

Я объясню. Схема с сертификатами работает следующим образом. Есть головной сервер, который называется корневым центром сертификации. Несколько десятков таких серверов уже добавлены в различные операционные системы, и по этой причине все выпущенные ими сертификаты являются доверенными. Эти сертификаты называются коммерческими и приобретаются за отдельную плату. Список доверенных центров сертификации можно увидеть запустив оснастку certmgr.msc. Там, в доверенных корневых центрах сертификации мы увидим все эти корневые сервера.

По умолчанию, на exchange сервере установлен самоподписанный сертификат, то есть выпущенный и подписанный самим exchange сервером. Ему доверяет только exchange сервер. Поэтому при доступе к веб интерфейсам мы получаем предупреждение. Что бы избежать этого, нам нужно сохранить данный сертификат на свой компьютер, и добавить его в доверенные корневые центры сертификации. Предупреждение больше показываться не будет. Но только на одном этом компьютере. В пределах организации нам это не очень подходит, поэтому обычно разворачивают свой внутренний центр сертификации и выпускают сертификаты с помощью него, а он в свою очередь по умолчанию является доверенным в нашем домене. Прочитать как развернуть центр сертификации можно в моей статье Установка Certification Authority

Проблему работы в домене мы этим решаем, но остается проблема внешних пользователей, доступа с мобильных устройств и .т.д. Для решения этих проблем нам подойдет только коммерческий сертификат.

Как видим на скриншоте, данный сертификат назначен службам IIS – то есть это все веб сервисы, включая outlook anywhere, который так же работает через web. По сути, извне нам нужны будут два порта – 25-й для получения почты с других серверов, и 443 для всего остального – MAPI over HTTP (outlook) Activesync и EWS (мобильные клиенты) OWA и ECP для web доступа.

 

В оснастке кстати можно создать либо самозаверенный сертификат, либо сгенерировать запрос на сертификат. Если с самозаверенным мы разобрались, то генерация запроса не очень понятна. Генерация запроса это создание сертификата запроса, который пока что не подписан не одним корневым центром сертификации. Вы можете скормить этот запрос либо своему центру сертификации, либо отправить его при запросе коммерческого сертификата, что бы корневой центр подписал этот запрос. В сертификате должны присутствовать все имена, по которым мы будем подключаться. В нашем случае это mail.contora.tld и autodiscover.contora.tld

И так, с сертификатами мы разобрались. Сертификат доверенный на нужных устройствах, и назначен нужным службам. При обращении через браузер мы должны видеть примерно такую картину:

Теперь, для проверки, заходим в OWA и пробуем отправить письмо сами себе. Если письмо доставлено – поздравляю. Доставка в организации работает. Давайте добавим домен, который будет маршрутизироваться в интернете. Как мы помним, в данный момент у нас contora.internal, и все новые пользователи будут автоматически создаваться с таким доменом. Для того что бы создать валидный внешний домен, перейдем во вкладку “accepted domains”(доверенные домены) и добавим новый авторитативный домен, с адресами которые будут работать в интернете.

Домены можно добавлять трех типов:

  1. Авторитативный. Обслуживается данным сервером, если ящик не обнаружен, то высылается отбивка о несуществующем адресе.
  2. internal relay. Обслуживается данным сервером, если ящик не обнаружен, то письмо пересылается на другой сервер, желательно создать новый коннектор с областью домена, и указать в качестве смарт хоста адрес сервера, куда перенаправлять почту. Помогает при переезде из другой почтовой системы
  3. external relay. Обслуживается данным сервером, сразу пересылается на другой сервер.

Что бы адреса новых пользователей создавались в соответствии с нашими пожеланиями и доменами используется политика адресов электронной почты:

Теперь, когда у нас есть адреса, нужно научить сервер отправлять письма наружу. Для этого нужно создать send connector.

Указываем отправку через MX, и область *, то есть все письма на все домены отправляем стандартно – определяем MX сервера через DNS.

Не забываем указать исходный сервер – так он у нас один его и добавляем.

Отправка наружу работает! Есть только дна проблема – письма не доходят. Это происходит потому что у нас не настроены корректно DNS записи.

Здесь есть несколько параметров настройки сервера, для его корректной проверки другими почтовыми серверами. Как проходит проверка?

У Вашего сервера должен быть прописан helo – имя, которым он представляется другим серверам:

Здесь нужно прописать имя, которое будет совпадать с Вашими MX серверами. IP адрес, с которого будет отправляться почта (скорее всего адрес интернет шлюза) должен разрешаться также в это имя. Это называется PTR запись, и настраивается она у провайдера, так как он как правило владеет IP адресом.

Проверить корректность настройки можно на сайте https://www.mail-tester.com/

Кроме того, обязательно нужно прописать spf запись для домена с которого отправляется почта, и разрешить отправлять с IP адресов с которых уходит почта. Более подробно описано здесь – STOP SPAM. PTR, SPF, DKIM, DMARC

Имейте ввиду, что записи DNS как правило кешируются, и не всегда настройки действуют сразу.

Теперь давайте опубликуем сервер через наш шлюз наружу – для этого будем использовать pfsense – виртуальный маршрутизатор.

Минимальный рабочий вариант просто пробросить порты 25 и 443. Делается это в разделе NAT.

Добавляем правило, интерфейс WAN, протокол TCP. Указываем порт назначения, куда перенаправлять трафик – в моем случае почтовый сервер 192.168.1.12 и redirect target port – https.

Обязательно включите внизу “create new associated filter rule”, в этом случае автоматически создастся правило в firewall, разрешающее трафик. Аналогично поступаем и с 25 портом.

Более безопасный способ это установить прокси сервер squid, и воспользоваться функционалом reverse proxy. Это позволит защитить наши веб службы от опасных действий. В этом случае создавать правило NAT на 443 порт не нужно, достаточно открыть 443 порт в firewall.

Пробрасываем через NAT только 25 порт.

Устанавливаем через менеджер пактов squid

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

External FQDN – mail.contora.tld

reverse HTTPS Default site – mail.contora.tld.

Reverse ssl certificate – в этом пункте нужно выбрать сертификат, который предварительно импортировать здесь:

Certification data – сам сертификат

Private key data – закрытый ключ сертификата

Как правило, два этих файла у вас есть. Открывать нужно блокнотом. Если файл в формате pfx – значит там и сертификат и закрытый ключ. Если интересно как разделить pfx на файлы пишите в комментариях, либо на наши форумы – itquestion.ru или forum.hobbycomp.ru

intermediate CA – промежуточный сертификат. Обычно присутствует в цепочке сертификатов поставщика. Открывается блокнотом.

Две последние колонки:

Compability mode – набор используемых шифров. Modern – наиболее современные, intermediate – наиболее совместимые.

В поле ниже нужно вписать адрес нашего почтового сервера, галочками отмечаем сервисы, которые должны быть доступны из интернета. В целом, этого достаточно для публикации exchange в интернет.

После описанных выше действий, Ваш почтовый сервер должен успешно отправлять и принимать почту. Осталось настроить почтового клиента – а именно outlook и мобильные клиенты.

Для настройки зайдём в ecp, серверы – виртуальные директории. У каждой виртуальной директории есть внешний и внутренний адрес.

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

Нам нужно настроить: ecp (админка), ews (мобильные клиенты), active sync (мобильные клиенты),OAB (адресная книга), OWA (веб доступ). Имена будем использовать одинаковые.  Не стирайте окончания ссылок, например для EWS – https://mail.contora.tld/EWS/Exchange.asmx

Для того что бы изнутри работали данные ссылки, в DNS внутри нужно создать зону mail.contora.tld и добавить в неё A запись без имени, которая ссылается на IP вашего почтового сервера.

Также нужно будет настроить каталог для outlook anywhere в разделе серверы:

Каталог MAPI over HTTPS. В exchange 2016 данный тип передачи данных включен по умолчанию. Поэтому нужно настроить соотвествующий каталог. Сделать это можно через EMS:

Set-MapiVirtualDirectory -Identity "MYEX01\mapi (Default Web Site)" -InternalUrl https://mail.contora.tld/mapi -ExternalUrl https://mail.contora.tld/mapi -IISAuthenticationMethods NTLM 

Еще нам надо настроить autodiscover. Эта служба автоматически сообщает клиенту нужные именно ему настройки,в зависимости от того, на каком сервере находится ящик. При работе в домене настройки берутся непосредственно оттуда – используется SCP – service connection point, запись в домене.

Если же подключение происходит из интернета, то проверяются несколько вариантов написания: contora.tld/autodiscover или autodiscover.contora.tld. Обычно используют второй вариант. Не забудьте добавить такую запись на внешних DNS.

Для настройки точки доступа SCP используйте командлет:

Set-ClientAccessService -Identity MYEX01 -AutoDiscoverServiceInternalUri https://autodiscover.contora.tld/Autodiscover/Autodiscover.xml

Всё! Можно тестировать и проверять работоспособность, как снаружи так и изнутри.

Снаружи нам поможет сервис microsoft – https://testconnectivity.microsoft.com/

Протестируем activesync и autodiscove. Изнутри смотрим как подключается outlook,  диагностические сведения можно получить нажав правой кнопкой мыши на значок outlook с зажатым ctrl, и выбрав “состояние подключения” либо “проверить автоконфигурацию электронной почты”

Свои вопросы и пожелания пишите в комментариях, либо на forum.hobbycomp.ru либо на itquestion.ru

 

 

Пока нет комментариев

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Реклама

Реклама