Настройка Edge+TMG+FPE

Amigo

9 лет назад

Продолжаем настраивать Exchange. Сегодня мы настроим TMG, Edge, FPE, внешний адрес домена, и пробросим порты с обычного wi-fi роутера внутрь виртуалок.

Давайте вспомним что у нас есть на текущий момент:

CAS1 192.168.100.2 (NLB 192.168.100.13)
mail.test.ru 192.168.100.100
CAS2 192.168.100.3 (NLB 192.168.100.14)

Mailbox1 192.168.100.4 (DAG 192.168.200.1) DAG 192.168.100.12
Mailbox2 192.168.100.5 (DAG 192.168.200.2)

Database 192.168.100.8
DC 192.168.100.1

Всё это находится у нас в сети 192.168.100.024, за исключением кластера DAG с отдельной подсетью. Но так как эта сеть используется только для репликации баз между серверами, роли она не играет.

Для наглядности посмотрим схему инфраструктуры которая должная получиться.

Наша почта работает, но пока что только в пределах компании, нам же нужно работать и с внешней почтой.

DNS

Сначала настроим работу с внешним доменом. Для этого нам понадобится зарегистрировать доменное имя, если у нас его до сих пор нет. В нашем примере будем использовать имя lifebay.ru.

Для его работы, нам нужно прописать на DNS серверах следующие записи:

Для хоста lifebay.ru – это будет основной сайт mail.lifebay.ru – для OWA и в качестве почтового сервера для отправки почты, autodicover.lifebay.ru соответственно для autodiscover, и еще пропишем их аналоги с www.

Если кто не знает, www прописывается отдельной A записью в DNS, желательно что бы он был, для совместимости.

Кроме того понадобится MX запись – будет указывать на почтовый сервер для домена который указан после @ в адресе посты.

И записи для борьбы со спамом:

PTR (pointer record) запись преобразует IP в адрес хоста (обратный запрос DNS). Когда Ваш почтовик отправляет письмо с некого домена, например microsoft.com, то принимающая сторона смотрит заголовок в письме, вытаскивает из него IP адрес хоста отправителя письма, резолвит его по PTR записи в домен, и если видит вместо домена microsoft.com нечто иное понимает что её наглым образом обманывают.

SPF (Sender Policy Framework) запись. Еще одна запись для борьбы со спамом. Суть в следующем. В DNS Вы создаёте специальную TXT запись, в которой указываете, что для такого то домена отправка почты разрешена с таких то серверов или IP. Например запись

Говорит нам, что для домена lifebay.ru могут отправлять почту все сервера, которые указаны в MX записях для этого домена. Значение ~all в конце разрешает принимать почту с других доменов, но предупреждает, что эта почта подозрительная. Если написать в конце -all, то почта пришедшая с других доменов, кроме указанных в MX будет однозначно отбрасываться.

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

Внешние DNS сервера могут быть либо собственные, либо предоставленные провайдером за отдельную плату. Я же делегировал управление зоной lifebay.ru на сервера бесплатного DNS хостера cloudflare.com.

Админка cloudflare с настроенными записями выглядит следующим образом:

Тип SPF записи в нём есть, но непонятно читается он или нет. Поэтому создадим просто понятную всем TXT для сервера который будет отправлять почту – mail.lifebay.ru.

Проверим утилитой nslookup:

Установка EDGE

Пока ждём обновления DNS, мы установим сервер Edge, которому отводится ответственная роль – работать на переднем плане, отправлять и получать почту в/из интернета, проверять и отсеивать спам.

EDGE сервер это по сути сильно урезанный hub transport, с установленными антиспам агентами (которые кстати можно ставить и на обычный сервер, с ролью hub transport)

Также установим TMG – прокси сервер, и хотя компания microsoft отказалась от его выпуска еще в 2012 году, он до сих пор используется во многих компаниях, поэтому рассмотрим и его настройку. Дополнительно установим Microsoft Forefront Protection 2010 for Exchange Server, специально разработанный для фильтрации спама и вирусов в почте.

Перед установкой роли Edge установим новый windows server 2008R2, с двумя сетевыми интерфейсами – один будет смотреть во внутреннюю сеть, другой во внешнюю. В домен сервер вводить не будем, для безопасности microsoft не рекомендует это делать. Доступ де к данным из AD мы будем получать из AD LDS – это сервис облегченной службы каталогов. Проще говоря это еще один экземпляр AD, только локальный и содержащий нужные нам данные.

Также нам понадобится еще один коммутатор – External (внешний). Этот тип коммутатора способен взаимодействовать с физическим сетевым интерфейсом, то есть выходить в интернет.

В моём случае я нахожусь за роутером, поэтому внешней сетью будет сеть роутера 192.168.1.024, а через роутер попробуем сделать проброс портов.

После создания коммутатора добавим нашему виртуальному серверу еще один интерфейс, и назначим его коммутатору External.

Теперь у нас один интерфейс смотрит в коммутатор private (частный), а второй в коммутатор external (внешний).

Важный момент, так как сервер edge у нас должен быть максимально изолирован от всех остальных серверов, то в домен мы его не вводим.

Запускаем виртуальную машину, переименовываем её, и добавляем DNS суффикс, тогда имена типа CAS1 автоматически будут преобразовываться в FQDN cas1.test.ru

После перезагрузки заходим в центр управления сетями, и видим что обе сетевые карты получили IP от разных DHCP серверов.

Переименуем интерфейсы, внутренний назовём LAN, внешний WAN.

Теперь настроим взаимодействие между серверами. Добавим в DNS запись о сервере EDGE.

Так как сервер у нас будет не в домене, установим службы AD LDS, Облегченные службы каталога Active Directory.

Теперь скопируем дистрибутив exchange на сервер. Можно сделать это командлетом:

Copy-VMFile -Name exchange2008_cas2 -SourcePath D:chrom_downloadsExchange2010-SP2-x64.exe -DestinationPath C: -CreateFullPath -FileSource Host

либо любым другим способом.

Запускаем установщик, выбираем выборочную установку, компонент edge transport role, и ставим внизу галочку – автоматически добавить необходимые компоненты.

Forefront protection for exchange 2010

Microsoft Forefront Protection 2010 for Exchange Server, обеспечивает антивирусную и антиспам проверку, тесно интегрирует с работой Edge и TMG. Сложностей в установке я думаю никаких не будет.

Сообщение о том что потребуется перезапуск служб.

Если для выхода в интернет используется прокси, вводим данные.

Включим антиспам сразу.

Установка начианется

И заканчивается. Галочку не ставим, вместо этого у нас будет TMG, предлагается же FOPE (он-лайн решение).

TMG

Следующим установим TMG. Запускаем установку, выбираем “средство подготовки к установке.” Этим мы установим нужные роли и компоненты для установки самого TMG.

Еще раз запускаем установку, выбираем “службы и диспетчер forefront TMG”.

Далее нас просят просят выбрать внутренний и внешний диапазоны. Так как у нас две сетевые карты, LAN и WAN, то для внутренней сети соответственно LAN, для внешней WAN.

Установка процесс не самый быстрый, поэтому запаситесь терпением. После завершения установки, нужно настроить некоторые параметры, например место в топологии сети и её параметры.

Так как у нас TMG на границе сети, выберем пограничный сетевой экран.

Настройка системных параметров – рабочая группа и имя сервера.

И настройка проверки трафика.

NIS – анализатор сетевого трафика протоколов HTTP, DNS, SMB, MSRPC, SMTP, POP3, IMAP, MIME. Может распознавать атаки по сигнатурам, или по аномальному поведению.

Следующим запускается мастер веб-доступа. Выбираем создавать правила.

Давайте оставим по умолчанию.

В следующем окне снимем галочку про архивы.

Параметры проверки HTTPS. Выбираем не проверять. Обратите внимание на желтый треугольник внизу. При включении этой функции, TMG сможет влезать в зашифрованные пакеты SSL, используя MITM. После анализа трафика, пакет подписывается сертификатом TMG и отправляется клиенту. Если у клиента установлен сертификат корневого центра сертификации, то клиент ничего не заметит. Иначе будет выскакивать предупреждение .

Включаем кэш (нужно выставить размер).

На этом базовая настройка завершена.

Установка сертификатов

Для того что бы подписывать сертификаты сервера, нам нужно установить свой центр сертификации. Об этом в статье Установка Certification Authority. Запрос на сертифкат будет выглядеть следующим образом:

Ставим галочки для OWA, ActiveSync и Autodiscover. Если какие то поля пусты, значит не заданы имена в настройках. Руками я вписал внутренний адрес owa -mail.test.ru, и внутренний autodiscover – autodiscover.test.ru.

Проверяем, что все адреса добавлены.

Заполняем информацию, и выбираем путь, куда сохраним запрос. (req файл)

Дальше переходим в веб-интерфейс http://dc1/certsrv

Выбираем Request a certificat.

Submit a certificat request

advanced certificate request

Открывает блокнотом наш файл запроса, копируем все что в нем есть в окно, шаблон сертификата (certificate template) выбираем web server.

Скачиваем сертификат по первой ссылке:

Скармливаем его серверу – complete pending request.

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

Для этого открывает консоль mmc, добавляем оснастку (add snapin):

Выбираем оснастку сертификаты и хранилище компьютер:

И уже в нём добавляем корневой сертификат нашего CA в доверенные, после этого на сертификате появиться галочка, что всё хорошо.

Теперь привязываем сервисы на новый сертификат:

Через export/import растащим сертификат по всем cas серверам.

Настроим правило, которое разрешает DNS серверу разрешать внешние имена.

Создадим правило доступа, которое разрешало бы отправлять запросы от нашего внутреннего DNS к внешнему по 53 порту.

Выбираем пункт “Создать правило доступа”, вписываем его имя, запросы из внутренней сети во внешнюю по протоколу DNS.

И прописываем форвардинг DNS на внешний сервер google в оснастке DNS сервера.

Собственно, сторонний DNS можно и не прописывать, тогда наш DNS будет разрешать имена с помощью корневых серверов. Галочка на картинке “Use root hints” отвечает именно за это. Но работать с корневыми сервера будет медленно.

На внешнем интерфейсе сервера EDGE прописываем наш внутренний DNS сервер, теперь он может разрешать и внутренние и внешние имена.

Теперь прописываем всем серверам и клиентам шлюз 192.168.100.6, то есть внутренний IP адрес EDGE. После этого у нас есть интернет на всех наших внутренних серверах.

Публикуем OWA, activesync, ECP.

Для начала включим outlook anywhere на обоих CAS, в качестве внешнего имени введем то, что мы прописали в DNS.

Нас предупредят, что имя будет активно через 15 минут. Возможно на каждый сервер придется зайти по отдельности.

Теперь пропишем внешнее имя OWA.

В свойствах owa (default web site) включим базовую и интегрированную аутентификацию.

Пропишем внешний адрес также для ActiveSync

Следующим шагом настроим внешний адрес OAB (offline address book), она также лежит в веб директории.

На директорию OAB нужно включить базовую аутентификацию на сервере IIS (по умолчанию выключена)

Зайдём в настройки IIS, выберем директорию OAB и включим basic autentification.

Переходим на TMG, там есть специальный мастер, который поможет нам создать правило.

Публикуем веб клиент.

Публикуем один сайт.

Будем использовать SSL. Для безопасного доступа нужно будет сгенерировать сетификаты.

Вписываем имя сайта так как оно доступно изнутри.

И как будет доступно снаружи.

Далее создадим прослушиватель.

Слушать будем внешний интерфейс.

Выбираем сертификат, который мы импортировали ранее.

Выберем проверку подлинности на основе HTML форм, и проверку учетных данных LDAP (потому что сервер не в домене).

Снимаем галочку.

Выбираем обычную проверку подлинности:

В пользователях создаём новую группу, добавляем туда все участники LDAP.

Вводим данные о домене.

После всех этих манипуляций, по внешнему имени у нас должна открываться обычная страница OWA, с проверкой подлинности Form-based (FBA)

Изнутри же будет работать базовая аутентификация (basic). Также работает интегрированная аутентификация, если заходить изнутри напрямую на CAS сервера – https://cas1/owa.

Публикация Exchange Active Sync аналогична публикации OWA, выбираем тот же мастер, настройки такие же как для OWA, прослушиватель выбираем тот который мы создали.

После установки, у нас должна работать OWA, ECP, Autodiscover и ActiveSync. Для autodiscover нужно прописать внешнее имя сайта и путь.

При настройке Active Sync не забывайте вписывать внутреннее имя домена – в нашем случае это test.ru, тогда всё будет работать.

Проверить работоспособность можно здесь – https://testconnectivity.microsoft.com

Настраиваем коннекторы приёма и отправки

Настроим внешнюю почту пока без edge, напрямую, что бы понять, как это должно работать.

Разрешим домены, с которыми будем работать.

Сервер с ролью hub transport будет принимать и отправлять почту. По умолчанию почта у нас ходит только внутри организации. Настроим коннектор приёма (receive connector)

Коннекторы получения настраиваются отдельно на каждом сервере. Поэтому заходим в область действия server configuration, hub transport.

По умолчанию у нас уже имеются два коннектора – default и client. Если заглянуть в настройки этих соединителей, на вкладку Network (сеть), то мы увидим у коннектора default прописан порт 25, а у коннектора client 587.

Из этого следует, что 25 порт мы будем использовать для приёма почты от серверов из интернета (default), а 587 оставим для клиентов (client).

Порт 587 используется для протоколов pop/imap.

Там же можно указать от каких диапазонов IP мы будем принимать почту. По умолчанию принимаем от всех.

На вкладке authentification нужно установить способы аутентификации.

Для дефолтного коннектора включим TLS. Mutual TLS, или взаимную аутентификацию включать не будем – вряд ли все публичные сервера будут показывать нам SSL сертификат.

Также снимем галочку “offer Basic autentification only after starting TLS”, то есть запрашивать аутентификацию только после старта TLS.

Разрешим проверку подлинности серверам exchange, и интегрированную аутентификацию.

Следующая вкладка Permission group, группы доступа. Здесь нужно указать каким группам можно в принципе подключаться. Укажем, что к 25 порту разрешено подключаться анонимным пользователям, exchange серверам, и legacy exchange серверам. Галку exchange user ставить не будем, пусть клиенты ходят через свой коннектор.

То есть, этот коннектор будет отвечать за приём почты только из интернета.

На клиентском же коннекторе включим запрос TLS до аутентификации, разрешим integrated windows authentification, а в permission group разрешаем только exchange users. В свойствах Каждого коннектора не забудем прописать внешний fqdn.

Этот коннектор будет отвечать за работу с внешними клиентами outlook.

Порты, которые можно открыть на TMG для работы с внешней почтой проиллюстрированы в следующей картинке:

Не забываем открыть 25 порт, который не представлен на картинке. Через него будет приходить почта со сторонних серверов.

Настройка EDGE

Настройка edge сервера особых сложностей не представляет.

Для начала нам нужно оформить подписку Edge subscription. Она нужна для процесса синхронизации EdgeSync. Так как сервер у нас не в домене, то тут как раз пригодится локальная база AD LDS, в которой будут храниться сведения из AD, получаемые по подписке.

Итак, на сервере edge, выполним следующую команду:

New-EdgeSubscription –FileName c:edge.xml

Скармливаем полученный XML файл серверу Hub transport. Автоматически создадутся коннекторы отправки (галочка внизу)

Коннектор отправки который мы создали ранее выключим.

Нас предупреждают, что на edge должен быть открыт порт 50636 для базы AD LDS.

Создадим правило на TMG.

И протестируем соединение.

Test-EdgeSynchronization

Запускаем EAC на нашем tmg/edge, и видим что он успешно синхронизировал наши настройки. Все изменения вносим на hub серверах.

Настроим политику электронной почты. В сервера добавим машины с ролью hub transport.

После этих манипуляций, должна заработать почта через edge сервер, на приём и на отправку изнутри и снаружи.

Управлять всем можно через TMG, на вкладке “устранение неполадок” интеграцию можно отключить, в противном случае TMG будем возвращать настройки на исходные, если поменять их например напрямую в EDGE.

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