Головна › Інтернет › Довідник по мережних портах Exchange. Підключення поштових клієнтів до Microsoft Exchange Server Шляхи даних для серверів поштових скриньок

Довідник по мережних портах Exchange. Підключення поштових клієнтів до Microsoft Exchange Server Шляхи даних для серверів поштових скриньок

[Ця стаття є попереднім документом і може бути змінена в майбутніх випусках. Порожні розділи включені як наповнювачі. Якщо ви хочете написати відгук, ми будемо раді отримати його. Надішліть його нам на електронну адресу [email protected].]

Застосовується до: Exchange Server 2016

Відомості про мережні порти, які Exchange 2016 використовує для клієнтського доступу та потоку обробки пошти.

У цьому розділі наведено відомості про мережні порти, які використовуються Microsoft Exchange Server 2016 для зв'язку з поштовими клієнтами, поштовими серверами в Інтернеті та іншими службами, які розташовані поза вашою локальною організацією Exchange. Перш ніж розпочати, обміркуйте такі основні правила.

Ми не підтримуємо обмеження або зміну мережного трафіку між внутрішніми серверами Exchange Server, між внутрішніми серверами Exchange Server та внутрішніми серверами Lync або Skype для бізнесу або між внутрішніми серверами Exchange Server та внутрішніми контролерами домену Active Directory в жодному з типів топологій. Якщо ви використовуєте брандмауери або мережеві пристрої, які можуть обмежити або змінити цей мережевий трафік, необхідно налаштувати правила, що забезпечують вільний та необмежений зв'язок між цими серверами (правила, що допускають вхідний та вихідний мережевий трафік на будь-який порт, включаючи випадкові порти RPC, та будь-який протокол) , який не змінює жодного біта).

Прикордонні транспортні сервери майже завжди знаходяться в мережі периметра, тому очікується, що мережевий трафік між прикордонним транспортним сервером та Інтернетом, а також між прикордонним транспортним сервером та внутрішньою організацією Exchange буде обмежено. Ці порти мережі описані в цьому розділі.

Очікується, що ви обмежите мережевий трафік між зовнішніми клієнтами та службами та внутрішньою організацією Exchange. Також можна обмежити трафік між внутрішніми клієнтами та внутрішніми серверами Exchange. Ці порти мережі описані в цьому розділі.

Зміст

Network ports required for clients and services

Network ports потрібна для mail flow (no Edge Transport servers)

Network ports required for mail flow with Edge Transport servers

Network ports required for hybrid deployments

Network ports потрібна для Unified Messaging

Мережні порти, які потрібні поштовим клієнтам для доступу до поштових скриньок та інших служб в організації Exchange, описані на наступній діаграмі та таблиці.

Примітки.

Пункт призначення для цих клієнтів та служб є служби клієнтського доступу на сервері поштових скриньок. В Exchange 2016 служби клієнтського доступу (зовнішні) та внутрішні служби встановлюються разом на одному сервері поштових скриньок. Щоб отримати додаткові відомості, див.

Хоча на діаграмі показані клієнти та служби з Інтернету, концепції однакові і для внутрішніх клієнтів (наприклад, клієнтів у лісі облікових записів, які звертаються до серверів Exchange у лісі ресурсів). Аналогічно в таблиці немає стовпця "Джерело", оскільки джерелом може бути будь-яке зовнішнє по відношенню до організації Exchange місцезнаходження (наприклад, Інтернет або ліс облікових записів).

Прикордонні транспортні сервери не беруть участь у мережевому трафіку, пов'язаному з цими клієнтами та службами.

Призначення Порти Примітки

Зашифровані підключення використовуються наступними клієнтами та службами. Служба автовиявлення Exchange ActiveSync Веб-служби Exchange (EWS) Розповсюдження автономних адресних книг Мобільний Outlook (протокол RPC через HTTP) MAPI Outlook через HTTP Outlook в Інтернеті	443/TCP (HTTPS)	Довідник EWS для Exchange
Незашифровані підключення використовуються наступними клієнтами та службами. Публікація календаря в Інтернеті 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 з автентифікацією)	Стандартний з'єднувач "Client Frontend у зовнішній транспортній службі прослуховує повідомлення від клієнтів SMTP, що пройшли перевірку справжності, на порту 587. Примітка. Якщо у вас є поштові клієнти, які можуть надсилати повідомлення по протоколу SMTP з автентифікацією тільки через порт 25, то ви можете змінити значення прив'язки цього з'єднувача отримання, щоб він також відстежував відправлення повідомлень по протоколу SMTP з автентифікацією через порт 25.

На початок

Мережні порти, необхідні для потоку обробки пошти

Вихідна пошта

25/TCP (SMTP)

Сервер поштових скриньок

Інтернет (все)

За промовчанням Exchange не створює з'єднувачі відправки, які дозволяють надсилати пошту до Інтернету. Необхідно створити з'єднувачі відправки вручну. Щоб отримати додаткові відомості, див.

Вихідна пошта (якщо вона передається через зовнішню службу транспорту)

25/TCP (SMTP)

Сервер поштових скриньок

Інтернет (все)

Вихідна пошта передається через зовнішню службу транспорту, лише якщо для з'єднувача відправки увімкнено параметр Проксі через сервер клієнтського доступу в Центрі адміністрування Exchange або параметр -FrontEndProxyEnabled $true у командній консолі Exchange.

У цьому випадку з'єднувач отримання за промовчанням "Outbound Proxy Frontend " у зовнішній службі транспорту прослуховує вихідну пошту зі служби транспорту на сервері поштових скриньок. Додаткові відомості див. у статті .

DNS-сервер для дозволу імен наступного переходу пошти (не показано на малюнку)

53/UDP, 53/TCP (DNS)

Сервер поштових скриньок

DNS-сервер

На початок

Підписаний прикордонний транспортний сервер, встановлений у мережі периметра, впливає на потік обробки пошти таким чином:

Вихідна пошта з організації Exchange ніколи не проходить через зовнішню службу транспорту на серверах поштових скриньок. Вона завжди перенаправляється зі служби транспорту на сервері поштових скриньок підписаного сайту Active Directory на прикордонний транспортний сервер (незалежно від версії Exchange на прикордонному транспортному сервері).

Пошта, що входить, перенаправляється з прикордонного транспортного сервера на сервер поштових скриньок підписаного сайту Active Directory. Це означає таке:

Пошта з прикордонного транспортного сервера Exchange 2016 або Exchange 2013 спочатку надходить до зовнішньої служби транспорту, а потім перенаправляється до служби транспорту на сервері поштових скриньок Exchange 2016.
Пошта з прикордонного транспортного сервера Exchange 2010 завжди надходить безпосередньо до служби транспорту на сервері поштових скриньок Exchange 2016.

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

Призначення Порти Джерело Призначення Примітки

Пошта, що входить - з Інтернету на прикордонний транспортний сервер	25/TCP (SMTP)	Інтернет (все)		Стандартний з'єднувач прийому "Внутрішній з'єднувач отримання за замовчуванням на прикордонному транспортному сервері прослуховує анонімну пошту SMTP на порту 25.
Вхідна пошта - від прикордонного транспортного сервера до внутрішньої організації Exchange	25/TCP (SMTP)	Прикордонний транспортний сервер		З'єднувач відправки за промовчанням з ім'ям "EdgeSync - Inbound to ретранслює вхідну пошту з порту 25 на будь-який сервер поштових скриньок підписаного сайту Active Directory. Додаткові відомості див. у розділі . Стандартний з'єднувач "Default Frontend у зовнішній службі транспорту на сервері поштових скриньок прослуховує всю вхідну пошту (включаючи пошту з прикордонних транспортних серверів Exchange 2016 та Exchange 2013) на порту 25.
Вихідна пошта - від внутрішньої організації Exchange на прикордонний транспортний сервер	25/TCP (SMTP)	Сервери поштових скриньок на підписаному Active Directory		Вихідна пошта завжди оминає зовнішню службу транспорту на серверах поштових скриньок. Пошта ретранслюється зі служби транспорту на будь-якому сервері поштових скриньок підписаного сайту Active Directory на прикордонний транспортний сервер за допомогою неявного та невидимого внутрішньоорганізаційного з'єднувача відправки, який автоматично перенаправляє пошту між серверами Exchange Server в одній організації. З'єднувач за промовчанням "Default internal Receive connector на прикордонному транспортному сервері прослуховує пошту за протоколом SMTP на порту 25 зі служби транспорту на будь-якому сервері поштових скриньок підписаного сайту Active Directory.
Вихідна пошта - з прикордонного транспортного сервера до Інтернету	25/TCP (SMTP)	Прикордонний транспортний сервер	Інтернет (все)	З'єднувач відправки за промовчанням з ім'ям "EdgeSync - з в Інтернет" ретранслює вихідну пошту порту 25 з прикордонного транспортного сервера в Інтернет.
Синхронізація EdgeSync	50636/TCP (безпечний LDAP)	Сервери поштових скриньок на підписаному сайті Active Directory, які беруть участь у синхронізації EdgeSync	Прикордонні транспортні сервери	Якщо прикордонний транспортний сервер підписано на сайт Active Directory, всі сервери поштових скриньок, які існують на сайті в даний момент, беруть участь у синхронізації EdgeSync. Але якщо додати інші сервери поштових скриньок пізніше, вони не будуть автоматично брати участь у синхронізації EdgeSync.
DNS-сервер для дозволу імен наступної транзитної ділянки (не показано на малюнку)	53/UDP, 53/TCP (DNS)	Прикордонний транспортний сервер	DNS-сервер	розділ Роздільна здатність імен.
Виявлення відкритого проксі-сервера у службі репутації відправників (не показано малюнку)	Див. примітки	Прикордонний транспортний сервер	Інтернет	За замовчуванням агент аналізу протоколу використовує виявлення відкритого проксі-сервера як одну з умов обчислення рівня репутації вихідного сервера обміну повідомленнями. Для отримання додаткових відомостей див . Для перевірки вихідних серверів обміну повідомленнями на наявність відкритого проксі-сервера використовуються такі TCP-порти: Крім того, якщо у вашій організації для контролю вихідного інтернет-трафіку використовується проксі-сервер, необхідно визначити ім'я, тип та TCP-порт проксі-сервера, необхідні для доступу до Інтернету та виявлення відкритого проксі-сервера. Ви також можете вимкнути виявлення відкритого проксі-сервера. Щоб отримати додаткові відомості, див.

На початок

Дозвіл імен

Дозвіл DNS наступного переходу пошти є основною складовою потоку обробки пошти в будь-якій організації Exchange. Сервери Exchange, які відповідають за отримання вхідної пошти або доставку вихідної, повинні мати можливість дозволяти як внутрішні, так і зовнішні імена вузлів для правильної маршрутизації пошти. Усі внутрішні сервери Exchange повинні мати можливість дозволяти внутрішні імена вузлів для правильної маршрутизації пошти. Існує безліч різних способів розробки інфраструктури DNS, але важливий результат - забезпечення правильної роздільної здатності імен для наступного переходу на всіх серверах Exchange.

What TCP and UDP ports does my Exchange 2000/2003 Server use?

Для того, щоб configuring firewalls або для проблем з комунікаційними службами, це може бути корисним для того, щоб TCP/UDP порти Exchange 2000 Server і Exchange 2000 Conferencing Server є використання. Цей матеріал також є true for Exchange Server 2003 installations.

Protocol: LDAP

Port (TCP/UDP): 389 (TCP)
Description: Lightweight Directory Access Protocol (LDAP), використовуваний Active Directory, Active Directory Connector, та Microsoft Exchange Server 5.5 directory.

Protocol: LDAP/SSL

Port (TCP/UDP): 636 (TCP)
Description: LDAP за допомогою Secure Sockets Layer (SSL). Якщо SSL є налагодженим, LDAP data, що є переведена і отримана, є розглянутою.
Для того, щоб забезпечити SSL, ви повинні налаштовувати комп'ютер certificate на домашній контролер або Exchange Server 5.5 комп'ютера.

Protocol: LDAP

Port (TCP/UDP): 379 (TCP)
Description: Служба Replication Service (SRS) використовує TCP port 379.

Protocol: LDAP

Port (TCP/UDP): 390 (TCP)
Description: Коли не існує стандартний LDAP port, TCP port 390 є відповідним іншим портом для налаштування Exchange Server 5.5 LDAP protocol при Exchange Server 5.5 is running on a Microsoft Windows 2000 Active Directory domain controller.

Protocol: LDAP

Port (TCP/UDP): 3268 (TCP)
Description: Global catalog. Windows 2000 Active Directory Global Catalog (який є справжнім домашнім контролером “роля”) повідомлень на TCP port 3268. Якщо ви рекомендуєте,використовувати питання, які можуть бути віднесені до Global Catalog, connect to port 3268 in LDP.

Protocol: LDAP/SSL

Port (TCP/UDP): 3269 (TCP)
Description: Global catalog over SSL. Applications that connect to TCP port 3269 of Global Catalog Server може transmit and receive SSL завантажені дані. Щоб налаштувати глобальний каталог для підтримки SSL, ви повинні налаштовувати комп'ютер certificate на глобальному каталогу.

Protocol: IMAP4

Port (TCP/UDP): 143 (TCP)
Description: Internet Message Access Protocol Version 4, який може бути використаний як “стандарти-базовані” клієнти, є Microsoft Outlook Express або Netscape Communicator для доступу до електронної пошти. IMAP4 runs on top of Microsoft Internet Information Service (IIS) Admin Service (Inetinfo.exe), і достатній клієнт access to the Exchange 2000 information store.

Protocol: IMAP4/SSL

Port (TCP/UDP): 993 (TCP)
Description: IMAP4 за допомогою SSL використовує TCP port 993. Перед сервером Exchange 2000 support IMAP4 (або будь-який інший протокол) за допомогою SSL, ви повинні налаштовувати на комп'ютері certificate на сервері Exchange 2000.

Protocol: POP3

Port (TCP/UDP): 110 (TCP)
Description: Post Office Protocol version 3, налаштовані “standards-based” clients such as Outlook Express або Netscape Communicator для доступу до e-mail server. Як з IMAP4, POP3 відправляються на верхню службу IIS Admin Service, і достатні клієнтські послуги до Exchange 2000 інформаційний центр.

Protocol: POP3/SSL

Port (TCP/UDP): 995 (TCP)
Опис: POP3 over SSL. Для забезпечення POP3 over SSL, ви повинні налаштовувати комп'ютерний certificate на сервері Exchange 2000.

Protocol: NNTP

Port (TCP/UDP): 119 (TCP)
Description: Network News Transport Protocol, деякими названими Usenet protocol, належним чином “standards-based” client access to public folders in the information store. Як з IMAP4 і POP3, NNTP залежить від IIS Admin Service.

Protocol: NNTP/SSL

Port (TCP/UDP): 563 (TCP)

Description: NNTP over SSL. Для забезпечення NNTP over SSL, ви повинні налаштовувати комп'ютер certificate на Exchange 2000 Server.

Protocol: HTTP

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

Protocol: HTTP/SSL

Port (TCP/UDP): 443 (TCP)
Description: HTTP over SSL. Для забезпечення HTTP over SSL, ви повинні налаштовувати комп'ютер certificate на сервері Exchange 2000.

Protocol: SMTP

Port (TCP/UDP): 25 (TCP)
Description: Simple Mail Transfer Protocol, є повідомлення для всіх електронної пошти в Exchange 2000. SMTP Service (SMTPSvc) runs on top of IIS Admin Service. Unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 does notВикористовуйте окремий port для надійної комунікації (SSL), а ще один, працюючий “на базі безпеки субсистеми” називається Transport Layer Security (TLS).

Protocol: SMTP/SSL

Port (TCP/UDP): 465 (TCP)
Description: SMTP over SSL. TCP port 465 is reserved common industry practice for secure SMTP communication using the SSL protocol. Одначе, unlike IMAP4, POP3, NNTP, і HTTP, SMTP в Exchange 2000 не може використовувати окремий port для захисту комунікацій (SSL), але інші, трудяться "в-засобі захисту субсистеми" називається Transport Layer Security (TLS) . Для забезпечення TLS працює на Exchange 2000, ви повинні install на комп'ютері certificate на сервері Exchange 2000.

Protocol: SMTP/LSA

Port (TCP/UDP): 691 (TCP)
Description: У Microsoft Exchange Routing Engine (як відомо, як RESvc) літери для повідомлень електронної пошти стану інформації на TCP port 691. Exchange 2000 використовується routing link state information для повідомлень електронної пошти та routing table is constantly updated. The Link State Algorithm (LSA) propagates outing status information між Exchange 2000 servers. Цей algoritm базується на Open Shortest Path First (OSPF) протоколі з мережевої технології, і transfers link state information між routing groups з використанням X-LSA-2 комбінаційної версії через SMTP і з використанням Transmission Control Protocol (TCP) з'єднання port 691 в routing group.

Protocol: RVP

Port (TCP/UDP): 80 (TCP)
Description: RVP є підготовкою до Instant Messaging в Exchange 2000. У той час як RVP з'єднується з TCP port 80, сервер підключається до нового підключення до клієнта на епеморальний TCP port до 1024. Тому цей порт є issues exist when you enable Instant Messaging через firewall.

Protocol: IRC/IRCX

Port (TCP/UDP): 6667 (TCP)
Description: Internet Relay Chat (IRC) - це chat protocol. IRCX is the extended version offered by Microsoft. Коли TCP port 6667 є найбільшим спільним port для IRC, TCP port 7000 є також дуже frequently used.

Protocol: IRC/SSL

Port (TCP/UDP): 994 (TCP)
Description: IRC або Chat через SSL. IRC або IRCX над SSL не підтримується в Exchange 2000.

Protocol: X.400

Port (TCP/UDP): 102 (TCP)
Description: ITU-T Recommendation X.400 є реально series recomendations for what electronic message handling system (MHS) should look like. TCP port 102 є визначеним в IETF RFC-1006, який описує OSI Communications over a TCP/IP network. В brief, TCP port 102 is the port that the Exchange message transfer agent (MTA) використовується для комунікації з іншими X.400-capable MTAs.

Protocol: MS-RPC

Port (TCP/UDP): 135 (TCP)
Description: Microsoft Remote procedure Call є Microsoft implementation of remote procedure calls (RPCs). TCP port 135 є фактично тільки RPC Locator Service, який є як реєстратор для всіх RPC-обслуговуваних послуг, які використовуються на окремому сервері. В Exchange 2000, Routing Group Connector використовує RPC додаток до SMTP, коли target bridgehead server is running Exchange 5.5. Також, деякі адміністративні операції потрібні RPC. Щоб configure firewall до enable RPC traffic, багато more ports than just 135 must be enabled.

Для додаткової інформації, клацніть сторінки номерів для перегляду статей в Microsoft Knowledge Base:

XADM: Setting TCP/IP Port Numbers for Internet Firewalls

XCON: Налаштування MTA TCP/IP Port # for X.400 and RPC Listens

Protocol: T.120

Port (TCP/UDP): 1503 (TCP)
Description: ITU-T Recommendation T.120 є основою відповідей, що define data conferencing. Data conferencing є здійснена на сервері сторони як Conferencing Technology Provider (CTP) в Multipoint Control Unit (MCU), який є одним з компонентів Exchange Conferencing Services (ECS). Data conferencing є здійснений на клієнта, як Chat, Application Sharing, Whiteboard, і File Transferring в Microsoft NetMeeting.

Protocol: ULS

Port (TCP/UDP): 522 (TCP)
Description: User Locator Service є типом Інтернет-ресурсів для конференційних клієнтів, так як NetMeeting. Exchange 2000 Server і Exchange 2000 Конференція Server не може реалізовувати ULS, але згодом приймає додаток до служб Active Directory (Directory Services TCP 389).

Protocol: H.323 (Video)

Port (TCP/UDP): 1720 (TCP)
Description: ITU-T Recommendation H.323 defines multimedia conferencing. TCP port 1720 є H.323 (video) call setup port. Після клієнта підключення, H.323 сервер невідповідає новий, динамічний UDP port буде використовуватися для streaming data.

Protocol: Audio

Port (TCP/UDP): 1731 (TCP)
Description: Audio conferencing is enabled in much the same way as H.323 video conferencing is enabled in Exchange 2000 Server. Після клієнтів підключення до TCP port 1731, новий динамічний port is negotiated for further streaming data.

Exchange Server та брандмауери

Брандмауери (файрволли) для поштових серверів (Exchange Server), порти поштових серверів, front-end та back-end поштові сервери, віртуальні сервери SMTP, POP3, IMAP4

Як і будь-який комп'ютер, підключений до Інтернету, комп'ютер, де стоїть поштовий сервер, необхідно захищати за допомогою брандмауера. При цьому варіанти встановлення поштового сервера з точки зору конфігурації мережі можуть бути різними:

· Найпростіший варіант - встановити поштовий сервер на комп'ютер, який одночасно є проксі-сервером/брандмауером, а потім на інтерфейсі, який звернений до Інтернету, відкрити необхідні порти. Зазвичай така схема застосовується у невеликих організаціях;

· Ще один варіант - встановити поштовий сервер в локальної мережіта налаштувати його роботу через проксі-сервер. Для цього можна прив'язати до поштового сервера public ip та пропускати його через проксі або скористатися засобами типу port mapping на проксі-сервері. На багатьох проксі-серверах є спеціальні майстри або заздалегідь заготовлені правила для організації такого рішення (наприклад, ISA Server). Такий варіант використовується у більшості організацій.

· Ще одна важлива можливість - створити DMZ і помістити в неї front-end Exchange Server (така можливість з'явилася, починаючи з версії 2000) або SMTP Relay на основі іншого Exchange Server або, наприклад, sendmail на *nix. Зазвичай застосовується у мережах великих організацій.

У будь-якому випадку для поштового сервера необхідно забезпечити взаємодію як мінімум на порту TCP 25 (SMTP ) і UDP 53 (DNS ). Інші порти, які можуть знадобитися Exchange Server в залежності від конфігурації вашої мережі (всі - TCP):

· 80 HTTP - для доступу на Web-інтерфейс (OWA)

· 88 Kerberos authentication protocol - якщо використовується аутентифікація Kerberos (рідко);

· 102 MTA .X .400 connector over TCP /IP (якщо використовується конектор X .400 для зв'язку між групами маршрутизації);

· 110 Post Office Protocol 3 (POP 3) – для доступу клієнтів;

· 119 Network News Transfer Protocol (NNTP) - якщо використовуються групи новин;

· 135 Client /server communication RPC Exchange administration - стандартний порт RPC для віддаленого адміністрування Exchange стандартними засобами System Manager;

· 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 and 3269 - запити до сервера глобального каталогу (пошук Active Directory і перевірка членства в universal groups).

Інтерфейс Exchange Server, звернений всередину організації, закривати брандмауером немає сенсу - по ньому відбуватиметься взаємодія з контролерами домену, утилітами адміністрування, системами резервного копіювання тощо. Для інтерфейсу, відкритого в Інтернет, рекомендується залишити порти 53 (якщо Exchange дозволятиме імена хостів сам, а не перенаправляти запити на локальний сервер DNS) та 25. Дуже часто клієнтам необхідно звертатися до своїх поштових скриньок ззовні (з дому, під час відрядження тощо). Найкраще рішення в цій ситуації - налаштувати OWA (Web-інтерфейс для доступу на Exchange Server, який встановлюється за замовчуванням, доступний за адресою http://ім'я_сервера/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 Exchange

OAB (Offline Address Book) - автономна адресна книга

EWS (Exchange Web Services) – сервіс, що надає доступ до даних поштової скриньки, що зберігаються у Exchange Online (як частина Office 365) та у локальній версії Exchange (починаючи з Exchange Server 2007)

Параметри сервера Exchange

Важливим моментом для успішної роботи не-Microsoft-клієнтів на Exchange 2010 є автентифікація. Подивитися її параметри можна на сервері Exchange за участю CAS (Client Access Server). Запустіть оснастку «Диспетчер служб IIS» та відкрийте вкладку «Сайти»/Default Web Site. Зверніть увагу на автентифікацію в трьох компонентах:

OWA - Стан «Увімкнено» для «Звичайна автентифікація» та «Перевірка автентичності Windows »:

OAB - Стан "Увімкнено" для "Звичайна автентифікація" та "Перевірка автентичності Windows":

EWS - Стан "Увімкнено" для "Анонімна автентифікація", "Звичайна автентифікація" та "Перевірка автентичності Windows":

Прошарок (посередники) та допоміжні утиліти DavMail

Деякі поштові клієнти не можуть безпосередньо підключатися до Microsoft Exchange і вимагають використання прошарку (посередника). В даному прикладі як посередник використовується проксі-сервер DavMail.

Встановіть DavMail, отримавши права адміністратора за допомогою su або sudo:

sudo urpmi davmail

Запустіть DavMail:

На вкладці "Main" у полі "OWA (Exchange) URL" введіть адресу свого сервера у форматі "https:///EWS/Exchange.asmx" або посилання на OWA

у форматі "https:///owa".

Запам'ятайте номери портів «Local IMAP port» та «Local SMTP port». У цьому прикладі це 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-ru

Встановіть додаток lightning, що дозволяє використовувати календарі:

sudo urpmi mozilla-thunderbird-lightning

Запустіть Thunderbird.

У розділі «Облікові записи» у пункті «Створити обліковий запис» виберіть « Електронна пошта». З'явиться вікно привітання.

У вікні, натисніть кнопку [Пропустити це та використовувати мою існуючу пошту ].

У вікні «Налаштування облікового запису пошти» введіть у поле «Ваше ім'я», «Адреса ел. пошти» та «Пароль» свої облікові дані.

Натисніть [Продовжити]. Програма спробує знайти підключення (безуспішно), і з'явиться повідомлення про помилку:

Тут вам знадобляться номери портів, які ви запам'ятали під час налаштування DavMail.

Для категорій "Вхідна" та "Вихідна" змініть ім'я сервера на "localhost".
Вкажіть для IMAP порт 1143, а для SMTP порт 1025.
У полі "Ім'я користувача" вкажіть UPN (User Principal Name) - доменне ім'я користувача у форматі "Ім'я Користувача@ДоменОрганізації.ru".
Натисніть кнопку [Перевірка ].

У разі правильного введення облікових даних помилок не буде. Можливо, система повідомить про необхідність ухвалити сертифікат сервера Exchange. Якщо цього не відбувається, можливо, ви занадто рано вимкнули інтерфейс DavMail.

Створення календаря користувача

У категорії «Облікові записи» виберіть «Створити новий календар».
У вікні виберіть значення «В мережі» і натисніть [Далі].
Виберіть формат «CalDAV» і введіть «http://localhost:1080/users/ /calendar» у полі «Адреса»:

Створення адресної книги

Адресна книга Thunderbirdне підтримує протокол CardDAV і може бути підключений лише до каталогу LDAP сервера Exchange.

Відкрийте існуючі адресні книги, натиснувши кнопку [Адресна книга ] і вибравши «Файл → Створити → Каталог LDAP».

У вікні майстра вкажіть такі параметри:
- Назва - будь-яке відповідне ім'я
- Ім'я сервера - localhost
- Кореневий елемент (Base DN) - ou=people
- Порт - 1389 (з Davmail)
- Ім'я користувача (Bind DN) - UPN-ім'я користувача

Натисніть [OK]. Програма попросить ввести пароль.

Зайдіть до меню параметрів Thunderbird. У категорії «Складання» виберіть вкладку «Адресація» і під текстом «При введенні адреси шукати відповідні поштові адреси» позначте пункт «Сервери каталогів», вибравши ім'я вашої адресної книги.

Evolution

У репозиторіях ROSA також доступний поштовий клієнт Evolution(У цьому прикладі використовується версія 3.16.4).

Встановіть Evolution:

sudo urpmi evolution

Встановіть конектор Exchange, сумісний з версією 2007 та пізнішими:

sudo urpmi evolution-ews

Запустіть Evolution.

У вікні майстра натискайте кнопку [Наступна ], доки не перейдете на вкладку «Обліковий запис».
Заповніть поля «Повне ім'я» та «Електронна пошта».
На вкладці "Отримання пошти" у списку "Тип сервера" виберіть "Exchange Web Services".
Як ім'я вкажіть UPN-ім'я користувача у форматі «Ім'яКористувача@ВашДомен.ru».
У полі "Host URL" введіть "https://Ім'яПоштовогоСервераExchange/EWS/Exchange.asmx".
У полі OAB URL введіть URL автономної адресної книги.
Як вид аутентифікації виберіть «Basic».

При успішному налаштуванні програма запитає пароль:

Після введення пароля Evolutionотримає доступ до вашої поштової скриньки, адресної книги та календарів.

З будь-яких питань, пов'язаних із цією статтею, прохання звертатися за адресою [email protected].

Застосовується до: Exchange Server 2010 SP1

Остання модифікація розділу: 2011-04-22

У цьому розділі наведено відомості про порти, автентифікацію та шифрування для всіх шляхів до даних, які використовуються в Microsoft Exchange Server 2010. Розділ «Примітки» після кожної таблиці уточнює або визначає нестандартні способи автентифікації або шифрування.

Транспортні сервери

У системі Exchange 2010 є дві ролі сервера, які виконують функції транспортування повідомлень: транспортний сервер-концентратор та прикордонний транспортний сервер.

У наступній таблиці наведено відомості про порти, автентифікацію та шифрування шляхів до даних між цими транспортними серверами та іншими серверами та службами Exchange 2010.

Шляхи даних для транспортних серверів Шлях даних Необхідні порти Підтримка шифрування

Між двома транспортними серверами-концентраторами			Так, за допомогою TLS (Transport Layer Security)
З транспортного сервера-концентратора на прикордонний транспортний сервер	Пряма довіра	Пряма довіра	Так, з використанням TLS
З прикордонного транспортного сервера на транспортний сервер-концентратор	Пряма довіра	Пряма довіра	Так, з використанням TLS
Між двома прикордонними транспортними серверами	Анонімно, автентифікація за допомогою сертифіката	Анонімно за допомогою сертифіката	Так, з використанням TLS
З сервера поштових скриньок через службу надсилання пошти Microsoft Exchange	NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок виконуються на одному сервері, використовується протокол Kerberos.		Так, за допомогою шифрування RPC
З транспортного сервера-концентратора на сервер поштових скриньок через MAPI	NTLM. Якщо роль транспортного сервера-концентратора та роль сервера поштових скриньок встановлені на одному сервері, використовується протокол Kerberos.		Так, за допомогою шифрування RPC
			Так, з використанням TLS
Служба Microsoft Exchange EdgeSync із транспортного сервера-концентратора на прикордонний транспортний сервер			Так, за допомогою LDAP через SSL (LDAPS)
Доступ Служба каталогів Active Directory із транспортного сервера-концентратора
Доступ до служби керування правами Служба каталогів Active Directory (AD RMS) з транспортного сервера-концентратора			Так, за допомогою SSL
Клієнти SMTP на транспортний сервер-концентратор (наприклад, кінцеві користувачі за допомогою пошти Windows Live)			Так, з використанням TLS

Примітки для транспортних серверів

Весь трафік між транспортними серверами-концентраторами шифрується за допомогою протоколу TLS і сертифікатів, що самозавіряють, встановлених програмою установки Exchange 2010.
Весь трафік між прикордонними транспортними серверами та транспортними серверами-концентраторами проходить автентифікацію та шифрується. Як механізм автентифікації та шифрування використовується Mutual TLS. Замість перевірки X.509 у Exchange 2010 для автентифікації сертифікатів використовується пряма довіра. Пряма довіра означає, що наявність сертифіката в службах Служба каталогів Active Directory або в службах Active Directory полегшеного доступу до каталогів (AD LDS) підтверджує дійсність сертифіката. Служба каталогів Active Directory вважається довіреним механізмом зберігання. Коли використовується пряма довіра, не має значення, чи застосовується сертифікат, що самозавірює, або сертифікат, підписаний центром сертифікації. При підписці прикордонного транспортного сервера на організацію Exchange прикордонна підписка публікує сертифікат прикордонного транспортного сервера в службі каталогів Active Directory, щоб транспортні сервери-концентратори могли його перевіряти. Служба Microsoft Exchange EdgeSync додає до служб Active Directory полегшеного доступу до каталогів (AD LDS) набір сертифікатів транспортного сервера-концентратора, щоб прикордонний транспортний сервер перевірив їх.
EdgeSync використовує безпечне підключення LDAP транспортного сервера-концентратора до підписаних прикордонних транспортних серверів через порт TCP 50636. Служби Active Directory полегшеного доступу до каталогів також здійснюють прослуховування порту TCP 50389. Підключення до цього порту не використовує протокол SSL. Для підключення до цього порту та перевірки даних служб Active Directory полегшеного доступу до каталогів можна використовувати службові програми LDAP.
За промовчанням трафік між прикордонними транспортними серверами, розташованими у двох різних організаціях, шифрується. Програма установки Exchange 2010 створює сертифікат, що самозавіряє, і за замовчуванням включає TLS. Це дозволяє будь-якій відправляючій системі шифрувати сеанс SMTP, що входить в Exchange. За промовчанням, сервер Exchange 2010 також намагається використовувати протокол TLS для всіх віддалених підключень.
Способи автентифікації для трафіку між транспортними серверами-концентраторами та серверами поштових скриньок відрізняються, якщо ролі транспортного сервера-концентратора та сервера поштових скриньок встановлені на одному комп'ютері. При локальній передачі пошти використовується автентифікація Kerberos. Під час віддаленої передачі пошти використовується автентифікація NTLM.
Exchange 2010 також підтримує безпеку домену. Безпека домену – це набір функцій Exchange 2010 та Microsoft Outlook 2010, які є недорогою альтернативою S/MIME та іншим рішенням для забезпечення безпеки передачі повідомлень через Інтернет. Безпека домену забезпечує спосіб керування безпечними шляхами надсилання повідомлень між доменами в Інтернеті. Після налаштування таких безпечних шляхів успішно передані по них повідомлення від відправника, що пройшов автентифікацію, відображаються для користувачів Outlook і Outlook Web Access як повідомлення, «захищені на рівні домену». Щоб отримати додаткові відомості, див. Загальні відомості про безпеку домену.
Багато агентів можуть виконуватися як у транспортних серверах-концентраторах, і на прикордонних транспортних серверах. Як правило, агенти захисту від небажаної пошти використовують відомості локального комп'ютера, на якому вони виконуються. Таким чином, практично не потрібна взаємодія з віддаленими комп'ютерами. Винятком є фільтрація одержувачів. Для фільтрації одержувачів потрібний виклик AD LDS або Служба каталогів Active Directory. Фільтрацію одержувачів рекомендується виконувати на прикордонному транспортному сервері. У цьому випадку каталог AD LDS знаходиться на тому ж комп'ютері, на якому встановлена роль прикордонного транспортного сервера, тому віддалене підключення не потрібне. Якщо функція фільтрації одержувачів встановлена та налаштована на транспортному сервері-концентраторі, необхідний доступ до служби каталогів Active Directory.
Агент аналізу протоколу використовується функцією репутації відправника Exchange 2010. Цей агент також підключається до різних зовнішніх проксі-серверів, щоб визначити шляхи вхідних повідомлень для підозрілих підключень.
Всі інші функції захисту від небажаної пошти використовують дані, які збираються, зберігаються та доступні лише на локальному комп'ютері. Зазвичай такі дані, як об'єднаний список надійних відправників або дані одержувачів для фільтрації одержувачів, примусово надсилаються до локального каталогу AD LDS за допомогою служби Microsoft Exchange EdgeSync.
Агенти управління правами на доступ до даних (IRM) на транспортних серверах-концентраторах виконують підключення до серверів служб управління правами Active Directory (AD RMS) в організації. Служба керування правами Active Directory (AD RMS) – це веб-служба, яку рекомендується захищати за допомогою SSL. Підключення до серверів служб керування правами Active Directory виконується за допомогою HTTPS, а для автентифікації використовується Kerberos або NTLM залежно від конфігурації сервера служб керування правами Active Directory.

Правила журналів, правила транспорту та класифікації повідомлень зберігаються у службах Служба каталогів Active Directory, і доступ до них здійснює агент ведення журналу та агент правил транспорту на транспортних серверах-концентраторах. Сервери поштових скриньок

На серверах поштових скриньок використання автентифікації NTLM або Kerberos залежить від контексту користувача або процесу, в рамках якого працює споживач рівня бізнес-логіки Exchange. У такому контексті споживачами є будь-які програми чи процеси, які використовують рівень бізнес-логіки Exchange. У стовпці Перевірка автентичності за умовчанням таблиці Шляхи до даних для серверів поштових скриньок для багатьох рядків вказано значення NTLM/Kerberos .

Рівень бізнес-логіки Exchange використовується для доступу до сховища Exchange та взаємодії з ним. Рівень бізнес-логіки Exchange також викликається зі сховища Exchange для взаємодії із зовнішніми програмами та процесами.

Якщо споживач рівня бізнес-логіки Exchange виконується в контексті локальної системи, способом автентифікації при доступі споживача до сховища Exchange завжди є Kerberos. Спосіб автентифікації Kerberos використовується через те, що справжність одержувача необхідно перевіряти з використанням облікового записукомп'ютера "Локальна система", а також потрібна двостороння довіра з автентифікацією.

Якщо одержувач рівня бізнес-логіки Exchange виконується не в контексті локальної системи, способом автентифікації є NTLM. Наприклад, коли адміністратор запускає командлет командної консолі Exchange, що використовує рівень бізнес-логіки 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)				Так, за допомогою SSL
Сервер клієнтського доступу до сервера клієнтського доступу (POP3)				Так, за допомогою SSL
Сервер клієнтського доступу до сервера клієнтського доступу (IMAP4)				Так, за допомогою SSL
Сервер Office Communications Server до сервера клієнтського доступу (коли включена інтеграція Office Communications Server та Outlook Web App)	5075-5077/TCP (ВХІД), 5061/TCP (ВИХІД)	mTLS (обов'язково)	mTLS (обов'язково)	Так, за допомогою SSL

Примітки для серверів клієнтського доступу Сервери єдиної системи обміну повідомленнями

Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують лише автентифікацію за допомогою сертифіката, при якій використовується автентифікація Mutual TLS для шифрування трафіку SIP та автентифікація на основі IP-адреси для підключень за протоколами SIP або TCP. Шлюзи IP не підтримують автентифікацію NTLM і Kerberos. Таким чином, при використанні автентифікації на основі IP-адреси в якості механізму автентифікації для незашифрованих підключень (TCP) використовуються IP-адреси підключень. При використанні в єдиній системі обміну повідомленнями автентифікації на основі IP-адрес перевіряє, чи дозволено цій IP-адресі підключатися. IP-адреса настроюється на шлюзі IP або IP PBX.

Шлюзи IP та УВАТС, що працюють за протоколом IP, підтримують Mutual TLS для шифрування трафіку SIP. Після успішного імпорту та експорту необхідних довірених сертифікатів шлюз IP або УВАТС, що працює за протоколом IP, запитуватиме сертифікат у сервера єдиної системи обміну повідомленнями, а потім запитуватиме сертифікат у шлюзу IP або УВАТС, що працює за протоколом IP. Обмін довіреними сертифікатами між шлюзом IP або УВАТС, що працює за протоколом IP, та сервером єдиної системи обміну повідомленнями дозволяє обом пристроям взаємодіяти безпечним каналом за допомогою 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)	5060/TCP , 5065/TCP, 5067/TCP (у незахищеному режимі), 5061/TCP, 5066/TCP, 5068/TCP (у захищеному режимі), динамічний порт з діапазону 16000-17000/TCP (управління) з діапазону 1024-65535/UDP (RTP)	За IP-адресою	За IP-адресою, MTLS	Так, за допомогою SIP/TLS, SRTP
Веб-служба єдиної системи обміну повідомленнями	80/TCP, 443/TCP (SSL)	Інтегрована автентифікація Windows (Negotiate)		Так, за допомогою SSL
Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу	5075, 5076, 5077 (TCP)	Вбудована автентифікація Windows (узгодження)	Звичайна, дайджест-автентифікація, NTLM, узгодження (Kerberos)	Так, за допомогою SSL
Із сервера єдиної системи обміну повідомленнями на сервер клієнтського доступу (відтворення на телефоні)	Динамічний RPC			Так, за допомогою шифрування RPC
Із сервера єдиної системи обміну повідомленнями на транспортний сервер-концентратор				Так, з використанням TLS
З сервера єдиної системи обміну повідомленнями на сервер поштових скриньок				Так, за допомогою шифрування RPC

Примітки для серверів єдиної системи обміну повідомленнями

При створенні об'єкта шлюзу IP єдиної системи обміну повідомленнями в Службі каталогів Active Directory необхідно визначити IP-адресу фізичного шлюзу IP або УВАТС, що працює за протоколом IP. При визначенні IP-адреси об'єкта шлюзу IP єдиної системи обміну повідомленнями IP-адреса додається до списку допустимих шлюзів IP або УВАТС, що працюють за протоколом IP (також званими учасниками SIP-сеансу), з якими можна взаємодіяти серверу єдиної системи обміну повідомленнями. Після створення шлюзу IP єдиної системи обміну повідомленнями, можна зв'язати його з абонентською групою цієї системи. Зіставлення шлюзу IP єдиної системи обміну повідомленнями з абонентською групою дозволяє серверам єдиної системи обміну повідомленнями, зіставленим з абонентською групою, використовувати автентифікацію на основі IP-адреси для взаємодії зі шлюзом IP. Якщо шлюз IP єдиної системи обміну повідомленнями не був створений або не був налаштований на використання правильної IP-адреси, то відбудеться збій автентифікації, і сервери єдиної системи обміну повідомленнями не прийматимуть підключення з IP-адреси даного шлюзу IP. Крім того, при реалізації Mutual TLS, шлюзу IP або УВАТС, що працює за протоколом IP, та серверів єдиної системи обміну повідомленнями, шлюз IP єдиної системи обміну повідомленнями необхідно налаштувати на використання повного доменного імені (FQDN). Після налаштування шлюзу 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)		Динамічний RPC	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (вхідний TCP)	Сервер клієнтського доступу, транспортний сервер-концентратор, прикордонний транспортний сервер, сервер єдиної системи обміну повідомленнями	Динамічний RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (вхідний TCP)		Динамічний RPC	Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (вхідний TCP)			Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (вхідний TCP)
MSExchangeRPC (GFW) (вхідний TCP)	Сервер клієнтського доступу, транспортний сервер-концентратор, сервер поштових скриньок, сервер єдиної системи обміну повідомленнями	Динамічний RPC
MSExchange - IMAP4 (GFW) (вхідний TCP)	Сервер клієнтського доступу
MSExchangeIMAP4 (вхідний TCP)	Сервер клієнтського доступу		ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (вхідний TCP)	Сервер клієнтського доступу
MSExchange - POP3 (вхідний TCP)	Сервер клієнтського доступу		ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (вхідний TCP)	Сервер клієнтського доступу	5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (вхідний TCP)	Сервер клієнтського доступу	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
MSExchangeAB RPC (вхідний TCP)	Сервер клієнтського доступу	Динамічний RPC
MSExchangeAB-RPCEPMap (вхідний TCP)	Сервер клієнтського доступу		Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (вхідний TCP)	Сервер клієнтського доступу	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (вхідний TCP)	Сервер клієнтського доступу	Динамічний RPC	System32\Svchost.exe
MSExchangeRPC - RPC (вхідний TCP)		Динамічний RPC
MSExchangeRPC - PRCEPMap (вхідний TCP)	Сервер клієнтського доступу, сервер поштових скриньок		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (вхідний TCP)	Сервер клієнтського доступу, сервер поштових скриньок		Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (вхідний TCP)	Сервер клієнтського доступу
MSExchangeMailboxReplication (вхідний TCP)	Сервер клієнтського доступу		Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP-вхідний)	Сервер поштових скриньок	Динамічний RPC
MSExchangeIS RPCEPMap (вхідний TCP)	Сервер поштових скриньок
MSExchangeIS (GFW) (вхідний TCP)	Сервер поштових скриньок	6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (вхідний TCP)	Сервер поштових скриньок
MSExchangeMailboxAssistants - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC
MSExchangeMailboxAssistants - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC
MSExchangeMailSubmission - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeMigration.exe
MSExchangerepl - Log Copier (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (вхідний TCP)	Сервер поштових скриньок	Динамічний RPC	Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (вхідний TCP)	Сервер поштових скриньок		Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP-вхідний)	Сервер поштових скриньок	Динамічний RPC
MSFTED - RPCEPMap (TCP-вхідний)	Сервер поштових скриньок
MSExchangeEdgeSync - RPC (вхідний TCP)	Транспортний сервер-концентратор	Динамічний RPC
MSExchangeEdgeSync RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор		Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (вхідний TCP)	Транспортний сервер-концентратор	Динамічний RPC	Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор		Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (вхідний TCP)	Транспортний сервер-концентратор
MSExchangeTransportWorker (вхідний TCP)	Транспортний сервер-концентратор		Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (вхідний TCP)		Динамічний RPC
MSExchangeTransportLogSearch - RPCEPMap (вхідний TCP)	Транспортний сервер-концентратор, прикордонний транспортний сервер, сервер поштових скриньок		Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями
SESWorker (вхідний TCP)	Сервер єдиної системи обміну повідомленнями		UnifiedMessaging\SESWorker.exe
UMService (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями
UMService (вхідний TCP)	Сервер єдиної системи обміну повідомленнями		Bin\UMService.exe
UMWorkerProcess (GFW) (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	5065, 5066, 5067, 5068
UMWorkerProcess (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (вхідний TCP)	Сервер єдиної системи обміну повідомленнями	Динамічний RPC	Bin\UMWorkerProcess.exe

Примітки до правил брандмауера Windows, створених програмою інсталяції Exchange 2010

На серверах із встановленими службами IIS Windows відкриває порти HTTP (порт 80, TCP) та HTTPS (порт 443, TCP). Програма інсталяції Exchange 2010 не відкриває ці порти. Отже, ці порти не наведені у попередній таблиці.
У Windows Server 2008 та Windows Server 2008 R2 брандмауер Windows у режимі підвищеної безпеки дозволяє вказати процес або службу, для яких відкритий порт. Це безпечніше, оскільки порт може використовуватися лише процесом чи службою, зазначеної у правилі. Програма інсталяції Exchange створює правила брандмауера із зазначеним ім'ям процесу. У деяких випадках з метою сумісності також створюється додаткове правило, не обмежене цим процесом. Можна вимкнути або видалити правила, не обмежені процесами, та зберегти відповідні правила, обмежені процесами, якщо поточне середовище розгортання підтримує їх. Правила, які не обмежені процесами, можна відрізнити за словом (GFW) в імені правила.
Багато служб Exchange використовують для взаємодії віддалені дзвінки процедур (RPC). Серверні процеси, що використовують віддалені виклики процедур, підключаються до співставника кінцевих точок RPC для отримання динамічних кінцевих точок та реєстрації їх у базі даних зіставника кінцевих точок. Клієнти RPC взаємодіють із співставником кінцевих точок RPC для визначення кінцевих точок, що використовуються серверним процесом. За промовчанням співставник кінцевих точок RPC прослуховує порт 135 (TCP). При налаштуванні брандмауера Windows для процесу, що використовує віддалені дзвінки процедур, програма інсталяції Exchange 2010 створює для цього процесу два правила брандмауера. Одне правило дозволяє взаємодію із співставником кінцевих точок RPC, а друге дозволяє взаємодію з динамічно призначеною кінцевою точкою. Для отримання додаткових відомостей про віддалені дзвінки процедур див. статтю . Для отримання додаткових відомостей про створення правил брандмауера Windows для динамічного віддаленого виклику процедур див.
Додаткові відомості див. у статті 179442 бази знань Microsoft

Популярне в рубриці: