У дома › интернет › Справочник за мрежови портове на Exchange. Свързване на имейл клиенти към Microsoft Exchange Server Пътища за данни за сървъри на пощенски кутии

Справочник за мрежови портове на Exchange. Свързване на имейл клиенти към Microsoft Exchange Server Пътища за данни за сървъри на пощенски кутии

[Тази статия е предварителен документ и може да подлежи на промяна в бъдещи издания. Празните секции са включени като контейнери. Ако искате да напишете отзив, ще се радваме да го получим. Изпратете ни го по имейл [имейл защитен].]

Отнася се за: Exchange Server 2016

Научете повече за мрежовите портове, които Exchange 2016 използва за клиентски достъп и пощенски поток.

Тази тема предоставя информация за мрежовите портове, които Microsoft Exchange Server 2016 използва за комуникация с имейл клиенти, онлайн сървъри за електронна поща и други услуги, които се намират извън вашата локална Exchange организация. Преди да започнете, разгледайте следните основни правила.

Ние не поддържаме ограничаване или модифициране на мрежов трафик между вътрешни сървъри на Exchange, между вътрешни сървъри на Exchange и вътрешни сървъри на Lync или Skype за бизнеса, или между вътрешни сървъри на Exchange и вътрешни контролери на домейни на Active Directory във всеки тип топология. Ако използвате защитни стени или мрежови устройства, които могат да ограничават или променят този мрежов трафик, трябва да конфигурирате правила, за да осигурите безплатна и неограничена комуникация между тези сървъри (правила, които позволяват мрежов трафик към и от всеки порт, включително произволни RPC портове и всеки протокол, което не променя нито един бит).

Edge Transport сървърите почти винаги се намират в периметърната мрежа, така че се очаква мрежовият трафик между Edge Transport сървъра и интернет, както и между Edge Transport сървъра и вътрешната организация на Exchange, да бъде ограничен. Тези мрежови портове са описани в този раздел.

От вас се очаква да ограничите мрежовия трафик между външни клиенти и услуги и вътрешната организация на Exchange. Можете също да ограничите трафика между вътрешни клиенти и вътрешни сървъри на Exchange. Тези мрежови портове са описани в този раздел.

Съдържание

Мрежови портове, необходими за клиенти и услуги

Мрежови портове, необходими за потока на пощата (без Edge Transport сървъри)

Мрежови портове, необходими за пощенски поток с Edge Transport сървъри

Мрежови портове, необходими за хибридно внедряване

Мрежови портове, необходими за Unified Messaging

Мрежовите портове, от които имейл клиентите се нуждаят за достъп до пощенски кутии и други услуги в организацията на Exchange, са описани в следващата диаграма и таблица.

Бележки

Дестинацията за тези клиенти и услуги са услугите за клиентски достъп на сървъра на пощенската кутия. В Exchange 2016 услугите за клиентски достъп (преден край) и задните услуги се инсталират заедно на един и същ сървър на пощенска кутия. За повече информация вижте.

Въпреки че диаграмата показва клиенти и услуги от Интернет, концепциите са същите за вътрешни клиенти (например клиенти в гора от акаунти, осъществяващи достъп до сървъри на Exchange в гора от ресурси). По същия начин таблицата няма колона "Източник", тъй като източникът може да бъде всяко местоположение, външно за организацията на Exchange (например интернет или гора от акаунти).

Edge Transport сървърите не участват в мрежов трафиксвързани с тези клиенти и услуги.

Предназначение Портове Бележки

Шифрованите уеб връзки се използват от следните клиенти и услуги. Услуга за автоматично откриване Exchange ActiveSync Уеб услуги на Exchange (EWS) Офлайн разпространение на адресна книга Outlook Mobile (RPC през HTTP) MAPI Outlook през HTTP Outlook в мрежата	443/TCP (HTTPS)	EWS за справка за обмен
Нешифрованите уеб връзки се използват от следните клиенти и услуги. Публикуване на календар онлайн Outlook в мрежата (пренасочване към порт 443/TCP) Автоматично откриване (резервен, когато порт 443/TCP е недостъпен)	80/TCP (HTTP)	Когато е възможно, препоръчваме да използвате криптирани уеб връзки през порт 443/TCP, за да защитите идентификационните данни и други данни. Някои услуги обаче трябва да бъдат конфигурирани да използват некриптирани уеб връзки през порт 80/TCP към услуги за клиентски достъп на сървъри на пощенски кутии. За повече информация относно тези клиенти и услуги вижте следните статии.
IMAP4 клиенти	143/TCP (IMAP), 993/TCP (сигурен IMAP)	По подразбиране IMAP4 е деактивиран. За повече информация вижте. Услугата IMAP4 в услугите за клиентски достъп на сървъра на пощенската кутия прокси връзки към вътрешната услуга IMAP4 на сървъра на пощенската кутия.
POP3 клиенти	110/TCP (POP3), 995/TCP (защитен POP3)	По подразбиране POP3 е деактивиран. За повече информация вижте. POP3 услугата в услугите за клиентски достъп на сървъра на пощенската кутия прокси връзки към вътрешната POP3 услуга на сървъра на пощенската кутия.
SMTP клиенти (удостоверени)	587/TCP (SMTP с удостоверяване)	Конекторът за получаване по подразбиране е „Клиентски фронтенд“ " в услугата за външен транспорт слуша за съобщения от удостоверени SMTP клиенти на порт 587. Забележка. Ако имате имейл клиенти, които могат да изпращат само SMTP удостоверени съобщения на порт 25, тогава можете да промените стойността на обвързване на този конектор за получаване, така че той също да проследява SMTP удостоверени съобщения, изпратени на порт 25.

Към началото

Мрежови портове, необходими за потока на пощата

Изходяща поща

25/TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

По подразбиране Exchange не създава конектори за изпращане, които ви позволяват да изпращате поща до интернет. Трябва да създадете ръчно конектори за изпращане. За повече информация вижте.

Изходяща поща (ако е изпратена чрез външна транспортна услуга)

25/TCP (SMTP)

Сървър на пощенска кутия

Интернет (всички)

Изходящата поща се насочва през външната транспортна услуга само ако конекторът за изпращане е активиран с опцията Client Access Server Proxy в EAC или опцията -FrontEndProxyEnabled $true в Exchange Management Shell.

В този случай конекторът за получаване по подразбиране е „Изходящ прокси интерфейс " във външната транспортна услуга слуша за изходяща поща от транспортната услуга на сървъра на пощенската кутия. За повече информация вижте.

DNS сървър за разрешаване на имена на следващ хоп за поща (не е показано на снимката)

53/UDP, 53/TCP (DNS)

Сървър на пощенска кутия

DNS сървър

Към началото

Абониран Edge Transport сървър, инсталиран в периметърна мрежа, влияе върху потока на пощата по следните начини:

Изходящата поща от организацията на Exchange никога не преминава през външната транспортна услуга на сървърите на пощенските кутии. Той винаги се пренасочва от транспортната услуга на сървъра на пощенската кутия на абонирания сайт на Active Directory към сървъра Edge Transport (независимо от версията на Exchange на сървъра Edge Transport).

Входящата поща се пренасочва от сървъра Edge Transport към сървъра на пощенската кутия на абонирания сайт на Active Directory. Това означава следното:

Пощата от Exchange 2016 или Exchange 2013 Edge Transport сървър първо пристига в услугата за транспорт от предния край и след това се препраща към услугата за транспорт на сървъра за пощенска кутия на Exchange 2016.
Пощата от сървър на Exchange 2010 Edge Transport винаги отива директно към транспортната услуга на сървър на пощенска кутия на Exchange 2016.

Мрежовите портове, необходими за потока на пощата в организации на Exchange с Edge Transport сървъри, са описани в следващата диаграма и таблица.

Дестинация Портове Източник Дестинация Бележки

Входяща поща - от интернет към сървъра Edge Transport	25/TCP (SMTP)	Интернет (всички)		Конектор за получаване по подразбиране, наречен „Вътрешен конектор за получаване по подразбиране“ " на сървъра Edge Transport слуша за анонимна SMTP поща на порт 25.
Входяща поща - от сървъра Edge Transport до вътрешната организация на Exchange	25/TCP (SMTP)	Граничен транспортен сървър		Конекторът за изпращане по подразбиране се нарича „EdgeSync – Входящ към "препредава входяща поща на порт 25 към всеки сървър на пощенска кутия в абониран сайт на Active Directory. За повече информация вижте . Конектор за получаване по подразбиране „По подразбиране Frontend“ " във външната транспортна услуга на сървъра на пощенската кутия слуша цялата входяща поща (включително поща от Exchange 2016 и Exchange 2013 Edge Transport сървъри) на порт 25.
Изходяща поща - от вътрешната организация на Exchange към сървъра Edge Transport	25/TCP (SMTP)	Сървъри на пощенски кутии в абониран сайт на Active Directory		Изходящата поща винаги заобикаля външната транспортна услуга на сървърите на пощенските кутии. Пощата се препредава от транспортната услуга на всеки сървър на пощенска кутия в абониран сайт на Active Directory към сървъра Edge Transport с помощта на скрит и невидим конектор за изпращане в рамките на организацията, който автоматично препраща пощата между сървърите на Exchange в същата организация. Вътрешен конектор за получаване по подразбиране " на сървъра Edge Transport слуша за SMTP поща на порт 25 от транспортната услуга на всеки сървър на пощенска кутия в абониран сайт на Active Directory.
Изходяща поща - от сървъра Edge Transport към Интернет	25/TCP (SMTP)	Граничен транспортен сървър	Интернет (всички)	Конекторът за изпращане по подразбиране се нарича „EdgeSync – с към Интернет" препредава изходяща поща на порт 25 от сървъра Edge Transport към Интернет.
EdgeSync синхронизация	50636/TCP (LDAP защитен)	Сървъри на пощенски кутии в абониран сайт на Active Directory, които участват в синхронизирането на EdgeSync	Гранични транспортни сървъри	Ако сървърът Edge Transport е абониран за сайт на Active Directory, всички сървъри на пощенски кутии, които в момента съществуват в сайта, участват в синхронизирането на EdgeSync. Но ако добавите други сървъри на пощенска кутия по-късно, те няма да участват автоматично в синхронизирането на EdgeSync.
DNS сървър за разрешаване на името на следващия хоп (не е показано на снимката)	53/UDP, 53/TCP (DNS)	Граничен транспортен сървър	DNS сървър	Вижте Разрешаване на имена.
Откриване на отворен прокси в репутацията на изпращача (не е показано на фигурата)	Вижте бележките	Граничен транспортен сървър	интернет	По подразбиране агентът за анализ на протоколи използва откриване на отворен прокси като едно от условията за изчисляване на нивото на репутация на първоначалния сървър за съобщения. За повече информация вижте статията. Следните TCP портове се използват за проверка на изходните сървъри за съобщения за отворен прокси: Освен това, ако вашата организация използва прокси сървър за контрол на изходящия интернет трафик, трябва да определите името, типа и TCP порта на прокси сървъра, необходими за достъп до интернет и откриване на отворен прокси сървър. Можете също да деактивирате откриването на отворен прокси. За повече информация вижте.

Към началото

Резолюция на имената

Разрешаването на поща след следващ DNS е основна част от пощенския поток във всяка организация на Exchange. Exchange сървърите, отговорни за получаване на входяща поща или доставка на изходяща поща, трябва да могат да разрешават вътрешни и външни имена на хостове, за да маршрутизират правилно пощата. Всички вътрешни сървъри на Exchange трябва да могат да разрешават вътрешни имена на хостове за правилно маршрутизиране на пощата. Има много различни начини за проектиране на DNS инфраструктура, но важният резултат е да се осигури правилна резолюция на имена на следващ хоп във всички Exchange сървъри.

Какви TCP и UDP портове използва моят Exchange 2000/2003 сървър?

За целите на конфигуриране на защитни стени или за отстраняване на комуникационни проблеми може да е полезно да знаете какви TCP/UDP портове използват Exchange 2000 Server и Exchange 2000 Conferencing Server. Тази статия е вярна и за инсталации на Exchange Server 2003.

Протокол: LDAP

Порт (TCP/UDP): 389 (TCP)
Описание: Lightweight Directory Access Protocol (LDAP), използван от Active Directory, Active Directory Connector и директорията на Microsoft Exchange Server 5.5.

Протокол: LDAP/SSL

Порт (TCP/UDP): 636 (TCP)
Описание: LDAP през Secure Sockets Layer (SSL). Когато SSL е активиран, LDAP данните, които се предават и получават, са криптирани.
За да активирате SSL, трябва да инсталирате компютърен сертификат на домейн контролера или компютъра с Exchange Server 5.5.

Протокол: LDAP

Порт (TCP/UDP): 379 (TCP)
Описание: Услугата за репликация на сайт (SRS) използва TCP порт 379.

Протокол: LDAP

Порт (TCP/UDP): 390 (TCP)
Описание: Въпреки че не е стандартен LDAP порт, TCP порт 390 е препоръчителният алтернативен порт за конфигуриране на LDAP протокола на Exchange Server 5.5, когато Exchange Server 5.5 работи на Microsoft Windows 2000 Active Directory домейн контролер.

Протокол: LDAP

Порт (TCP/UDP): 3268 (TCP)
Описание: Глобален каталог. Глобалният каталог на Windows 2000 Active Directory (което всъщност е „роля“ на домейн контролер) слуша TCP порт 3268. Когато отстранявате проблеми, които може да са свързани с глобален каталог, свържете се към порт 3268 в LDP.

Протокол: LDAP/SSL

Порт (TCP/UDP): 3269 (TCP)
Описание: Глобален каталог през SSL. Приложенията, които се свързват към TCP порт 3269 на сървър за глобален каталог, могат да предават и получават SSL криптирани данни. За да конфигурирате глобален каталог да поддържа SSL, трябва да инсталирате компютърен сертификат в глобалния каталог.

Протокол: IMAP4

Порт (TCP/UDP): 143 (TCP)
Описание: Internet Message Access Protocol версия 4 може да се използва от „базирани на стандарти“ клиенти като Microsoft Outlook Express или Netscape Communicator за достъп до сървъра за електронна поща. IMAP4 работи върху Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe) и позволява достъп на клиента до хранилището на информация на Exchange 2000.

Протокол: IMAP4/SSL

Порт (TCP/UDP): 993 (TCP)
Описание: IMAP4 през SSL използва TCP порт 993. Преди сървър на Exchange 2000 да поддържа IMAP4 (или който и да е друг протокол) през SSL, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: POP3

Порт (TCP/UDP): 110 (TCP)
Описание: Post Office Protocol версия 3, позволява на „базирани на стандарти“ клиенти като Outlook Express или Netscape Communicator за достъп до сървъра за електронна поща. Както при IMAP4, POP3 работи върху услугата за администриране на IIS и позволява достъп на клиента до хранилището на информация на Exchange 2000.

Протокол: POP3/SSL

Порт (TCP/UDP): 995 (TCP)
Описание: POP3 през SSL. За да разрешите POP3 през SSL, трябва да инсталирате компютърен сертификат на сървъра Exchange 2000.

Протокол: NNTP

Порт (TCP/UDP): 119 (TCP)
Описание: Протоколът за мрежов транспорт на новини, понякога наричан протокол Usenet, позволява „базиран на стандарти“ клиентски достъп до публични папки в хранилището за информация. Както при IMAP4 и POP3, NNTP зависи от IIS Admin Service.

Протокол: NNTP/SSL

Порт (TCP/UDP): 563 (TCP)

Описание: NNTP през SSL. За да активирате NNTP през SSL, трябва да инсталирате компютърен сертификат на Exchange 2000 Server.

Протокол: HTTP

Порт (TCP/UDP): 80 (TCP)
Описание: Hyper-Text Transfer Protocol е протоколът, използван предимно от Microsoft Outlook Web Access (OWA), но също така позволява някои административни действия в Exchange System Manager. HTTP се внедрява чрез World Wide Web Publishing Service (W3Svc) и работи върху IIS Admin Service.

Протокол: HTTP/SSL

Порт (TCP/UDP): 443 (TCP)
Описание: HTTP през SSL. За да разрешите HTTP през SSL, трябва да инсталирате компютърен сертификат на сървъра Exchange 2000.

Протокол: SMTP

Порт (TCP/UDP): 25 (TCP)
Описание: Simple Mail Transfer Protocol е основата за целия транспорт на електронна поща в Exchange 2000. SMTP услугата (SMTPSvc) работи върху IIS Admin Service. За разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 неизползва отделен порт за защитена комуникация (SSL), а по-скоро използва „вътрешна подсистема за сигурност“, наречена Сигурност на транспортния слой (TLS).

Протокол: SMTP/SSL

Порт (TCP/UDP): 465 (TCP)
Описание: SMTP през SSL. TCP порт 465 е запазен от обичайната индустриална практика за защитена SMTP комуникация, използваща SSL протокола. Въпреки това, за разлика от IMAP4, POP3, NNTP и HTTP, SMTP в Exchange 2000 не използва отделен порт за защитена комуникация (SSL), а по-скоро използва „вътрешна подсистема за сигурност“, наречена Защита на транспортния слой (TLS). . За да разрешите TLS да работи на Exchange 2000, трябва да инсталирате компютърен сертификат на сървъра на Exchange 2000.

Протокол: SMTP/LSA

Порт (TCP/UDP): 691 (TCP)
Описание: Механизмът за маршрутизиране на Microsoft Exchange (известен също като RESvc) слуша информация за състоянието на връзката за маршрутизиране на TCP порт 691. Exchange 2000 използва информация за състоянието на връзката за маршрутизиране, за да маршрутизира съобщенията и таблицата за маршрутизиране се актуализира постоянно. Алгоритъмът за състояние на връзката (LSA) разпространява информация за състоянието на изход между сървърите на Exchange 2000. Този алгоритъм се основава на протокола Open Shortest Path First (OSPF) от мрежовата технология и прехвърля информация за състоянието на връзката между групите за маршрутизиране чрез използване на командния глагол X-LSA-2 през SMTP и чрез използване на връзка с протокол за контрол на предаването (TCP) към порт 691 в група за маршрутизиране.

Протокол: RVP

Порт (TCP/UDP): 80 (TCP)
Описание: RVP е основата за незабавни съобщения в Exchange 2000. Докато RVP комуникацията започва с TCP порт 80, сървърът бързо настройва нова връзка към клиента на ефимерен TCP порт над 1024. Тъй като този порт не е известен предварително, възникват проблеми, когато активирате незабавни съобщения през защитна стена.

Протокол: IRC/IRCX

Порт (TCP/UDP): 6667 (TCP)
Описание: Internet Relay Chat (IRC) е протоколът за чат. IRCX е разширената версия, предлагана от Microsoft. Докато TCP порт 6667 е най-често срещаният порт за IRC, TCP порт 7000 също се използва много често.

Протокол: IRC/SSL

Порт (TCP/UDP): 994 (TCP)
Описание: IRC (или чат) през SSL. IRC или IRCX през SSL не се поддържат в Exchange 2000.

Протокол: X.400

Порт (TCP/UDP): 102 (TCP)
Описание: Препоръката на ITU-T X.400 всъщност е поредица от препоръки за това как трябва да изглежда една система за обработка на електронни съобщения (MHS). TCP порт 102 е дефиниран в IETF RFC-1006, който описва OSI комуникации през TCP/IP мрежа. Накратко, TCP порт 102 е портът, който агентът за прехвърляне на съобщения на Exchange (MTA) използва, за да комуникира с други поддържащи X.400 MTA.

Протокол: MS-RPC

Порт (TCP/UDP): 135 (TCP)
Описание: Microsoft Remote Procedure Call е реализация на Microsoft за извиквания на отдалечени процедури (RPC). TCP порт 135 всъщност е само RPC Locator Service, който е като регистратор за всички RPC-активирани услуги, които се изпълняват на определен сървър. В Exchange 2000 съединителят на групата за маршрутизиране използва RPC вместо SMTP, когато целевият предмостов сървър работи с Exchange 5.5. Освен това някои административни операции изискват RPC. За да конфигурирате защитна стена да активира RPC трафик, трябва да бъдат активирани много повече портове от само 135.

За допълнителна информация щракнете върху номерата на статиите по-долу, за да видите статиите в базата знания на Microsoft:

XADM: Задаване на номера на TCP/IP портове за интернет защитни стени

XCON: Конфигуриране на MTA TCP/IP порт # за X.400 и RPC слушания

Протокол: T.120

Порт (TCP/UDP): 1503 (TCP)
Описание: ITU-T Препоръка T.120 е поредица от препоръки, които дефинират конферентната връзка с данни. Конферентната връзка с данни се изпълнява от страната на сървъра като доставчик на конферентна технология (CTP) в многоточковия контролен блок (MCU), който е един от компонентите на услугите за конферентна връзка на обмена (ECS). Конферентната връзка с данни се изпълнява от страна на клиента като чат, споделяне на приложения, бяла дъска и прехвърляне на файлове в Microsoft NetMeeting.

Протокол: ULS

Порт (TCP/UDP): 522 (TCP)
Описание: Услугата за локализиране на потребители е вид интернет директория за клиенти за конференции, като NetMeeting. Exchange 2000 Server и Exchange 2000 Conferencing Server не прилагат ULS, а по-скоро се възползват от Active Directory за справочни услуги (чрез TCP порт 389).

Протокол: H.323 (видео)

Порт (TCP/UDP): 1720 (TCP)
Описание: ITU-T Препоръка H.323 дефинира мултимедийни конференции. TCP порт 1720 е портът за настройка на H.323 (видео) повикване. След като клиент се свърже, H.323 сървърът договаря нов, динамичен UDP порт, който да се използва за поточно предаване на данни.

Протокол: Аудио

Порт (TCP/UDP): 1731 (TCP)
Описание: Аудиоконференциите са активирани по почти същия начин, както H.323 видеоконференциите са активирани в Exchange 2000 Server. След като клиентите се свържат към TCP порт 1731, се договаря нов динамичен порт за по-нататъшно поточно предаване на данни.

Exchange сървър и защитни стени

Защитни стени за пощенски сървъри (Exchange Server), портове на пощенски сървъри, предни и бек-енд пощенски сървъри, виртуални сървъри SMTP, POP3, IMAP4

Както всеки компютър, свързан към интернет, компютърът, на който работи пощенският сървър, трябва да бъде защитен със защитна стена. Опциите за инсталиране на пощенски сървър по отношение на мрежовата конфигурация обаче могат да бъдат много различни:

· най-простият вариант е да инсталирате пощенски сървър на компютър, който е и прокси сървър/защитна стена, и след това да отворите необходимите портове на интерфейса, който гледа към Интернет. Обикновено тази схема се използва в малки организации;

Друг вариант е да инсталирате пощенски сървър локална мрежаи го конфигурирайте да работи през прокси сървър. За да направите това, можете да свържете публичен ip към пощенския сървър и да го прехвърлите през прокси или да използвате инструменти като картографиране на портове на прокси сървър. Много прокси сървъри имат специални съветници или предварително подготвени правила за организиране на такова решение (например ISA Server). Тази опция се използва в повечето организации.

· друга фундаментална възможност е да създадете DMZ и да поставите преден Exchange Server в него (тази опция се появи от версия 2000) или SMTP Relay на базата на друг Exchange Server или, например, sendmail на *nix. Обикновено се използва в мрежи от големи организации.

Във всеки случай пощенският сървър трябва да комуникира поне на порт TCP 25 (SMTP) и UDP 53 (DNS). Други портове, които Exchange Server може да изисква в зависимост от вашата мрежова конфигурация (всички TCP):

· 80 HTTP - за достъп до уеб интерфейс (OWA)

· 88 Kerberos authentication protocol – ако се използва Kerberos автентификация (рядко);

· 102 MTA .X .400 конектор през TCP /IP (ако X .400 конекторът се използва за комуникация между групите за маршрутизиране);

· 110 Post Office Protocol 3 (POP 3) – за клиентски достъп;

· 119 Network News Transfer Protocol (NNTP) – ако се използват дискусионни групи;

· 135 Комуникация клиент/сървър RPC Exchange администриране - стандартен RPC порт за отдалечено Exchange администриране стандартни средстваСистемен мениджър;

· 143 Internet Message Access Protocol (IMAP) – за клиентски достъп;

· 389 LDAP - за достъп до справочната услуга;

· 443 HTTP (Secure Sockets Layer (SSL)) (и по-долу) – същите протоколи, защитени от SSL.

· 563 NNTP (SSL)

636 LDAP (SSL)

· 993 IMAP4 (SSL)

· 995 POP3 (SSL)

· 3268 и 3269 - заявки към сървъра на глобалния каталог (търсене в Active Directory и проверка на членство в универсални групи).

Няма смисъл да покривате интерфейса на Exchange Server, обърнат към вътрешността на организацията, със защитна стена - той ще се използва за взаимодействие с домейн контролери, помощни програми за администриране, системи за архивиране и т.н. За интерфейс, отворен към Интернет, се препоръчва да оставите портове 53 (ако Exchange сам разрешава имена на хостове и не пренасочва заявки към локалния DNS сървър) и 25. Много често клиентите имат нужда от достъп до своите пощенски кутии отвън (от вкъщи, по време на командировка и др.). Най-доброто решение в тази ситуация е да конфигурирате OWA (уеб интерфейс за достъп до Exchange Server, който е инсталиран по подразбиране, достъпен на http://server_name/exchange) да работи през SSL и да отваря достъп само на порт 443. В допълнение към разрешаването на проблеми със сигурно удостоверяване и криптиране на съобщения автоматично разрешава проблема със SMTP Relay (повече за това по-късно) и ситуацията, когато потребител случайно изтегли служебен имейл в папки на пощенски клиент на домашен компютър, а след това на работа той не може да намери тези съобщения (да не говорим за факта, че съхраняването на служебен имейл у дома е нарушение на сигурността).

Нова функция, която се появи в Exchange Server. започвайки от версия 2000, възможност за използване на няколко виртуални SMTP и POP3 сървъра с различни настройки за сигурност. Например SMTP сървърът, който взаимодейства с интернет, може да бъде конфигуриран с повишен режим на защита и строги ограничения за доставка, а SMTP сървърът, който потребителите в рамките на организацията използват, може да бъде конфигуриран с най-мощните и удобни за потребителя настройки.

Трябва да се спомене и известно объркване в терминологията - много често защитните стени за Exchange се наричат системи за филтриране на съобщения, които ще бъдат разгледани по-долу.

Материал от Rosalab Wiki

Предназначение

Това ръководство описва как да свържете различни пощенски клиентикъм сървъра на Microsoft Exchange. Целта е да се получи система, която съответства на функционалността на Microsoft Outlook.

Входни данни

Примерите използват Microsoft Exchange 2010 сървър (v14.03.0361.001) Service Pack 3 Update RollUp 18. Тестването се извършва в рамките на корпоративната мрежа. DNS сървърите съдържат външни пощенски адреси за пощенския сървър. Следното трябва да работи на Exchange сървъра:

OWA (Outlook Web Access) - уеб клиент за достъп до сървър за сътрудничество Работа на MicrosoftРазмяна

OAB (Offline Address Book) - офлайн адресна книга

EWS (Exchange Web Services) е услуга, която предоставя достъп до данните на пощенската кутия, съхранявани в Exchange Online (като част от Office 365) и в локалната версия на Exchange (започвайки с Exchange Server 2007)

Настройки на сървъра на Exchange

Важен проблем за клиентите, които не са от Microsoft, за да работят успешно на Exchange 2010, е удостоверяването. Можете да видите неговите параметри на Exchange сървър с роля CAS (клиентски достъп сървър). Стартирайте конзолната добавка на IIS Manager и отворете раздела Сайтове/Уеб сайт по подразбиране. Имайте предвид, че удостоверяването има три компонента:

OWA - Активиран статус за основно удостоверяване и проверка Автентичност на Windows »:

OAB - Активиран статус за основно удостоверяване и Windows удостоверяване:

EWS - Активирано състояние за анонимно удостоверяване, основно удостоверяване и Windows удостоверяване:

Слоеве (посредници) и спомагателни помощни програми DavMail

Някои имейл клиенти не могат да се свържат директно с Microsoft Exchange и изискват използването на посредник. В този пример прокси сървърът се използва като посредник DavMail.

Инсталирай DavMail, като сте получили администраторски права с помощта на su или sudo:

sudo urpmi davmail

Бягай DavMail:

В раздела „Основни“, в полето „OWA (Exchange) URL“, въведете адреса на вашия сървър във формат „https:///EWS/Exchange.asmx“ или връзка към OWA

във формат "https:///owa".

Запомнете номерата на портовете „Локален IMAP порт“ и „Локален SMTP порт“. В този пример това са съответно 1143 и 1025.

За да не стартирате ръчно сървъра всеки път DavMail, трябва да добавите извикването му към стартиране.

Отидете в менюто „Системни настройки → Стартиране и изключване → Автоматично стартиране“, щракнете върху бутона [Добавяне на приложение] и въведете „davmail“ в лентата за търсене, след което щракнете върху [OK]:

Сега локален прокси сървър DavMailще стартира автоматично при стартиране на системата. Ако иконата му в лентата на задачите ви притеснява, има опция да го скриете. За да направите това, във файла .davmail.properties редактирайте реда davmail.server=false, като промените false на true:

Sudo mcedit /home//.davmail.properties

Пощенски клиенти за свързване към Exchange

Сега можете да започнете да настройвате имейл клиенти.

Thunderbird

Mozilla Thunderbirdе основният имейл клиент за ROSA Linux дистрибуции и най-вероятно вече е инсталиран на вашата система и е готов за използване. Ако не, можете да го инсталирате от хранилищата на ROSA. Този пример използва версия 52.2.1.

Инсталирай Thunderbird:

sudo urpmi mozilla-thunderbird

Добавете интерфейс на руски език:

sudo urpmi mozilla-thunderbird-en

Инсталирайте добавката за мълния, която ви позволява да използвате календари:

sudo urpmi mozilla-thunderbird-lightning

Бягай Thunderbird.

В секцията „Акаунти“, в секцията „Създаване на акаунт“, изберете „ електронна поща" Ще се появи прозорец за добре дошли.

В прозореца, който се отваря, щракнете върху бутона [Пропускане на това и използване на съществуващия ми имейл].

В прозореца „Настройка на пощенски акаунт“ въведете „Вашето име“, „Имейл адрес“ в полетата. поща" и "Парола" вашите идентификационни данни.

Щракнете върху [Продължи]. Програмата ще се опита да намери връзки (неуспешно) и ще се появи съобщение за грешка:

Тук ще ви трябват номерата на портовете, които сте запомнили по време на настройката DavMail.

За категориите „Входящи“ и „Изходящи“ променете името на сървъра на „localhost“.
Посочете порт 1143 за „IMAP“ и порт 1025 за „SMTP“.
В полето „Потребителско име“ въведете UPN (User Principal Name) - името на домейна на потребителя във формат „[email protected]“.
Щракнете върху бутона [Retest].

Ако въведете вашите идентификационни данни правилно, няма да има грешки. Системата може да ви подкани да приемете сертификата на сървъра на Exchange. Ако това не се случи, може да сте изключили интерфейса твърде рано DavMail.

Създайте потребителски календар

В категорията „Акаунти“ изберете „Създаване на нов календар“.
В прозореца, който се показва, изберете „Онлайн“ и щракнете върху [Напред].
Изберете формата „CalDAV“ и в полето „Адрес“ въведете „http://localhost:1080/users/ /calendar“:

Създаване на адресна книга

Адресната книга Thunderbirdне поддържа протокола CardDAV и може да бъде свързан само към LDAP директорията на Exchange сървъра.

Отворете съществуващи адресни книги, като щракнете върху бутона [Адресна книга] и изберете „Файл → Нов → LDAP директория“.

В прозореца на съветника задайте следните параметри:
- Име - всяко подходящо име
- Име на сървъра - localhost
- Коренен елемент (Base DN) - ou=хора
- Пристанище - 1389 (от Davmail)
- Потребителско име (Bind DN) - UPN потребителско име

Щракнете върху [OK]. Програмата ще ви помоли да въведете парола.

Отидете в менюто с опции Thunderbird. В категорията „Съставяне“ изберете раздела „Адресиране“ и под текста „При въвеждане на адрес търсете подходящи адреси за кореспонденция в“ отметнете опцията „Сървър на директория“, като изберете името на вашата адресна книга.

Еволюция

В хранилищата на ROSA е наличен и имейл клиент Еволюция(в този пример се използва версия 3.16.4).

Инсталирай Еволюция:

sudo urpmi еволюция

Инсталирайте съединителя Размянасъвместим с версия 2007 и по-нова:

sudo urpmi evolution-ews

Бягай Еволюция.

В прозореца на съветника щракнете върху бутона [Напред], докато отидете в раздела „Акаунт“.
Попълнете полетата "Пълно име" и "Имейл".
В раздела „Получаване на поща“ в списъка „Тип сървър“ изберете „Уеб услуги на Exchange“.
За името въведете UPN името на потребителя във формат „[email protected]“.
В полето „URL адрес на хост“ въведете „https://MailServerNameExchange/EWS/Exchange.asmx.
В полето URL адрес на OAB въведете URL адреса на OAB.
Изберете „Основно“ като тип удостоверяване.

При успешна настройка програмата ще поиска парола:

След като въведете паролата Еволюцияще има достъп до вашата пощенска кутия, адресна книга и календари.

За всякакви въпроси, свързани с тази статия, моля, свържете се с [имейл защитен].

Отнася се за: Exchange Server 2010 SP1

Този раздел беше последно променен: 2011-04-22

Този раздел предоставя информация за портове, удостоверяване и криптиране за всички пътища на данни, използвани в Microsoft Exchange Server 2010. Разделът „Забележки“ след всяка таблица изяснява или дефинира нестандартни методи за удостоверяване или криптиране.

Транспортни сървъри

В Exchange 2010 има две сървърни роли, които изпълняват функции за транспортиране на съобщения: Hub Transport server и Edge Transport server.

Следващата таблица предоставя информация за портове, удостоверяване и криптиране на пътища за данни между тези транспортни сървъри и други сървъри и услуги на Exchange 2010.

Пътища за данни за транспортни сървъри Път за данни Необходими портове Поддръжка на криптиране

Между два Hub Transport сървъра			Да, използвайки TLS (сигурност на транспортния слой)
От Hub Transport сървър към Edge Transport сървър	Директно доверие	Директно доверие	Да, с помощта на TLS
От Edge Transport сървър към Hub Transport сървър	Директно доверие	Директно доверие	Да, с помощта на TLS
Между два Edge Transport сървъра	Анонимен, удостоверяване на сертификат	Анонимно, с помощта на сертификат	Да, с помощта на TLS
От сървър на пощенска кутия до чрез услугата за изпращане на поща на Microsoft Exchange	NTLM. Когато ролята на сървъра Hub Transport и ролята на сървъра на пощенската кутия се изпълняват на един и същи сървър, се използва протоколът Kerberos.		Да, използвайки RPC криптиране
От Hub Transport сървър към сървър на пощенска кутия чрез MAPI	NTLM. Когато ролята на сървъра Hub Transport и ролята на сървъра на пощенската кутия са инсталирани на един и същи сървър, се използва протоколът Kerberos.		Да, използвайки RPC криптиране
			Да, с помощта на TLS
Услуга Microsoft Exchange EdgeSync от Hub Transport сървър към Edge Transport сървър			Да, използвайки LDAP през SSL (LDAPS)
Достъп до Active Directory от Hub Transport сървър
Достъп до услугите за управление на права на Active Directory (AD RMS) от Hub Transport сървър			Да, използвайки SSL
SMTP клиенти към Hub Transport сървър (например крайни потребители, използващи Windows Live Mail)			Да, с помощта на TLS

Бележки за транспортни сървъри

Целият трафик между сървърите Hub Transport е шифрован с помощта на TLS и самоподписани сертификати, инсталирани от настройката на Exchange 2010.
Целият трафик между Edge Transport сървъри и Hub Transport сървъри е удостоверен и криптиран. Взаимният TLS се използва като механизъм за удостоверяване и криптиране. Вместо X.509 удостоверяване, Exchange 2010 използва пряко доверие. Директно доверие означава, че наличието на сертификат в Active Directory или Active Directory Lightweight Directory Services (AD LDS) проверява автентичността на сертификата. Active Directory се счита за доверен механизъм за съхранение. Когато се използва директно доверие, няма значение дали се използва самоподписан сертификат или сертификат, подписан от сертифициращ орган. Когато Edge Transport сървър се абонира за организация на Exchange, Edge Subscription публикува сертификата на Edge Transport сървъра в Active Directory, така че Hub Transport сървърите да могат да го валидират. Услугата Microsoft Exchange EdgeSync добавя набор от сертификати на Hub Transport сървър към Active Directory Lightweight Directory Services (AD LDS) за проверка на Edge Transport сървъра.
EdgeSync използва защитена LDAP връзка от сървъра Hub Transport към абонирани сървъри Edge Transport на TCP порт 50636. Active Directory Lightweight Directory Services също слуша на TCP порт 50389. Връзките на този порт не използват SSL протокол. Можете да използвате LDAP помощни програми, за да се свържете с този порт и да проверите данните на Active Directory Lightweight Directory Services.
По подразбиране трафикът между Edge Transport сървъри, разположени в две различни организации, е шифрован. Настройката на Exchange 2010 създава самоподписан сертификат и активира TLS по подразбиране. Това позволява на всяка изпращаща система да шифрова SMTP сесията, влизаща в Exchange. По подразбиране Exchange 2010 също се опитва да използва TLS за всички отдалечени връзки.
Методите за удостоверяване на трафика между Hub Transport сървъри и сървъри на пощенска кутия са различни, когато ролите на Hub Transport и сървъра на пощенска кутия са инсталирани на един и същи компютър. Локалният пренос на поща използва Kerberos удостоверяване. Отдалеченото прехвърляне на поща използва NTLM удостоверяване.
Exchange 2010 също поддържа сигурност на домейна. Защитата на домейна е набор от функции в Exchange 2010 и Microsoft Outlook 2010, които предоставят евтина алтернатива на S/MIME и други решения за защита на интернет съобщения. Защитата на домейна предоставя начин за управление на защитени пътища за съобщения между домейни в Интернет. След като тези защитени пътеки са конфигурирани, успешно предадените съобщения от удостоверен подател се показват като „защитени от домейн“ съобщения за потребителите на Outlook и Outlook Web Access. За повече информация вижте Преглед на сигурността на домейна.
Много агенти могат да работят както на Hub Transport сървъри, така и на Edge Transport сървъри. Обикновено анти-спам агентите използват информация от локалния компютър, на който работят. По този начин практически не се изисква взаимодействие отдалечени компютри. Изключение е филтрирането на получатели. Филтрирането на получатели изисква извикване на AD LDS или Active Directory. Препоръчваме ви да извършите филтриране на получатели на сървъра Edge Transport. В този случай директорията AD LDS е на същия компютър, на който е инсталирана ролята на Edge Transport server, така че не е необходима отдалечена връзка. Ако филтрирането на получатели е инсталирано и конфигурирано на Hub Transport сървър, трябва да имате достъп до директорийната услуга на Active Directory.
Агентът за анализ на протоколи се използва от функцията за репутация на изпращача в Exchange 2010. Този агент също се свързва с различни външни прокси сървъри, за да определи пътищата на входящите съобщения за подозрителни връзки.
Всички други анти-спам функции използват данни, които се събират, съхраняват и са достъпни само на локалния компютър. Обикновено данни като консолидиран списък с безопасни податели или данни за получатели за филтриране на получатели се изпращат към локалната AD LDS директория с помощта на услугата Microsoft Exchange EdgeSync.
Агентите за управление на правата за информация (IRM) на Hub Transport сървъри се свързват към сървърите на услугите за управление на правата на Active Directory (AD RMS) във вашата организация. Услугата за управление на правата на Active Directory (AD RMS) е уеб услуга, която се препоръчва да бъде защитена чрез SSL. Връзките към сървърите на услугите за управление на права на Active Directory се осъществяват чрез HTTPS, а удостоверяването използва Kerberos или NTLM, в зависимост от конфигурацията на сървъра на услугите за управление на права на Active Directory.

Правилата за регистрационни файлове, транспортните правила и правилата за класифициране на съобщенията се съхраняват в услугите на Active Directory и достъпни от агента за журналиране и агента за транспортни правила на Hub Transport сървъри. Сървъри за пощенски кутии

На сървърите на пощенски кутии дали се използва NTLM или Kerberos удостоверяване зависи от потребителския контекст или процеса, в който се изпълнява потребителят на слоя на бизнес логиката на Exchange. В този контекст потребители са всички приложения или процеси, които използват слоя бизнес логика на Exchange. В резултат на това колоната Удостоверяване по подразбиране в таблицата Пътища към данни за сървъри на пощенски кутии има много редове, зададени на NTLM/Kerberos.

Слоят на бизнес логиката на Exchange се използва за достъп и взаимодействие с магазина на Exchange. Слоят на бизнес логиката на Exchange също се извиква от магазина на Exchange, за да взаимодейства с външни приложения и процеси.

Ако потребителят на слоя бизнес логика на Exchange работи в контекста на локалната система, методът за удостоверяване, използван, когато потребителят има достъп до хранилището на Exchange, винаги е Kerberos. Използва се методът за удостоверяване Kerberos, тъй като самоличността на получателя трябва да бъде потвърдена чрез сметкакомпютър "Локална система" и също така изисква двупосочно удостоверено доверие.

Ако получателят на слоя бизнес логика на Exchange не работи в контекста на локалната система, методът за удостоверяване е NTLM. Например, когато администратор изпълнява cmdlet на Exchange Management Shell, който използва слоя бизнес логика на Exchange, се прилага NTLM удостоверяване.

RPC трафикът винаги е криптиран.

Следващата таблица предоставя информация за портове, удостоверяване и шифроване на пътя на данните за сървъри на пощенски кутии.

Пътища за данни за сървъри на пощенски кутии Път за данни Необходими портове Удостоверяване по подразбиране Поддържан метод за удостоверяване Шифроване Поддръжка Шифроване на данни по подразбиране

	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мрежово RPC влизане)			Да, използвайки Kerberos криптиране
Административни отдалечен достъп(отдалечен регистър)				Да, използвайки IPsec
Административен отдалечен достъп (SMB, файлове)				Да, използвайки IPsec
Уеб услуга за наличност (клиентски достъп до пощенска кутия)				Да, използвайки RPC криптиране
Клъстеризиране				Да, използвайки RPC криптиране
Между сървъри за клиентски достъп (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)		Удостоверяване на Kerberos сертификат	Да, използвайки HTTPS	Да, използвайки самоподписан сертификат
Между сървъри за клиентски достъп (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)			Да, използвайки SSL
Сървър за клиентски достъп към сървър за клиентски достъп (Exchange Web Services)				Да, използвайки SSL
Сървър за клиентски достъп към сървър за клиентски достъп (POP3)				Да, използвайки SSL
Сървър за клиентски достъп към сървър за клиентски достъп (IMAP4)				Да, използвайки SSL
Office Communications Server към сървър за клиентски достъп (когато интеграцията на Office Communications Server и Outlook Web App е активирана)	5075-5077/TCP (IN), 5061/TCP (OUT)	mTLS (задължително)	mTLS (задължително)	Да, използвайки SSL

Бележки за сървъри за клиентски достъп сървъри за унифицирани съобщения

IP шлюзовете и IP телефонните централи поддържат само автентификация със сертификати, която използва взаимно TLS удостоверяване за шифроване на SIP трафик и удостоверяване на базата на IP адрес за SIP или TCP връзки. IP шлюзовете не поддържат NTLM или Kerberos удостоверяване. Следователно, когато използвате удостоверяване, базирано на IP адрес, IP адресите на връзките се използват като механизъм за удостоверяване за некриптирани (TCP) връзки. Когато се използва в Unified Messaging, удостоверяването на базата на IP проверява дали даден IP адрес има разрешение за свързване. IP адресът е конфигуриран на IP шлюза или IP PBX.

IP шлюзовете и IP PBX поддържат Mutual TLS за криптиране на SIP трафик. След успешно импортиране и експортиране на необходимите доверени сертификати, IP шлюзът или IP PBX ще поиска сертификат от сървъра за унифицирани съобщения и след това ще поиска сертификата от IP шлюза или IP PBX. Обменът на доверени сертификати между IP шлюза или IP PBX и сървъра за унифицирани съобщения позволява на двете устройства да комуникират по защитен канал, използвайки Mutual TLS.

Следващата таблица предоставя информация за порт, удостоверяване и криптиране за пътища на данни между сървъри за унифицирани съобщения и други сървъри.

Пътища за данни за сървъри за унифицирани съобщения Път за данни Необходими портове Удостоверяване по подразбиране Поддържан метод за удостоверяване Шифроване Поддръжка Шифроване на данни по подразбиране

Достъп до Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (мрежово RPC влизане)			Да, използвайки Kerberos криптиране
Телефония за унифицирани съобщения (IP PBX/VoIP Gateway)	5060/TCP, 5065/TCP, 5067/TCP (незащитен режим), 5061/TCP, 5066/TCP, 5068/TCP (сигурен режим), динамичен диапазон на портове 16000-17000/TCP (контрол), динамични UDP портове от диапазона 1024-65535/UDP (RTP)	По IP адрес	Чрез IP адрес, MTLS	Да, използвайки SIP/TLS, SRTP
Уеб услуга за унифицирани съобщения	80/TCP, 443/TCP (SSL)	Интегрирано Windows удостоверяване (договаряне)		Да, използвайки SSL
От сървъра за унифицирани съобщения до сървъра за клиентски достъп	5075, 5076, 5077 (TCP)	Интегрирано Windows удостоверяване (договаряне)	Basic, Digest, NTLM, Negotiate (Kerberos)	Да, използвайки SSL
От сървър за унифицирани съобщения до сървър за клиентски достъп (играйте на телефона)	Динамичен RPC			Да, използвайки RPC криптиране
От сървър за унифицирани съобщения до сървър Hub Transport				Да, с помощта на TLS
От сървър за унифицирани съобщения до сървър за пощенска кутия				Да, използвайки RPC криптиране

Бележки за сървъри за унифицирани съобщения

Когато създавате обект на IP шлюз за унифицирани съобщения в Active Directory, трябва да посочите IP адреса на физическия IP шлюз или IP PBX. Когато определите IP адреса на обект на UM IP шлюз, IP адресът се добавя към списъка с валидни IP шлюзове или IP PBX (известни също като участници в SIP сесии), с които сървърът за унифицирани съобщения има право да комуникира. След като създадете IP шлюз за унифицирани съобщения, можете да го свържете с план за набиране на унифицирани съобщения. Съпоставянето на UM IP шлюз към план за набиране позволява на сървърите за унифицирани съобщения, които са нанесени към плана за набиране, да използват удостоверяване, базирано на IP адрес, за да комуникират с IP шлюза. Ако IP шлюзът за унифицирани съобщения не е създаден или не е конфигуриран да използва правилния IP адрес, удостоверяването ще бъде неуспешно и сървърите за унифицирани съобщения няма да приемат връзки от IP адреса на IP шлюза. Освен това, когато внедрявате Mutual TLS, IP шлюз или IP PBX и сървъри за унифицирани съобщения, UM IP шлюзът трябва да бъде конфигуриран да използва пълно квалифицирано име на домейн (FQDN). След като конфигурирате UM IP шлюз, като използвате напълно квалифицирано име на домейн, трябва също да добавите запис на хост за този шлюз към зоната за препращащо DNS търсене.
В Exchange 2010 сървърът за унифицирани съобщения може да комуникира на порт 5060/TCP (незащитен) или порт 5061/TCP (защитен) и може да бъде конфигуриран да използва и двата порта.

За повече информация вижте разбиране на VoIP сигурността на унифицираните съобщения и разбиране на протоколите, портовете и услугите за унифицирани съобщения.

правила Защитна стена на Windowsсъздаден от настройката на Exchange 2010

Защитната стена на Windows с разширена защита е машинно базирана защитна стена с проследяване на състоянието, която филтрира входящия и изходящия трафик въз основа на правилата на защитната стена. Настройката на Exchange 2010 създава правила за защитна стена на Windows, за да отвори портовете, необходими за комуникация сървър-клиент във всяка сървърна роля. Следователно вече не е необходимо да използвате съветника за конфигуриране на сигурността, за да конфигурирате тези настройки. За повече информация относно защитната стена на Windows с разширена защита вижте Защитна стена на Windows с разширена защита и IPsec.

Следващата таблица показва правилата на защитната стена на Windows, които настройката на Exchange създава, включително портовете, които са отворени във всяка сървърна роля. Можете да прегледате тези правила, като използвате MMC модула за защитна стена на Windows с разширена защита.

Име на правило Роли на сървър Порт Програма

MSExchangeADTopology - RPC (TCP-in)		Динамичен RPC	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP-in)	Сървър за клиентски достъп, Hub Transport сървър, Edge Transport сървър, Unified Messaging сървър	Динамичен RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP-in)		Динамичен RPC	Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP-in)			Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP-in)
MSExchangeRPC (GFW) (TCP-in)	Сървър за клиентски достъп, сървър за транспортен център, сървър за пощенска кутия, сървър за унифицирани съобщения	Динамичен RPC
MSExchange - IMAP4 (GFW) (TCP-in)	Сървър за клиентски достъп
MSExchangeIMAP4 (TCP-in)	Сървър за клиентски достъп		ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP-in)	Сървър за клиентски достъп
MSExchange - POP3 (TCP-in)	Сървър за клиентски достъп		ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP-in)	Сървър за клиентски достъп	5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (TCP-in)	Сървър за клиентски достъп	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
MSExchangeAB RPC (TCP-in)	Сървър за клиентски достъп	Динамичен RPC
MSExchangeAB-RPCEPMap (TCP-in)	Сървър за клиентски достъп		Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP-in)	Сървър за клиентски достъп	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP-in)	Сървър за клиентски достъп	Динамичен RPC	System32\Svchost.exe
MSExchangeRPC - RPC (TCP-in)		Динамичен RPC
MSExchangeRPC - PRCEPMap (TCP-in)	Сървър за клиентски достъп, сървър за пощенска кутия		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP-in)	Сървър за клиентски достъп, сървър за пощенска кутия		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP-in)	Сървър за клиентски достъп
MSExchangeMailboxReplication (TCP-in)	Сървър за клиентски достъп		Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC
MSExchangeIS RPCEPMap (TCP-in)	Сървър на пощенска кутия
MSExchangeIS (GFW) (TCP-in)	Сървър на пощенска кутия	6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (TCP-in)	Сървър на пощенска кутия
MSExchangeMailboxAssistants - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC
MSExchangeMailboxAssistants - RPCEPMap (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC
MSExchangeMailSubmission - RPCEPMap (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC	Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeMigration.exe
MSExchangerepl - Копирно устройство за регистрационни файлове (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC	Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC	Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP-in)	Сървър на пощенска кутия		Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP-in)	Сървър на пощенска кутия	Динамичен RPC
MSFTED - RPCEPMap (TCP-in)	Сървър на пощенска кутия
MSExchangeEdgeSync - RPC (TCP-in)	Хъб транспортен сървър	Динамичен RPC
MSExchangeEdgeSync RPCEPMap (TCP-in)	Хъб транспортен сървър		Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP-in)	Хъб транспортен сървър	Динамичен RPC	Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP-in)	Хъб транспортен сървър		Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP-in)	Хъб транспортен сървър
MSExchangeTransportWorker (TCP-in)	Хъб транспортен сървър		Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP-in)		Динамичен RPC
MSExchangeTransportLogSearch - RPCEPMap (TCP-in)	Hub Transport Server, Edge Transport Server, Mailbox Server		Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP-in)	Сървър за унифицирани съобщения
SESWorker (TCP-in)	Сървър за унифицирани съобщения		UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP-in)	Сървър за унифицирани съобщения
UMService (TCP-in)	Сървър за унифицирани съобщения		Bin\UMService.exe
UMWorkerProcess (GFW) (TCP-in)	Сървър за унифицирани съобщения	5065, 5066, 5067, 5068
UMWorkerProcess (TCP-in)	Сървър за унифицирани съобщения	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP-in)	Сървър за унифицирани съобщения	Динамичен RPC	Bin\UMWorkerProcess.exe

Бележки относно правилата на защитната стена на Windows, създадени от инсталационната програма на Exchange 2010

На сървъри с инсталиран IIS Windows отваря HTTP (порт 80, TCP) и HTTPS (порт 443, TCP) портове. Инсталационната програма на Exchange 2010 не отваря тези портове. Следователно тези портове не са изброени в предишната таблица.
IN Windows сървър 2008 и Windows Server 2008 R2, защитната стена на Windows с разширена защита ви позволява да посочите процеса или услугата, за които е отворен порт. Това е по-сигурно, защото портът може да се използва само от процеса или услугата, посочени в правилото. Настройката на Exchange създава правила за защитна стена с указаното име на процес. В някои случаи за целите на съвместимостта се създава и допълнително правило, което не е ограничено до този процес. Можете да деактивирате или премахнете правила, които не са ограничени от процеси, и да запазите съответните правила, ограничени от процеси, ако текущата ви среда за разполагане ги поддържа. Правилата, които не са ограничени до процеси, могат да бъдат идентифицирани чрез думата (GFW) в името на правилото.
Много услуги на Exchange използват извиквания на отдалечени процедури (RPC) за комуникация. Сървърните процеси, които използват извиквания на отдалечени процедури, се свързват с RPC картографа на крайна точка, за да получат динамични крайни точки и да ги регистрират в базата данни на картографа на крайна точка. RPC клиентите взаимодействат с RPC съпоставителя на крайни точки, за да определят крайните точки, използвани от сървърния процес. По подразбиране преобразувателят на RPC крайна точка слуша на порт 135 (TCP). Когато конфигурирате защитната стена на Windows за процес, който използва извиквания на отдалечени процедури, настройката на Exchange 2010 създава две правила за защитна стена за този процес. Едното правило позволява взаимодействие с картографа на RPC крайна точка, а второто позволява взаимодействие с динамично присвоена крайна точка. За повече информация относно извикванията на отдалечени процедури вижте тази статия. За повече информация относно създаването на правила на защитната стена на Windows за динамични извиквания на отдалечени процедури вижте тази статия.
За повече информация вижте статия 179442 от базата знания на Microsoft

Популярни в категорията: