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

Продолжаем настраивать 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 с отдельной подсетью. Но так как эта сеть используется только для репликации баз между серверами, роли она не играет.

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

map

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

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. Например запись

spf_lifebay1

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

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

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

cloudflare_dns

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

cloudflare_admin1

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

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

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 (внешний). Этот тип коммутатора способен взаимодействовать с физическим сетевым интерфейсом, то есть выходить в интернет.

external_commutator

external_properties

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

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

new_ethernet_hyperv external_ethernet

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

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

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

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

wan_lan_properties

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

wan_lan

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

edge_dns1

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

ad_lds

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

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

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

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

edge_install

Forefront protection for exchange 2010

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

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

FPE

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

FPE2

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

FPE3

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

FPE4

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

FPE5

TMG

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

tmg_install_feature

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

TMG

 

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

TMG1

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

edge_config

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

edge_config_2


edge_config_3

edge_config_4

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

edge_config_5

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

edge_config_6

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

edge_config_7

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

edge_config_8

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

edge_config_9

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

edge_config_10

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

edge_config_13

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

edge_config_15

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

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

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

cert_ex

cert_ex1

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

cert_ex5

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

cert_ex12

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

new_cert2

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

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

cert_ex7

Submit a certificat request

cert_ex8

advanced certificate request

new_cert3

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

cert_ex9

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

cert_ex10

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

cert_ex11

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

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

new_cert4

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

new_cert5

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

cert_ex13

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

cert_ex14

 

cert_ex16

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

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

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

DNS1

 

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

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

google_dns

 

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

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

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

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

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

anywhere1

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

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

owa_2

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

owa_auth

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

active_sync1

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

oab

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

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

oab_auth

oab_auth1

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

 

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

tmg1

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

tmg2

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

tmg3

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

external_site

 

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

owa_internal1

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

tmg5

tmg6

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

tmg8

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

edge_ssl

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

tmg10

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

tmg11

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

basic

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

all23

all234

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

tmg12

 

tmg13

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

owa_external

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

owa_internal

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

ActiveSync

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

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

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

test

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

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

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

acce

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

receive

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

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

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

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

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

receive4_client receive3_client

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

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

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

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

receive5_client

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

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

receive6_client

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

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

receive8_client receive7_client

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

IC793301

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

Настройка EDGE

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

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

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

New-EdgeSubscription –FileName c:edge.xml

edge_sync

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

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

edge_sync1

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

edge_sync2

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

edge_smtp1

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

Test-EdgeSynchronization

test_edge_sync

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

test_edge_sync1

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

test_edge_sync4

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

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

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

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

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

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

Реклама

Реклама

Tags