W tym artykule dowiemy się, jak skonfigurować statyczne porty RPC dla usług dostępu klienta RPC, książki adresowej programu Exchange i dostępu do folderów publicznych w programie Exchange 2010.
Wyobraźmy sobie, że mamy złożoną organizację z systemem Exchange Server 2010 SP1 (lub nowszym), która ma również platformę . Serwery CAS są zwykle zlokalizowane w sieci oddzielonej zaporami ogniowymi od sieci, z których użytkownicy mają uzyskiwać dostęp (sieci programu Outlook). Połączenie klienta Outlooka z serwerem CAS odbywa się za pośrednictwem RPC, co oznacza, że wł Warstwa sieci można użyć dowolnego portu w wolnym zakresie portów. Nie jest tajemnicą, że w serwer Windowsa 2008 i 2008 R2 używają 49152-65535 jako dynamicznego zakresu portów dla połączeń RPC (poprzednie Wersje Windowsa Serwer używał portów RPC z zakresu 1025-65535).
Aby zapory ogniowe nie stały się „przesiewaczem”, pożądane jest zawężenie zakresu używanych portów RPC, najlepiej poprzez uczynienie ich statycznymi na każdym serwerze Client Access Server w macierzy Client Access. Dodatkowo zastosowanie statycznych portów RPC pozwala na zmniejszenie zużycia pamięci na load balancerach (zwłaszcza HLB) oraz uproszczenie ich konfiguracji (brak konieczności określania dużych zakresów portów).
W programie Exchange 2010 usługa dostępu klienta RPC oraz książka adresowa programu Exchange mogą być ustawione na porty statyczne. Outlook komunikuje się z tymi usługami poprzez interfejs MAPI.
Port statyczny dla usługi dostępu klienta Exchange 2010 RPC
Usługa wirtualna programu Exchange 2010 RPC Client Access jest powiązana z usługą RPC Client Access, z którą łączą się klienci Outlook MAPI w programie Exchange 2010. Gdy klient programu Outlook łączy się z programem Exchange na serwerze dostępu klienta programu Exchange 2010, usługa dostępu klienta RPC używa portu TCP End Point Mapper (TCP/135) i losowego portu z dynamicznego zakresu portów RPC (6005-59530) dla połączeń przychodzących znajomości
Aby ustawić statyczny port dla usługi RPC Client Access w Exchange 2010, musisz otworzyć sekcję w edytorze rejestru:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\usługi\MSExchangeRPC
Utwórz nowy klucz o nazwie ParametrySystem, wewnątrz którego utwórz parametr typu REG_DWORD Z imieniem portu TCP/IP. Ustawienie portu TCP/IP określa port statyczny dla usługi dostępu klienta RPC. Dokumentacja Microsoft zaleca wybranie portu z zakresu 59531 - 60554 i używanie tej wartości na wszystkich serwerach CAS (podaliśmy oczywiście port 59532, nie powinien on być używany przez żadne inne oprogramowanie).
Po przypisaniu portów statycznych należy ponownie uruchomić usługę Microsoft Exchange RPC Client Access, aby zmiany zaczęły obowiązywać.
Uruchom ponownie usługę MSExchangeRPC
Port statyczny dla usługi książki adresowej programu Exchange 2010
W wersjach wcześniejszych niż SP1 program Exchange 2010 używał specjalnego pliku konfiguracyjnego do ustawiania statycznego portu usługi Książka adresowa programu Exchange 2010 Microsoft.exchange.addressbook.service.exe.config. Po wydaniu Exchange 2010 SP1 można ustawić statyczny port tej usługi za pomocą rejestru. Aby to zrobić, otwórz edytor rejestru i przejdź do oddziału:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters
Utwórz nowy parametr RpcTcpPort(typu REG_SZ) i nadaj mu numer portu, który chcesz naprawić dla usługi Exchange Address Book. Zaleca się użycie dowolnego wolnego portu z zakresu 59531-60554, a następnie użycie go na wszystkich serwerach Exchange 2010 Client Access w domenie. Ustawimy RpcTcpPort=59533
Następnie musisz ponownie uruchomić usługę książki adresowej Microsoft Exchange
Uruchom ponownie usługę MSExchangeAB
Ważny: Podczas migracji z Exchange 2010 RTM do SP1 klucz ten należy ustawić ręcznie, nie jest on dziedziczony automatycznie.
Konfigurowanie statycznego portu do łączenia się z udostępnionymi folderami
Dostęp do folderów publicznych można uzyskać z klienta programu Outlook bezpośrednio za pośrednictwem usługi dostępu klienta RPC na serwerze z rolą skrzynki pocztowej. To ustawienie należy przeprowadzić na wszystkich serwerach z rolą Mailbox, które zawierają bazę danych udostępnione foldery(podobnie jak serwery CAS). Otwórz edytor rejestru i przejdź do oddziału
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\usługi\MSExchangeRPC
Utwórz nowy klucz o nazwie ParametrySystem, wewnątrz którego utwórz parametr typu REG_DWORD o nazwie portu TCP/IP. Ustaw jego wartość: Port TCP/IP = 59532.
Po statycznym ustawieniu portu folderu publicznego należy ponownie uruchomić usługę Microsoft Exchange RPC Client Access na każdym serwerze skrzynki pocztowej.
Sprawdź użycie portów statycznych między programami Outlook i Exchange 2010
Po wprowadzeniu zmian sprawdź, czy program Outlook łączy się ze wskazanymi statycznymi portami RPC. Aby to zrobić, na komputerze klienckim uruchom ponownie program Outlook, a następnie w wiersz poleceń uruchom polecenie:
Netstat - nie
Stosuje się do: Serwer Exchange 2010 SP1
Ostatnia modyfikacja sekcji: 2011-04-22
Ta sekcja zawiera informacje o portach, uwierzytelnianiu i szyfrowaniu dla wszystkich ścieżek danych używanych w programie Microsoft Exchange Server 2010. Sekcja „Uwagi” po każdej tabeli wyjaśnia lub definiuje niestandardowe metody uwierzytelniania lub szyfrowania.
Serwery transportowe
W Exchange 2010 istnieją dwie role serwera realizujące funkcje transportu wiadomości: serwer Hub Transport i serwer Edge Transport.
Poniższa tabela zawiera informacje o portach, uwierzytelnianiu i szyfrowaniu ścieżek danych między tymi serwerami transportowymi a innymi serwerami i usługami programu Exchange 2010.
Ścieżki danych dla serwerów transportowych
| Ścieżka danych | Wymagane porty | Obsługa szyfrowania | |||
|---|---|---|---|---|---|
|
Między dwoma serwerami Hub Transport |
Tak, z TLS (Transport Layer Security) |
||||
|
Z serwera Hub Transport do serwera Edge Transport |
bezpośrednie zaufanie |
bezpośrednie zaufanie |
Tak, przy użyciu TLS |
||
|
Z serwera Edge Transport do serwera Hub Transport |
bezpośrednie zaufanie |
bezpośrednie zaufanie |
Tak, przy użyciu TLS |
||
|
Między dwoma serwerami Edge Transport |
Anonimowy, uwierzytelnianie za pomocą certyfikatu |
Anonimowo, z certyfikatem |
Tak, przy użyciu TLS |
||
|
Z serwera skrzynki pocztowe za pośrednictwem usługi wysyłkowej Poczta Microsoftu Giełda |
NTLM. Jeśli rola serwera Hub Transport i rola serwera skrzynki pocztowej są uruchomione na tym samym serwerze, używany jest protokół Kerberos. |
Tak, przy użyciu szyfrowania RPC |
|||
|
Z serwera Hub Transport do serwera Mailbox przez MAPI |
NTLM. Jeśli rola serwera Hub Transport i rola serwera skrzynki pocztowej są zainstalowane na tym samym serwerze, używany jest protokół Kerberos. |
Tak, przy użyciu szyfrowania RPC |
|||
|
Tak, przy użyciu TLS |
|||||
|
Usługa Microsoft Exchange EdgeSync z serwera Hub Transport do serwera Edge Transport |
Tak, używając protokołu LDAP przez SSL (LDAPS) |
||||
|
Uzyskaj dostęp do Active Directory z serwera Hub Transport |
|||||
|
Uzyskiwanie dostępu do usługi zarządzania prawami dostępu w usłudze Active Directory (AD RMS) z serwera Hub Transport |
Tak, z SSL |
||||
|
klientów SMTP do serwera Hub Transport (na przykład użytkownicy końcowi korzystający z usługi Windows Live Mail) |
Tak, przy użyciu TLS |
Uwagi dotyczące serwerów transportowych
- Cały ruch między serwerami Hub Transport jest szyfrowany przy użyciu Transport Layer Security (TLS) i samopodpisanych certyfikatów instalowanych przez Instalatora Exchange 2010.
- Cały ruch między serwerami Edge Transport i serwerami Hub Transport jest uwierzytelniany i szyfrowany. Wzajemny TLS jest używany jako mechanizm uwierzytelniania i szyfrowania. Zamiast sprawdzania poprawności X.509 Exchange 2010 używa bezpośrednie zaufanie. Zaufanie bezpośrednie oznacza, że obecność certyfikatu w usługach Active Directory lub Active Directory Lightweight Directory Services (AD LDS) weryfikuje autentyczność certyfikatu. Usługa katalogowa Active Directory jest uważana za zaufany mechanizm przechowywania. Gdy używane jest zaufanie bezpośrednie, nie ma znaczenia, czy używany jest certyfikat z podpisem własnym, czy certyfikat podpisany przez urząd certyfikacji. Gdy subskrybujesz serwer Edge Transport w organizacji Exchange, subskrypcja Edge Subscription publikuje certyfikat serwera Edge Transport w usłudze katalogowej Active Directory, aby serwery Hub Transport mogły go zweryfikować. Usługa Microsoft Exchange EdgeSync dodaje zestaw certyfikatów serwera Hub Transport do Active Directory Lightweight Directory Services (AD LDS), aby serwer Edge Transport mógł je zweryfikować.
- EdgeSync używa bezpiecznego połączenia LDAP z serwera Hub Transport do subskrybowanych serwerów Edge Transport na porcie TCP 50636. Active Directory Lightweight Directory Services nasłuchuje również na porcie TCP 50389. Połączenia z tym portem nie używają protokołu SSL. Możesz użyć narzędzi LDAP, aby połączyć się z tym portem i sprawdzić dane AD LDS.
- Domyślnie ruch między serwerami Edge Transport znajdującymi się w dwóch różnych organizacjach jest szyfrowany. Instalator programu Exchange 2010 tworzy certyfikat z podpisem własnym i domyślnie włącza protokół TLS. Umożliwia to dowolnemu systemowi wysyłającemu szyfrowanie przychodzącej sesji SMTP do programu Exchange. Domyślnie Exchange 2010 próbuje również używać TLS dla wszystkich połączeń zdalnych.
- Metody uwierzytelniania dla ruchu między serwerami Hub Transport i serwerami Mailbox różnią się, gdy role serwera Hub Transport i Mailbox są zainstalowane na tym samym komputerze. Lokalny transfer poczty wykorzystuje uwierzytelnianie Kerberos. Zdalny transfer poczty wykorzystuje uwierzytelnianie NTLM.
- Exchange 2010 obsługuje również zabezpieczenia domeny. Domain Security to zestaw funkcji programów Exchange 2010 i Microsoft Outlook 2010, które stanowią niedrogą alternatywę dla S/MIME i innych rozwiązań zabezpieczających wiadomości internetowe. Zabezpieczenia domeny zapewniają sposób zarządzania bezpiecznymi ścieżkami komunikacji między domenami w Internecie. Po skonfigurowaniu tych bezpiecznych ścieżek wiadomości pomyślnie wysłane za ich pośrednictwem od uwierzytelnionego nadawcy są wyświetlane użytkownikom programów Outlook i Outlook Web Access jako wiadomości „chronione na poziomie domeny”. Aby uzyskać więcej informacji, zobacz Omówienie zabezpieczeń domeny.
- Wielu agentów może działać zarówno na serwerach Hub Transport, jak i Edge Transport. Zwykle środki ochrony niechciana poczta korzystać z informacji komputer lokalny na których są wykonywane. Tak więc interakcja z zdalne komputery. Wyjątkiem jest filtrowanie odbiorców. Filtrowanie adresatów wymaga wywołania AD LDS lub Active Directory. Zalecamy przeprowadzenie filtrowania adresatów na serwerze Edge Transport. W takim przypadku katalog usług AD LDS znajduje się na tym samym komputerze, na którym zainstalowano rolę serwera Edge Transport, więc połączenie zdalne nie jest wymagane. Jeśli filtrowanie adresatów jest zainstalowane i skonfigurowane na serwerze Hub Transport, wymagany jest dostęp do usługi katalogowej Active Directory.
- Agent analizy protokołów jest używany przez funkcję Sender Reputation w programie Exchange 2010. Agent ten łączy się również z różnymi zewnętrznymi serwerami proxy w celu określenia ścieżek wiadomości przychodzących dla podejrzanych połączeń.
- Wszystkie inne funkcje antyspamowe wykorzystują dane, które są gromadzone, przechowywane i dostępne tylko na komputerze lokalnym. Zazwyczaj dane, takie jak połączona lista bezpiecznych nadawców lub dane adresatów do filtrowania adresatów, są wypychane do lokalnego katalogu AD LDS przy użyciu usługi Microsoft Exchange EdgeSync.
- Agenci zarządzania prawami do informacji (IRM) na serwerach Hub Transport łączą się z serwerami Active Directory Rights Management Services (AD RMS) w organizacji. Usługa zarządzania prawami dostępu w usłudze Active Directory (AD RMS) to usługa internetowa, którą zalecamy zabezpieczyć za pomocą protokołu SSL. Połączenia z serwerami AD RMS są nawiązywane przy użyciu protokołu HTTPS i są uwierzytelniane przy użyciu protokołu Kerberos lub NTLM, w zależności od konfiguracji serwera AD RMS.
- Reguły rejestrowania, reguły transportu i reguły klasyfikacji wiadomości są przechowywane w usłudze Active Directory i dostępne dla agenta rejestrowania i agenta zasad transportu na serwerach Hub Transport.
Serwery skrzynek pocztowych
Na serwerach skrzynek pocztowych to, czy używane jest uwierzytelnianie NTLM czy Kerberos, zależy od kontekstu użytkownika lub procesu, w ramach którego działa konsument warstwy logiki biznesowej programu Exchange. W tym kontekście konsumentami są wszelkie aplikacje lub procesy korzystające z warstwy logiki biznesowej programu Exchange. W rezultacie w kolumnie Uwierzytelnianie domyślne stoły Ścieżki danych dla serwerów Mailbox wiele wierszy ma wartość NTLM/Kerberos.
Warstwa logiki biznesowej programu Exchange służy do uzyskiwania dostępu do magazynu programu Exchange i interakcji z nim. Warstwa logiki biznesowej Exchange jest również wywoływana ze sklepu Exchange w celu interakcji z zewnętrznymi aplikacjami i procesami.
Gdy konsument warstwy logiki biznesowej programu Exchange działa w kontekście systemu lokalnego, metodą uwierzytelniania konsumenta w celu uzyskania dostępu do magazynu programu Exchange jest zawsze Kerberos. Używana jest metoda uwierzytelniania Kerberos, ponieważ odbiorca musi zostać uwierzytelniony za pomocą konto komputer „System lokalny” i wymaga dwukierunkowego zaufania z uwierzytelnianiem.
Jeśli odbiorca warstwy logiki biznesowej programu Exchange nie działa w kontekście systemu lokalnego, metodą uwierzytelniania jest NTLM. Na przykład, gdy administrator uruchamia polecenie cmdlet Exchange Management Shell, które używa warstwy logiki biznesowej programu Exchange, używane jest uwierzytelnianie NTLM.
Ruch RPC jest zawsze szyfrowany.
Poniższa tabela zawiera informacje o portach, uwierzytelnianiu i szyfrowaniu ścieżek danych dla serwerów Mailbox.
Ścieżki danych dla serwerów Mailbox
Ścieżka danych Wymagane porty Uwierzytelnianie domyślne Obsługiwana metoda uwierzytelniania Obsługa szyfrowania Domyślne szyfrowanie danych 389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (logowanie do sieci RPC)
Tak, przy użyciu szyfrowania Kerberos
Zdalny dostęp administracyjny (zdalny rejestr)
Tak, przy użyciu protokołu IPsec
Zdalny dostęp administracyjny (SMB, pliki)
Tak, przy użyciu protokołu IPsec
Usługa internetowa dostępności (dostęp do skrzynki pocztowej klienta)
Tak, przy użyciu szyfrowania RPC
Grupowanie
Tak, przy użyciu szyfrowania RPC
Między serwerami Client Access (Exchange ActiveSync)
80/TCP, 443/TCP (SSL)
Kerberos, uwierzytelnianie certyfikatu
Tak, używając HTTPS
Tak, przy użyciu samopodpisanego certyfikatu
Między serwerami Client Access (Outlook Web Access)
80/TCP, 443/TCP (HTTPS)
Tak, z SSL
Serwer dostępu klienta do serwera dostępu klienta (usługi internetowe programu Exchange)
Tak, z SSL
Serwer dostępu klienta do serwera dostępu klienta (POP3)
Tak, z SSL
Serwer dostępu klienta do serwera dostępu klienta (IMAP4)
Tak, z SSL
Office Communications Server do serwera Client Access (gdy włączona jest integracja Office Communications Server i Outlook Web App)
5075-5077/TCP (wejście), 5061/TCP (wyjście)
mTLS (wymagane)
mTLS (wymagane)
Tak, z SSL
Uwagi dotyczące serwerów Client Access
Serwery ujednolicony system wiadomości
Bramy IP i centrale IP PBX obsługują tylko uwierzytelnianie za pomocą certyfikatów, które wykorzystuje wzajemne uwierzytelnianie TLS do szyfrowania ruchu SIP i uwierzytelnianie oparte na adresach IP dla połączeń SIP lub TCP. Bramy IP nie obsługują uwierzytelniania NTLM i Kerberos. Dlatego podczas korzystania z uwierzytelniania opartego na adresie IP mechanizm uwierzytelniania dla połączeń nieszyfrowanych (TCP) wykorzystuje adresy IP połączeń. Uwierzytelnianie oparte na adresie IP, używane w Unified Messaging, sprawdza, czy dany adres IP może się łączyć. Adres IP jest konfigurowany na bramce IP lub IP PBX.
Bramy IP i centrale IP PBX obsługują protokół Mutual TLS w celu szyfrowania ruchu SIP. Po pomyślnym zaimportowaniu i wyeksportowaniu niezbędnych zaufanych certyfikatów brama IP lub IP PBX zażąda certyfikatu od serwera Unified Messaging, a następnie zażąda certyfikatu od bramy IP lub IP PBX. Wymiana zaufanych certyfikatów między bramą IP lub IP PBX a serwerem Unified Messaging umożliwia obu urządzeniom bezpieczną komunikację przy użyciu wzajemnego protokołu TLS.
Poniższa tabela zawiera informacje o porcie, uwierzytelnianiu i szyfrowaniu dla ścieżek danych między serwerami UM a innymi serwerami.
Ścieżki danych dla serwerów Unified Messaging
Ścieżka danych Wymagane porty Uwierzytelnianie domyślne Obsługiwana metoda uwierzytelniania Obsługa szyfrowania Domyślne szyfrowanie danych Dostęp do Active Directory
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (logowanie do sieci RPC)
Tak, przy użyciu szyfrowania Kerberos
Połączenie telefoniczne UM (IP PBX/bramka VoIP)
5060/TCP , 5065/TCP, 5067/TCP (w trybie niezabezpieczonym), 5061/TCP, 5066/TCP, 5068/TCP (w trybie bezpiecznym), dynamiczny zakres portów 16000-17000/TCP (zarządzanie), dynamiczny UDP porty z zakresu 1024-65535/UDP (RTP)
Według adresu IP
Według adresu IP, MTLS
Tak, przy użyciu SIP/TLS, SRTP
Serwis internetowy UM
80/TCP, 443/TCP (SSL)
Zintegrowane uwierzytelnianie systemu Windows (negocjuj)
Tak, z SSL
Z serwera Unified Messaging do serwera Client Access
5075, 5076, 5077 (TCP)
Zintegrowane uwierzytelnianie systemu Windows (negocjuj)
Podstawowy, skrót, NTLM, negocjowanie (Kerberos)
Tak, z SSL
Serwer UM do serwera dostępu klienta (odtwarzanie na telefonie)
Dynamiczne RPC
Tak, przy użyciu szyfrowania RPC
Z serwera Unified Messaging do serwera Hub Transport
Tak, przy użyciu TLS
Z serwera Unified Messaging do serwera skrzynki pocztowej
Tak, przy użyciu szyfrowania RPC
Uwagi dotyczące serwerów Unified Messaging
- Podczas tworzenia obiektu bramy UM IP w usłudze Active Directory należy zdefiniować adres IP fizycznej bramy IP lub centrali IP PBX. Po określeniu adresu IP obiektu bramy UM IP adres IP jest dodawany do listy prawidłowych bram IP lub central IP PBX (znanych również jako uczestnicy sesji SIP), z którymi serwer UM może się komunikować. Po utworzeniu bramy UM IP można powiązać ją z planem wybierania numerów UM. Mapowanie bramy UM IP na plan wybierania numerów umożliwia serwerom UM mapowanym na plan wybierania numerów używanie uwierzytelniania opartego na adresie IP do komunikacji z bramą IP. Jeśli brama UM IP nie została utworzona lub skonfigurowana do korzystania z prawidłowego adresu IP, uwierzytelnianie zakończy się niepowodzeniem, a serwery UM nie będą akceptować połączeń z adresu IP tej bramy IP. Ponadto, jeśli implementujesz protokół Mutual TLS, bramę IP lub IP PBX oraz serwery Unified Messaging, brama UM IP musi być skonfigurowana do używania w pełni kwalifikowanej nazwy domeny (FQDN). Po skonfigurowaniu bramy UM IP przy użyciu nazwy FQDN należy również dodać rekord hosta dla bramy do strefy wyszukiwania DNS do przodu.
- W programie Exchange 2010 serwer Unified Messaging może komunikować się przez port 5060/TCP (niezabezpieczony) lub port 5061/TCP (bezpieczny) i można go skonfigurować do korzystania z obu portów.
Aby uzyskać więcej informacji, zobacz Zrozumienie zabezpieczeń UM VoIP i Zrozumienie protokołów, portów i usług w ujednoliconej komunikacji .
Zasady Zapora systemu Windows utworzone przez Instalatora programu Exchange 2010
Zapora systemu Windows z zabezpieczeniami zaawansowanymi to stanowa zapora komputerowa, która filtruje ruch przychodzący i wychodzący na podstawie reguł zapory. Instalator programu Exchange 2010 tworzy reguły Zapory systemu Windows w celu otwarcia portów wymaganych do komunikacji serwera i klienta w każdej roli serwera. W związku z tym nie trzeba już używać SCW do konfigurowania tych ustawień. Aby uzyskać więcej informacji na temat Zapory systemu Windows z zabezpieczeniami zaawansowanymi, zobacz Zapora systemu Windows z zabezpieczeniami zaawansowanymi i protokołem IPsec.
Poniższa tabela zawiera listę reguł Zapory systemu Windows, generowane przez program Instalacje programu Exchange, w tym porty otwarte w każdej roli serwera. Reguły te można przeglądać za pomocą przystawki Zapora systemu Windows z zaawansowanymi zabezpieczeniami programu MMC.
Nazwa reguły Role serwera Port Program MSExchangeADTopology — RPC (przychodzące TCP)
Dynamiczne RPC
Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring — RPC (przychodzące TCP)
Serwer Client Access, serwer Hub Transport, serwer Edge Transport, serwer Unified Messaging
Dynamiczne RPC
Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost — RPC (przychodzący protokół TCP)
Dynamiczne RPC
Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost — RPCEPMap (przychodzące TCP)
Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (przychodzące TCP)
MSExchangeRPC (GFW) (przychodzące TCP)
Serwer Client Access, serwer Hub Transport, serwer Mailbox, serwer Unified Messaging
Dynamiczne RPC
MSExchange — IMAP4 (GFW) (przychodzące TCP)
Serwer dostępu klienta
MSExchangeIMAP4 (przychodzący TCP)
Serwer dostępu klienta
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange — POP3 (FGW) (przychodzący protokół TCP)
Serwer dostępu klienta
MSExchange — POP3 (przychodzący TCP)
Serwer dostępu klienta
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange — OWA (GFW) (przychodzące TCP)
Serwer dostępu klienta
5075, 5076, 5077 (TCP)
MSExchangeOWAAppPool (wejście TCP)
Serwer dostępu klienta
5075, 5076, 5077 (TCP)
inetsrv\w3wp.exe
MSExchangeAB RPC (przychodzący TCP)
Serwer dostępu klienta
Dynamiczne RPC
MSExchangeAB-RPCEPMap (wejście TCP)
Serwer dostępu klienta
Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (wejście TCP)
Serwer dostępu klienta
6002, 6004 (TCP)
Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (przychodzący TCP)
Serwer dostępu klienta
Dynamiczne RPC
System32\Svchost.exe
MSExchangeRPC — RPC (przychodzące TCP)
Dynamiczne RPC
MSExchangeRPC — PRCEPMap (przychodzące TCP)
Serwer dostępu klienta, serwer skrzynki pocztowej
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (przychodzący TCP)
Serwer dostępu klienta, serwer skrzynki pocztowej
Bing\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (przychodzący TCP)
Serwer dostępu klienta
MSExchangeMailboxReplication (przychodzący TCP)
Serwer dostępu klienta
Bin\MSExchangeMailboxReplication.exe
MSExchangeIS — RPC (przychodzący protokół TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
MSExchangeIS RPCEPMap (przychodzący TCP)
Serwer skrzynki pocztowej
MSExchangeIS (GFW) (przychodzący TCP)
Serwer skrzynki pocztowej
6001, 6002, 6003, 6004 (TCP)
MSExchangeIS (przychodzący TCP)
Serwer skrzynki pocztowej
MSExchangeMailboxAssistants — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
MSExchangeMailboxAssistants — RPCEPMap (przychodzące TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
MSExchangeMailSubmission — RPCEPMap (przychodzące TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeMailSubmission.exe
MSExchangeMigration — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
Bin\MSExchangeMigration.exe
MSExchangeMigration — RPCEPMap (przychodzące TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeMigration.exe
MSExchangerepl — kopiarka dziennika (przychodzące TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeRepl.exe
MSExchangerepl — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
Bin\MSExchangeRepl.exe
MSExchangerepl — RPC-EPMap (wejście TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeRepl.exe
MSExchangeSearch — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling — RPC (przychodzące TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
Bin\MSExchangeThrottling.exe
MSExchangeThrottling — RPCEPMap (przychodzące TCP)
Serwer skrzynki pocztowej
Bin\MSExchangeThrottling.exe
MSFTED — RPC (przychodzący protokół TCP)
Serwer skrzynki pocztowej
Dynamiczne RPC
MSFTED — RPCEPMap (wejście TCP)
Serwer skrzynki pocztowej
MSExchangeEdgeSync — RPC (przychodzący protokół TCP)
Hubowy serwer transportowy
Dynamiczne RPC
MSExchangeEdgeSync RPCEPMap (przychodzące TCP)
Hubowy serwer transportowy
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker — RPC (przychodzący TCP)
Hubowy serwer transportowy
Dynamiczne RPC
Bin\edgetransport.exe
MSExchangeTransportWorker — RPCEPMap (przychodzące TCP)
Hubowy serwer transportowy
Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (przychodzący TCP)
Hubowy serwer transportowy
MSExchangeTransportWorker (przychodzący TCP)
Hubowy serwer transportowy
Bin\edgetransport.exe
MSExchangeTransportLogSearch — RPC (przychodzący protokół TCP)
Dynamiczne RPC
MSExchangeTransportLogSearch — RPCEPMap (przychodzące TCP)
Serwer Hub Transport, serwer Edge Transport, serwer Mailbox
Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (wejście TCP)
Serwer ujednoliconej komunikacji
SESWorker (przychodzący TCP)
Serwer ujednoliconej komunikacji
UnifiedMessaging\SESWorker.exe
UMService (GFW) (przychodzące TCP)
Serwer ujednoliconej komunikacji
UMService (przychodzące TCP)
Serwer ujednoliconej komunikacji
Bin\UMService.exe
UMWorkerProcess (GFW) (przychodzący TCP)
Serwer ujednoliconej komunikacji
5065, 5066, 5067, 5068
UMWorkerProcess (przychodzący TCP)
Serwer ujednoliconej komunikacji
5065, 5066, 5067, 5068
Bin\UMWorkerProcess.exe
UMWorkerProcess — RPC (przychodzący TCP)
Serwer ujednoliconej komunikacji
Dynamiczne RPC
Bin\UMWorkerProcess.exe
Uwagi dotyczące reguł zapory systemu Windows utworzonych przez Instalatora programu Exchange 2010
- Na serwerach z zainstalowanymi usługami IIS system Windows otwiera porty HTTP (port 80, TCP) i HTTPS (port 443, TCP). Instalator programu Exchange 2010 nie otwiera tych portów. W związku z tym te porty nie są wymienione w poprzedniej tabeli.
- W systemach Windows Server 2008 i Windows Server 2008 R2 Zapora systemu Windows z zabezpieczeniami zaawansowanymi umożliwia określenie procesu lub usługi, dla której port jest otwarty. Jest to bezpieczniejsze, ponieważ port może być używany tylko przez proces lub usługę określoną w regule. Instalator programu Exchange tworzy reguły zapory z określoną nazwą procesu. W niektórych przypadkach dla celów zgodności tworzona jest również dodatkowa reguła, która nie jest ograniczona do tego procesu. Reguły nieograniczające procesów można wyłączyć lub usunąć i zachować odpowiadające im reguły ograniczone do procesów, jeśli obsługuje je bieżące środowisko wdrażania. Reguły, które nie są ograniczone do procesów, można odróżnić po słowie (GFW) w imię zasady.
- Wiele usług Exchange używa do komunikacji zdalnych wywołań procedur (RPC). Procesy serwera korzystające ze zdalnych wywołań procedur łączą się z narzędziem odwzorowującym punkty końcowe RPC w celu uzyskania dynamicznych punktów końcowych i zarejestrowania ich w bazie danych programu odwzorowującego punkty końcowe. Klienci RPC współdziałają z narzędziem RPC Endpoint Mapper w celu określenia punktów końcowych używanych przez proces serwera. Domyślnie narzędzie RPC Endpoint Mapper nasłuchuje na porcie 135 (TCP). Podczas konfigurowania Zapory systemu Windows dla procesu korzystającego ze zdalnych wywołań procedur Instalator programu Exchange 2010 tworzy dla tego procesu dwie reguły zapory. Jedna reguła umożliwia komunikację z narzędziem mapującym punkty końcowe RPC, a druga reguła umożliwia komunikację z dynamicznie przypisywanym punktem końcowym. Aby uzyskać więcej informacji na temat zdalnych wywołań procedur, zobacz artykuł. Aby uzyskać więcej informacji na temat tworzenia reguł Zapory systemu Windows dla dynamicznego zdalnego wywołania procedury, zobacz artykuł.
Aby uzyskać więcej informacji, zobacz artykuł 179442 bazy wiedzy Microsoft Knowledge Base
www.microsoft.com
Artykuł Exchange 2013 Front End Usługa transportowa jest pierwszym z serii artykułów opisujących sposób działania usług transportowych programu Exchange Server 2013. W tym artykule skupimy się na Usługa transportu frontowego na serwerach Client Access.
W wersji 2013 serwera Exchange nastąpiły dość mocne zmiany w architekturze i teraz są tylko dwie główne role - serwer skrzynki pocztowej (w skrócie Mailbox Server lub MBX) oraz serwer dostępu klienta (Client Access Server - CAS). Wyróżnieniem jest rola serwera Edge Transport. Praca Exchange 2013 Front End Transport znajduje się na serwerach CAS i działa jako proxy.
To jest pierwszy artykuł z serii o tym, jak działają usługi potoków transportowych Exchange 2013, ale oto pełna lista:
A także artykuły na temat zarządzania logowaniem tych usług:
Nie zapomnij o oficjalnej dokumentacji.
Więcej informacji na temat konfigurowania i administrowania Exchange 2013 znajdziesz na moim blogu w głównym temacie -.
Tak się składa, że w Exchange 2013 jest teraz całkiem sporo usług transportowych, które mają podobne nazwy, ale zasadniczo różnią się przeznaczeniem i sposobem działania. Oto wszystkie te usługi:
- Usługa transportu frontowego na serwerach Client Access (nazwa wyświetlana to Microsoft Exchange FrontEnd Transport, w skrócie MSExchangeFrontEndTransport);
- Usługi transportowe na serwerach Mailbox (nazwa wyświetlana to Microsoft Exchange Transport, w skrócie MSExchangeTransport);
- Usługa transportu skrzynek pocztowych na serwerach skrzynek pocztowych (naprawdę obejmuje dwie usługi - Microsoft Exchange Mailbox Transport Delivery i Microsoft Exchange Mailbox Transport Submission, skrócone nazwy - odpowiednio MSExchangeDelivery i MSExchangeSubmission);
- Usługa transportu na serwerach Edge Transport (nazwa wyświetlana to Microsoft Exchange Transport, w skrócie MSExchangeTransport).
Jednocześnie tylko druga i czwarta usługa pełnią porównywalną funkcjonalność, reszta różni się zasadniczo. Razem tworzą potok transportowy, który jest sercem serwera pocztowego.
przenośnik transportowy
Ogólnie rurociąg transportowy wygląda następująco:
W kontekście tego artykułu interesuje nas górna część ilustracji, która przedstawia Client Access Server:
W tym schemacie jest jeden niuans. Faktem jest, że domyślnie serwery MBX mogą niezależnie wysyłać pocztę przez port 25 SMTP. Aby upewnić się, że łącznik wysyłania zawsze wysyła pocztę do Internetu za pośrednictwem serwerów Client Access, należy jawnie ustawić parametr łącznika wysyłania na Włączono serwer proxy frontendu w znaczenie $prawda(lub w EAC zaznacz pole Proxy przez serwer Client Access we właściwościach łącznika Send). To właśnie z tej konfiguracji będę korzystał w przyszłości.
Poniżej postaram się przybliżyć nieco zasadę działania. Serwery Exchange 2013 z rolą CAS.
Zasada działania
Transport z przodu(w terminologii Microsoftu - Usługa transportu frontowego) nie przetwarza treści wiadomości, nie korzysta z kolejki wiadomości i nie wchodzi w interakcję z usługą Mailbox Transport. Innymi słowy, serwery Exchange 2013 posiadające tylko rolę CAS nie przechowują danych ani na stałe (za pomocą bazy danych), ani tymczasowo (w kolejce przetwarzania komunikatów).
Jednak usługa Front End Transport ma własnych agentów transportu (patrz rysunek — agenci protokołów). Agenci umożliwiają rozszerzenie funkcjonalności serwera poczty Exchange przez dodanie niestandardowego kodu do logiki przetwarzania wiadomości. Agenty są wywoływane, gdy wystąpią zdarzenia SMTP. Zdarzenia te z kolei są generowane na tym czy innym etapie przetwarzania komunikatów podczas przechodzenia przez potok transportowy. Warto zauważyć, że większość domyślnie obecnych agentów jest ukryta lub nie można kontrolować ich ustawień. Funkcjonalność agentów na serwerach CAS jest dość ograniczona i jest w pełni obecna tylko dla ról MBX i Edge.
Łączniki wysyłania i odbierania
Na schemacie (patrz wyżej) Usługa transportu frontowego oznaczamy serwer dostępu klienta na każdym przychodzącym i połączenie wychodzące odpowiedni port, co daje następującą reprezentację:
Oddzielne złącze odbiorcze odpowiada za nasłuchiwanie połączeń na każdym porcie wskazanym na schemacie, z czego trzy sztuki są tworzone domyślnie po zainstalowaniu roli CAS:
Oprócz konektorów, które są widoczne i dostępne dla administratora, istnieją również ukryte konektory systemowe Wyślij:
- Wewnętrzne złącze wysyłania przychodzącego serwera proxy (SMTP 25/2525 cala )
- Client Proxy Send Connector (SMTP odebrany na porcie 587 w Usługa transportu na serwerach Mailbox do portu 465)
Nawiasem mówiąc, pierwszy konektor w rosyjskiej wersji Exchange Server 2013 będzie miał nazwę Wewnętrzne złącze wysyłania dla wejścia. połączenie serwery proxy, i drugi - Łącznik wysyłania serwera proxy klienta. To tak na wszelki wypadek, żeby nie wpaść w osłupienie przy pierwszym spotkaniu z tymi łącznikami.
W rezultacie otrzymujemy następującą kompletną tabelę:
| Nazwa | Zamiar | Port | Kierunek |
| Domyślny interfejs użytkownika |
Przyjęcie | 25 | Z zewnętrznych serwerów |
| Wychodzący interfejs proxy |
Przyjęcie | 717 | Z serwerów MBX |
| Interfejs klienta |
Przyjęcie | 587 | Od klientów zewnętrznych, bezpieczne połączenie |
| Łącznik wysyłania serwera proxy klienta | Wysyłanie | 465 | Do serwerów MBX |
| Wewnętrzny łącznik wysyłania przychodzącego serwera proxy | Wysyłanie | 25/2525 | Do serwerów MBX. Akceptowane są tylko połączenia na porcie 587 |
| Ręcznie utworzony łącznik wysyłania | Wysyłanie | 25 | Do serwerów zewnętrznych |
Przenieśmy nazwy złączy na diagram Usługa transportu frontowego.
Serwer Exchange i zapory ognioweFirewalle (firewalle) dla serwerów pocztowych (Exchange Server), porty serwerów pocztowych, serwery pocztowe front-end i back-end, Serwery Wirtualne SMTP, POP3, IMAP4
Jak każdy komputer podłączony do Internetu, komputer obsługujący serwer pocztowy musi być chroniony zaporą ogniową. Jednocześnie opcje instalacji serwera pocztowego pod względem konfiguracji sieci mogą być bardzo różne:
· Najprostszą opcją jest zainstalowanie serwera pocztowego na komputerze będącym jednocześnie proxy/firewallem, a następnie otwarcie niezbędnych portów na interfejsie skierowanym do Internetu. Zazwyczaj ten schemat jest używany w małych organizacjach;
Inną opcją jest zainstalowanie serwera pocztowego w lokalna sieć i skonfiguruj go do pracy przez serwer proxy. Aby to zrobić, możesz powiązać publiczny adres IP z serwerem pocztowym i przekazać go przez serwer proxy lub użyć narzędzi do mapowania portów na serwerze proxy. Wiele serwerów proxy ma specjalne kreatory lub predefiniowane reguły organizacji takiego rozwiązania (na przykład w ISA Server). Ta opcja jest używana w większości organizacji.
· Inną fundamentalną możliwością jest utworzenie DMZ i umieszczenie w nim front-endowego Serwera Exchange (taka możliwość pojawiła się od wersji 2000) lub SMTP Relay oparty na innym Serwerze Exchange lub np. sendmail na *nix. Zwykle używany w sieciach dużych organizacji.
W każdym przypadku serwer pocztowy musi zapewniać komunikację co najmniej na porcie TCP 25 (SMTP) i porcie UDP 53 (DNS). Inne porty, które mogą być wymagane przez Exchange Server w zależności od konfiguracji sieci (wszystkie TCP):
80 HTTP - aby uzyskać dostęp do interfejsu internetowego (OWA)
· 88 protokół uwierzytelniania Kerberos — jeśli używane jest uwierzytelnianie Kerberos (rzadko);
· 102 złącze MTA .X .400 przez TCP /IP (jeśli złącze X .400 jest używane do komunikacji między grupami routingu);
· 110 Post Office Protocol 3 (POP 3) - dla dostępu klienta;
· 119 Network News Transfer Protocol (NNTP) – jeśli używane są grupy dyskusyjne;
135 Komunikacja klient/serwer Administracja RPC Exchange - standardowy port RPC do zdalnej administracji Exchange standardowe środki menadżer systemu;
· 143 Internetowy protokół dostępu do wiadomości (IMAP) - w celu uzyskania dostępu dla klientów;
· 389 LDAP – dostęp do usługi katalogowej;
· 443 HTTP (Secure Sockets Layer (SSL)) (i niższe) - te same protokoły chronione przez SSL.
563 NNTP (SSL)
636 LDAP (SSL)
993 IMAP4 (SSL)
995 POP3 (SSL)
· 3268 i 3269 - żądania do serwera wykazu globalnego (wyszukiwanie w Active Directory i sprawdzanie członkostwa w grupach uniwersalnych).
Nie ma sensu zamykać firewallem interfejsu Exchange Server skierowanego do wewnątrz organizacji – posłuży on do interakcji z kontrolerami domeny, narzędziami administracyjnymi, systemami Kopia rezerwowa i tak dalej. W przypadku interfejsu wystawionego na działanie Internetu zaleca się pozostawienie portów 53 (jeżeli Exchange będzie sam rozpoznawał nazwy hostów, a nie przekazywał żądań do lokalny serwer DNS) i 25. Bardzo często klienci potrzebują dostępu do swoich skrzynek pocztowych z zewnątrz (z domu, w podróży służbowej itp.). Najlepszym rozwiązaniem w tej sytuacji jest skonfigurowanie OWA (interfejs internetowy umożliwiający dostęp do Exchange Server, który jest instalowany domyślnie, dostępny pod adresem http://nazwa_serwera/exchange) do pracy przez SSL i zezwalania na dostęp tylko na porcie 443. Oprócz rozwiązanie problemów z bezpiecznym uwierzytelnianiem i szyfrowaniem wiadomości automatycznie rozwiązuje problem z SMTP Relay (więcej o tym później) oraz sytuację, gdy użytkownik przypadkowo pobierze działającą e-mail do folderów klienta poczty komputer domowy, a potem w pracy nie może znaleźć tych wiadomości (nie mówiąc już o tym, że przechowywanie służbowej poczty w domu to naruszenie bezpieczeństwa).
Nowa funkcja wprowadzona w Exchange Server. od wersji 2000 możliwość korzystania z wielu wirtualnych serwerów SMTP i POP3 z różnymi ustawieniami zabezpieczeń. Na przykład serwer SMTP, który komunikuje się z Internetem, można skonfigurować pod kątem zwiększonego bezpieczeństwa i ścisłych ograniczeń dostarczania, podczas gdy serwer SMTP, z którego korzystają użytkownicy w organizacji, można skonfigurować pod kątem maksymalnej wydajności i łatwości obsługi.
Trzeba też wspomnieć o pewnym zamieszaniu terminologicznym – bardzo często firewalle dla Exchange nazywane są systemami filtrowania wiadomości, co zostanie omówione poniżej.
[Ten artykuł jest dokumentem wstępnym i może ulec zmianie w przyszłych wydaniach. Puste sekcje są uwzględniane jako elementy zastępcze. Jeśli chcesz napisać recenzję, chętnie ją otrzymamy. Wyślij go do nas e-mailem [e-mail chroniony]]
Stosuje się do: Serwer Exchange 2016
Informacje o portach sieciowych używanych przez Exchange 2016 do uzyskiwania dostępu klientów i przepływu poczty.
Ten temat zawiera informacje o portach sieciowych używanych przez program Microsoft Exchange Server 2016 do komunikowania się z klientami poczty e-mail, internetowymi serwerami poczty i innymi usługami znajdującymi się poza lokalną organizacją programu Exchange. Zanim zaczniesz, rozważ następujące podstawowe zasady.
Nie obsługujemy ograniczania ani modyfikowania ruchu sieciowego między wewnętrznymi serwerami Exchange, między wewnętrznymi serwerami Exchange a wewnętrznymi serwerami Lync lub Skype dla firm ani między wewnętrznymi serwerami Exchange a wewnętrznymi kontrolerami domeny usługi Active Directory w żadnym z typów topologii. Jeśli używasz zapór sieciowych lub urządzeń sieciowych, które mogą ograniczać lub modyfikować ten ruch sieciowy, musisz skonfigurować reguły umożliwiające swobodną i nieograniczoną komunikację między tymi serwerami (reguły zezwalające na ruch sieciowy do i z dowolnego portu, w tym losowe porty RPC i wszelkie protokół). , który nie zmienia ani jednego bitu).
Serwery Edge Transport prawie zawsze znajdują się w sieci obwodowej, więc oczekuje się, że ruch sieciowy między serwerem Edge Transport a Internetem oraz między serwerem Edge Transport a wewnętrzną organizacją Exchange będzie ograniczony. Te porty sieciowe są opisane w tej sekcji.
Oczekuje się od Ciebie ograniczenia ruchu sieciowego między zewnętrznymi klientami i usługami a wewnętrzną organizacją Exchange. Możesz także ograniczyć ruch między klientami wewnętrznymi a wewnętrznymi serwerami Exchange. Te porty sieciowe są opisane w tej sekcji.
Treść
Porty sieciowe wymagane dla klientów i usług
Porty sieciowe wymagane do przepływu poczty (brak serwerów Edge Transport)
Porty sieciowe wymagane do przepływu poczty z serwerami Edge Transport
Porty sieciowe wymagane do wdrożeń hybrydowych
Porty sieciowe wymagane do usługi Unified Messaging
Porty sieciowe, których potrzebują klienci poczty e-mail, aby uzyskać dostęp do skrzynek pocztowych i innych usług w organizacji Exchange, są opisane w następny schemat i w tabeli.
Notatki.
Miejscem docelowym dla tych klientów i usług są usługi Client Access na serwerze Mailbox. W programie Exchange 2016 usługi dostępu klienta (zewnętrzne) i usługi wewnętrzne są instalowane razem na tym samym serwerze skrzynki pocztowej. Zobacz sekcję, aby uzyskać więcej informacji.
Chociaż na diagramie przedstawiono klientów i usługi z Internetu, pojęcia dotyczące klientów wewnętrznych (na przykład klientów w lesie kont uzyskujących dostęp do serwerów programu Exchange w lesie zasobów) są takie same. Podobnie w tabeli nie ma kolumny Źródło, ponieważ źródłem może być dowolna lokalizacja poza organizacją programu Exchange (na przykład Internet lub las konta).
Serwery Edge Transport nie uczestniczą w ruchu sieciowym związanym z tymi klientami i usługami.
| Zamiar | Porty | Notatki |
|---|---|---|
Szyfrowane połączenia internetowe są używane przez następujących klientów i usługi. Usługa automatycznego wykrywania Exchange ActiveSync Usługi internetowe Exchange (EWS) Dystrybucja książek adresowych offline Outlook Anywhere (RPC przez HTTP) MAPI Outlook przez HTTP Outlook w sieci | 443/TCP (HTTPS) | Odniesienie EWS dla Exchange |
Nieszyfrowane połączenia internetowe są używane przez następujących klientów i usługi. Opublikuj swój kalendarz w Internecie Outlook w sieci (przekierowanie do portu 443/TCP) Automatyczne wykrywanie (awaryjne, gdy port 443/TCP jest niedostępny) | 80/TCP (HTTP) | Jeśli to możliwe, zalecamy korzystanie z szyfrowanych połączeń internetowych na porcie 443/TCP w celu ochrony poświadczeń i innych danych. Jednak niektóre usługi muszą być skonfigurowane do korzystania z niezaszyfrowanych połączeń internetowych na porcie 80/TCP z usługami Client Access na serwerach Mailbox. Aby uzyskać więcej informacji na temat tych klientów i usług, zobacz następujące artykuły. |
klientów IMAP4 | 143/TCP (IMAP), 993/TCP (bezpieczny IMAP) | IMAP4 jest domyślnie wyłączony. Zobacz sekcję, aby uzyskać więcej informacji. Usługa IMAP4 w usługach Client Access na serwerze Mailbox pośredniczy w połączeniach z wewnętrzną usługą IMAP4 na serwerze Mailbox. |
Klienci POP3 | 110/TCP (POP3), 995/TCP (bezpieczny POP3) | Domyślnie protokół POP3 jest wyłączony. Zobacz sekcję, aby uzyskać więcej informacji. Usługa POP3 w usługach Client Access na serwerze Mailbox pośredniczy w połączeniach z wewnętrzną usługą POP3 na serwerze Mailbox. |
Klienci SMTP (z uwierzytelnianiem) | 587/TCP (uwierzytelniony SMTP) | Domyślnym łącznikiem odbierania jest „fronton klienta Notatka. Jeśli masz klientów poczty e-mail, którzy mogą wysyłać uwierzytelnione wiadomości SMTP tylko na porcie 25, możesz zmienić wartość powiązania tego łącznika odbierania, aby również nasłuchiwać uwierzytelnionych wiadomości SMTP na porcie 25. |
Na początek
Porty sieciowe wymagane do przepływu poczty
Poczta wychodząca
25/TCP (SMTP)
Serwer skrzynki pocztowej
Internet (wszystkie)
Domyślnie program Exchange nie tworzy łączników wysyłania, które umożliwiają wysyłanie poczty do Internetu. Łączniki wysyłania należy utworzyć ręcznie. Zobacz sekcję, aby uzyskać więcej informacji.
Poczta wychodząca (jeśli jest wysyłana za pośrednictwem zewnętrznej usługi transportowej)
25/TCP (SMTP)
Serwer skrzynki pocztowej
Internet (wszystkie)
Poczta wychodząca jest wysyłana przez zewnętrzną usługę transportową tylko wtedy, gdy włączone jest ustawienie Wyślij łącznik Proxy przez serwer Client Access w EAC lub parametr -FrontEndProxyEnabled $true w powłoce Exchange Management Shell.
W takim przypadku domyślny łącznik odbierania „Outbound Proxy Frontend
Serwer DNS do rozpoznawania nazw następnego przeskoku poczty (nie pokazano)
53/UDP, 53/TCP (DNS)
Serwer skrzynki pocztowej
serwer DNS
Na początek
Subskrybowany serwer Edge Transport zainstalowany w sieci obwodowej wpływa na przepływ poczty w następujący sposób:
Poczta z serwera Exchange 2016 lub Exchange 2013 Edge Transport najpierw trafia do usługi External Transport, a następnie jest kierowana do usługi Transport na serwerze Exchange 2016 Mailbox.
Poczta z serwera Exchange 2010 Edge Transport zawsze trafia bezpośrednio do usługi Transport na serwerze Exchange 2016 Mailbox.
Poczta wychodząca z organizacji Exchange nigdy nie przechodzi przez zewnętrzną usługę transportową na serwerach Mailbox. Zawsze przekierowuje z usługi Transport na serwerze Mailbox subskrybowanej witryny Active Directory na serwer Edge Transport (niezależnie od wersji Exchange na serwerze Edge Transport).
Poczta przychodząca jest przekierowywana z serwera Edge Transport do serwera Mailbox subskrybowanej witryny Active Directory. Oznacza to, co następuje:
Porty sieciowe wymagane do przepływu poczty w organizacjach Exchange z serwerami Edge Transport są opisane na poniższym diagramie i w tabeli.
| Zamiar | Porty | Źródło | Zamiar | Notatki |
|---|---|---|---|---|
Poczta przychodząca - z Internetu do serwera Edge Transport | 25/TCP (SMTP) | Internet (wszystkie) | Domyślny łącznik odbiorczy o nazwie Domyślny wewnętrzny łącznik odbiorczy <имя пограничного транспортного сервера> " na serwerze Edge Transport nasłuchuje anonimowej poczty SMTP na porcie 25. |
|
Poczta przychodząca — z serwera Edge Transport do wewnętrznej organizacji Exchange | 25/TCP (SMTP) | Serwer transportu brzegowego | Domyślny łącznik wysyłania o nazwie „EdgeSync — przychodzące do Domyślny łącznik odbiorczy „Domyślny interfejs użytkownika |
|
Poczta wychodząca — z wewnętrznej organizacji Exchange do serwera Edge Transport | 25/TCP (SMTP) | Serwery skrzynek pocztowych w subskrybowanej lokacji usługi Active Directory | Poczta wychodząca zawsze omija usługę transportu zewnętrznego na serwerach skrzynek pocztowych. Poczta jest przekazywana z usługi Transport na dowolnym serwerze skrzynek pocztowych w subskrybowanej lokacji Active Directory do serwera Edge Transport przy użyciu niejawnego i niewidocznego wewnątrzorganizacyjnego łącznika Send, który automatycznie kieruje pocztę między serwerami Exchange w tej samej organizacji. Domyślne wewnętrzne złącze odbiorcze |
|
Poczta wychodząca - z serwera Edge Transport do Internetu | 25/TCP (SMTP) | Serwer transportu brzegowego | Internet (wszystkie) | Domyślny łącznik wysyłania o nazwie „EdgeSync — z <имя сайта Active Directory> do Internetu” przekazuje pocztę wychodzącą na porcie 25 z serwera Edge Transport do Internetu. |
Synchronizacja EdgeSync | 50636/TCP (Bezpieczny LDAP) | Serwery skrzynek pocztowych w subskrybowanej lokacji Active Directory, które uczestniczą w synchronizacji EdgeSync | Serwery transportu brzegowego | Jeśli serwer Edge Transport jest subskrybowany do witryny Active Directory, wszystkie serwery skrzynek pocztowych, które obecnie istnieją w tej lokacji, uczestniczą w synchronizacji EdgeSync. Ale jeśli później dodasz więcej serwerów Mailbox, nie będą one automatycznie uczestniczyć w synchronizacji EdgeSync. |
Serwer DNS do rozpoznawania nazw następnego przeskoku (nie pokazano) | 53/UDP, 53/TCP (DNS) | Serwer transportu brzegowego | serwer DNS | Zobacz rozpoznawanie nazw. |
Sender Reputation Wykrywanie otwartego serwera proxy (nie pokazano) | Zobacz notatki | Serwer transportu brzegowego | Internet | Domyślnie agent analizy protokołów używa wykrywania otwartego serwera proxy jako jednego z warunków obliczania poziomu reputacji źródłowego serwera przesyłania wiadomości. Zobacz artykuł, aby uzyskać więcej informacji. Następujące porty TCP są używane do sprawdzania źródłowych serwerów przesyłania wiadomości pod kątem otwartego serwera proxy: Ponadto, jeśli Twoja organizacja używa serwera proxy do kontrolowania wychodzącego ruchu internetowego, musisz określić nazwę, typ i port TCP serwera proxy wymagane do uzyskania dostępu do Internetu i wykrycia otwartego serwera proxy. Możesz także wyłączyć wykrywanie otwartego serwera proxy. Zobacz sekcję, aby uzyskać więcej informacji. |
Na początek
Rozdzielczość nazw
Rozdzielczość nazw
Rozpoznawanie poczty następnego przeskoku DNS jest podstawową częścią przepływu poczty w każdej organizacji Exchange. Serwery Exchange odpowiedzialne za odbieranie poczty przychodzącej lub dostarczanie poczty wychodzącej muszą być w stanie rozpoznać zarówno wewnętrzne, jak i zewnętrzne nazwy hostów, aby prawidłowo kierować pocztę. Wszystkie wewnętrzne serwery Exchange muszą mieć możliwość rozpoznawania wewnętrznych nazw hostów w celu prawidłowego kierowania poczty. Jest wiele różne drogi rozwój infrastruktury DNS, ale ważnym rezultatem jest zapewnienie prawidłowego rozpoznawania nazw dla następnego przeskoku na wszystkich serwerach Exchange.