Exchange 네트워크 포트 참조

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

이 항목에서는 MicrosoftExchange Server 2010에서 사용되는 모든 데이터 경로의 포트, 인증 및 암호화에 대한 정보를 제공합니다. 각 표 뒤에 나오는 "참고 사항" 섹션에서는 비표준 인증 또는 암호화 방법을 설명하거나 정의합니다.

전송 서버

Exchange 2010에는 메시지 전송 기능을 수행하는 두 가지 서버 역할 허브 전송 서버 및 Edge 전송 서버.

다음 표에서는 이 두 전송 서버 간, 다른 Exchange 2010 서버 및 서비스 간의 포트, 인증 및 데이터 경로 암호화에 대한 정보를 제공합니다.

전송 서버 데이터 경로

데이터 경로 필요한 포트 기본 인증 지원되는 인증 암호화 지원 여부 암호화 작업 기본 수행 여부

허브 전송 서버에서 허브 전송 서버로

25/TCP(SMTP)

Kerberos

Kerberos

예, TLS(전송 계층 보안) 사용

예

허브 전송 서버에서 Edge 전송 서버로

25/TCP(SMTP)

직접 신뢰

직접 신뢰

예, TLS 사용

예

Edge 전송 서버에서 허브 전송 서버로

25/TCP(SMTP)

직접 신뢰

직접 신뢰

예, TLS 사용

예

Edge 전송 서버에서 Edge 전송 서버로

25/TCP(SMTP)

익명, 인증서

익명, 인증서

예, TLS 사용

예

Microsoft Exchange Mail Submission Service를 통해 사서함 서버에서 허브 전송 서버로

135/TCP(RPC)

NTLM. 허브 전송 및 사서함 서버 역할이 같은 서버에 있으면 Kerberos가 사용됩니다.

NTLM/Kerberos

예, RPC 암호화 사용

예

MAPI를 통해 허브 전송 서버에서 사서함 서버로

135/TCP(RPC)

NTLM. 허브 전송 및 사서함 서버 역할이 같은 서버에 있으면 Kerberos가 사용됩니다.

NTLM/Kerberos

예, RPC 암호화 사용

예

통합 메시징 서버에서 허브 전송 서버로

25/TCP(SMTP)

Kerberos

Kerberos

예, TLS 사용

예

Microsoft 허브 전송 서버에서 Edge 전송 서버로의 Exchange EdgeSync 서비스

50636/TCP(SSL)

기본

기본

예, LDAPS(LDAP over SSL) 사용

예

허브 전송 서버에서 Active Directory 액세스

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

허브 전송 서버에서 AD RMS(Active Directory Rights Management Services) 액세스

443/TCP(HTTPS)

NTLM/Kerberos

NTLM/Kerberos

예, SSL 사용

예*

SMTP 클라이언트에서 허브 전송 서버로(예: Windows Live Mail을 사용하는 최종 사용자)

587(SMTP)

25/TCP(SMTP)

NTLM/Kerberos

NTLM/Kerberos

예, TLS 사용

예

전송 서버 참고 사항

  • 허브 전송 서버 간의 모든 트래픽은 Exchange 2010 설치 프로그램에서 설치하는 자체 서명 인증서와 TLS를 사용하여 암호화됩니다.

    참고

    Exchange 2010의 허브 전송 서버에서 동일한 Exchange 조직에 있는 다른 허브 전송 서버와의 내부 SMTP 통신에 TLS를 사용하지 않도록 설정할 수 있습니다. 반드시 필요한 경우가 아니면 이 작업을 수행하지 않는 것이 좋습니다. 자세한 내용은 Active Directory 사이트 간 TLS를 사용하지 않도록 설정하여 WAN 최적화 지원를 참조하십시오.

  • Edge 전송 서버와 허브 전송 서버 간의 모든 트래픽은 인증 및 암호화됩니다. 상호 TLS는 기본 인증 및 암호화 메커니즘입니다. Exchange 2010에서는 X.509 유효성 검사 대신 직접 신뢰를 사용하여 인증서를 인증합니다. 직접 신뢰란 Active Directory 또는 Active Directory LDS(Lightweight Directory Services)에 있는 인증서의 존재 여부로 인증서의 유효성을 검사하는 것입니다. Active Directory는 신뢰할 수 있는 저장소 메커니즘으로 간주됩니다. 직접 신뢰를 사용하는 경우 인증서가 자체 서명한 것인지 아니면 CA(인증 기관)에서 서명한 것인지는 관계가 없습니다. Exchange 조직에서 Edge 전송 서버를 구독하는 경우 해당 Edge 구독에서는 유효성을 검사할 허브 전송 서버에 대해 Active Directory에 Edge 전송 서버 인증서를 게시합니다. Microsoft Exchange Edgesync 서비스에서는 유효성을 검사할 Edge 전송 서버에 대해 허브 전송 서버 인증서 집합을 사용하여 AD LDS를 함께 업데이트합니다.

  • EdgeSync는 TCP 50636을 통해 허브 전송 서버에서 구독한 Edge 전송 서버로 연결되는 보안 LDAP 연결을 사용합니다. AD LDS는 또한 TCP 50389에서 수신 대기합니다. 이 포트에 대한 연결은 SSL을 사용하지 않습니다. LDAP 유틸리티를 사용하여 포트에 연결하고 AD LDS 데이터를 확인할 수 있습니다.

  • 서로 다른 두 조직에 있는 Edge 전송 서버 간의 트래픽은 기본적으로 암호화됩니다. Exchange 2010 설치 프로그램은 자체 서명 인증서를 만들며, TLS는 기본적으로 사용하도록 설정됩니다. 이를 통해 모든 보내는 시스템에서 Exchange로의 인바운드 SMTP 세션을 암호화할 수 있습니다. 또한 기본적으로 Exchange 2010에서도 모든 원격 연결에 대해 TLS를 시도합니다.

  • 허브 전송 서버 역할과 사서함 서버 역할이 같은 컴퓨터에 설치되어 있는 경우에는 허브 전송 서버와 사서함 서버 간의 트래픽을 인증하는 방법이 달라집니다. 메일 전송을 로컬에서 수행하는 경우 Kerberos 인증이 사용되고 원격에서 수행하는 경우에는 NTLM 인증이 사용됩니다.

  • Exchange 2010에서는 도메인 보안도 지원됩니다. 도메인 보안은 보다 저렴한 가격으로 S/MIME 또는 기타 메시지 수준 인터넷 보안 솔루션을 대체할 수 있는 Exchange 2010 및 Microsoft Outlook 2010의 기능을 의미합니다. 도메인 보안은 인터넷을 통해 도메인 간 보안 메시지 경로를 관리할 수 있는 방법을 제공합니다. 이러한 보안 메시지 경로가 구성된 후 인증된 보낸 사람으로부터 보안 경로를 통해 전달된 메시지는 Outlook 및 Outlook Web Access 사용자에게 "도메인 보안"으로 표시됩니다. 자세한 내용은 도메인 보안 이해를 참조하십시오.

  • 허브 전송 서버와 Edge 전송 서버에서는 여러 에이전트를 실행할 수 있습니다. 일반적으로 스팸 방지 에이전트는 해당 에이전트가 실행되는 컴퓨터에 로컬로 저장된 정보를 사용합니다. 그러므로 원격 컴퓨터와의 통신이 거의 필요하지 않습니다. 받는 사람 필터링은 예외입니다. 받는 사람 필터링에는 AD LDS 또는 Active Directory에 대한 호출이 필요합니다. 받는 사람 필터링은 Edge 전송 서버에서 실행하는 것이 가장 효율적입니다. 이 경우 AD LDS 디렉터리는 Edge 전송 서버와 같은 컴퓨터에 있습니다. 그러므로, 원격 통신이 필요하지 않습니다. 받는 사람 필터링을 허브 전송 서버에서 설치 및 구성한 경우 받는 사람 필터링 과정에서 Active Directory에 액세스하게 됩니다.

  • Exchange 2010의 보낸 사람 신뢰도 기능에서는 프로토콜 분석 에이전트를 사용합니다. 또한 이 에이전트는 외부 프록시 서버와의 다양한 연결을 통해 의심되는 연결에 대한 인바운드 메시지 경로를 확인합니다.

  • 다른 모든 스팸 방지 기능은 수신 허용 목록 집계와 받는 사람 데이터 등의 데이터를 받는 사람 필터링에 사용합니다. 이 데이터는 로컬 컴퓨터에서만 수집, 저장 및 액세스됩니다. MicrosoftExchange EdgeSync 서비스를 사용하여 로컬 AD LDS 디렉터리로 데이터가 푸시되는 경우가 많습니다.

  • 허브 전송 서버의 IRM(정보 권한 관리) 에이전트는 조직의 AD RMS(Active Directory Rights Management Services) 서버에 대한 연결을 설정합니다. AD RMS는 SSL을 사용하여 보안되는 웹 서비스입니다. AD RMS 서버와의 통신은 HTTPS를 사용하여 수행되며 AD RMS 서버 구성에 따라 Kerberos 또는 NTLM이 인증에 사용됩니다.

  • 저널 규칙, 전송 규칙 및 메시지 분류는 Active Directory에 저장되며 허브 전송 서버의 저널링 에이전트 및 전송 규칙 에이전트에서 액세스합니다.

사서함 서버

사서함 서버에 NTLM 또는 Kerberos 인증이 사용되는지 여부는 Exchange 비즈니스 논리 계층 소비자를 실행하는 사용자 또는 프로세스 컨텍스트에 따라 달라집니다. 이러한 컨텍스트에서 볼 때 소비자는 Exchange 비즈니스 논리 계층을 사용하는 모든 응용 프로그램 또는 프로세스입니다. 따라서 사서함 서버 데이터 경로 표의 기본 인증 열 아래에 나열되는 대부분의 항목은 NTLM/Kerberos입니다.

Exchange 비즈니스 논리 계층은 Exchange 저장소와의 액세스 및 통신에 사용됩니다. 또한 외부 응용 프로그램 및 프로세스와 통신할 때도 Exchange 저장소에서 Exchange 비즈니스 논리 계층을 호출합니다.

Exchange 비즈니스 논리 계층 소비자가 로컬 시스템으로 실행 중인 경우 소비자에서 Exchange 저장소로의 인증 방법은 항상 Kerberos가 됩니다. 로컬 시스템 컴퓨터 계정을 사용하여 소비자를 인증해야 하며 양방향으로 인증된 신뢰 관계가 있어야 하므로 Kerberos가 사용되는 것입니다.

Exchange 비즈니스 논리 계층 소비자가 로컬 시스템으로 실행되고 있지 않으면 인증 방법은 NTLM이 됩니다. 예를 들어 Exchange 비즈니스 논리 계층을 사용하는 Exchange 관리 셸 cmdlet을 실행할 때는 NTLM이 사용됩니다.

RPC 트래픽은 항상 암호화됩니다.

다음 표에서는 사서함 서버 간의 데이터 경로에 대한 포트, 인증 및 암호화 정보를 제공합니다.

사서함 서버 데이터 경로

데이터 경로 필요한 포트 기본 인증 지원되는 인증 암호화 지원 여부 암호화 작업 기본 수행 여부

Active Directory 액세스

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

관리자 원격 액세스(원격 레지스트리)

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, IPsec 사용

아니요

관리자 원격 액세스(SMB/파일)

445/TCP(SMB)

NTLM/Kerberos

NTLM/Kerberos

예, IPsec 사용

아니요

가용성 웹 서비스(사서함으로의 클라이언트 액세스)

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

클러스터링

135/TCP(RPC) 이 표 다음에 나오는 사서함 서버 참고 사항를 참조하십시오.

NTLM/Kerberos

NTLM/Kerberos

예, IPsec 사용

아니요

콘텐츠 인덱싱

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

로그 전달

64327(사용자 지정 가능)

NTLM/Kerberos

NTLM/Kerberos

예

아니요

시드

64327(사용자 지정 가능)

NTLM/Kerberos

NTLM/Kerberos

예

아니요

VSS(볼륨 섀도 복사본 서비스) 백업

SMB(로컬 메시지 블록)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

사서함 도우미

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

MAPI 액세스

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

Microsoft Exchange Active Directory 토폴로지 서비스 액세스

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

Microsoft Exchange System Attendant 서비스 레거시 액세스(요청 수신)

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

Active Directory로의 Microsoft Exchange System Attendant 서비스 레거시 액세스

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

Microsoft Exchange System Attendant 서비스 레거시 액세스(MAPI 클라이언트로 액세스)

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

OAB(오프라인 주소록)의 Active Directory 액세스

135/TCP(RPC)

Kerberos

Kerberos

예, RPC 암호화 사용

예

받는 사람 업데이트 서비스 RPC 액세스

135/TCP(RPC)

Kerberos

Kerberos

예, RPC 암호화 사용

예

Active Directory에 대한 받는 사람 업데이트

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

사서함 서버 참고 사항

  • 위의 표에 나열된 클러스터링 데이터 경로는 동적 RPC over TCP를 사용하여 서로 다른 클러스터 노드 간에 클러스터 상태 및 작업을 교환합니다. 클러스터 서비스(ClusSvc.exe)도 UDP/3343 및 임의로 할당된 높은 TCP 포트를 사용하여 클러스터 노드 간에 통신합니다.

  • 노드 내 통신의 경우 클러스터 노드는 UDP(사용자 데이터그램 프로토콜) 3343 포트를 통해 통신합니다. 클러스터의 각 노드는 클러스터에 있는 다른 노드와 순차화된 유니캐스트 UDP 데이터그램을 주기적으로 교환합니다. 이러한 교환 작업은 모든 노드가 제대로 실행되고 있는지를 확인하고 네트워크 링크의 상태를 모니터링하기 위한 것입니다.

  • 포트 64327/TCP는 로그 전달에 사용되는 기본 포트입니다. 관리자는 로그 전달에 사용되는 다른 포트를 지정할 수 있습니다.

  • 협상 항목이 있는 HTTP 인증의 경우 Kerberos가 먼저 시도된 후에 NTLM이 시도됩니다.

클라이언트 액세스 서버

별도로 명시된 경우가 아니면 Outlook Web App, POP3 또는 IMAP4와 같은 클라이언트 액세스 기술은 클라이언트 응용 프로그램에서 클라이언트 액세스 서버로의 인증 및 암호화를 통해 설명됩니다.

다음 표에서는 클라이언트 액세스 서버와 다른 서버 및 클라이언트 간의 데이터 경로에 대한 포트, 인증 및 암호화 정보를 제공합니다.

클라이언트 액세스 서버 데이터 경로

데이터 경로 필요한 포트 기본 인증 지원되는 인증 암호화 지원 여부 암호화 작업 기본 수행 여부

Active Directory 액세스

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

Autodiscover 서비스

80/TCP, 443/TCP(SSL)

기본/통합된 Windows 인증(협상)

기본, 다이제스트, NTLM, 협상(Kerberos)

예, HTTPS 사용

예

가용성 서비스

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

NTLM, Kerberos

예, HTTPS 사용

예

MRS(사서함 복제 서비스)

808/TCP

Kerberos/NTLM

Kerberos, NTLM

예, RPC 암호화 사용

예

Outlook의 OAB 액세스

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

NTLM/Kerberos

예, HTTPS 사용

아니요

Outlook Web App

80/TCP, 443/TCP(SSL)

폼 기반 인증

기본, 다이제스트, 폼 기반 인증, NTLM(v2 전용), Kerberos, 인증서

예, HTTPS 사용

예, 자체 서명 인증서 사용

POP3

110/TCP(TLS), 995/TCP(SSL)

기본, Kerberos

기본, Kerberos

예, SSL, TLS 사용

예

IMAP4

143/TCP(TLS), 993/TCP(SSL)

기본, Kerberos

기본, Kerberos

예, SSL, TLS 사용

예

Outlook Anywhere(이전의 RPC over HTTP)

80/TCP, 443/TCP(SSL)

기본

기본 또는 NTLM

예, HTTPS 사용

예

Exchange ActiveSync 응용 프로그램

80/TCP, 443/TCP(SSL)

기본

기본, 인증서

예, HTTPS 사용

예

클라이언트 액세스 서버에서 통합 메시징 서버로

5060/TCP, 5061/TCP, 5062/TCP, 동적 포트

IP 주소별

IP 주소별

예, SIP(Session Initiation Protocol) over TLS 사용

예

클라이언트 액세스 서버에서 이전 버전의 Exchange Server를 실행 중인 사서함 서버로

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

협상(Kerberos, NTLM 또는 기본(옵션)으로 대체), POP/IMAP 일반 텍스트

예, IPsec 사용

아니요

클라이언트 액세스 서버에서 Exchange 2010 사서함 서버로

RPC. 클라이언트 액세스 서버 참고 사항를 참조하십시오.

Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

클라이언트 액세스 서버에서 클라이언트 액세스 서버로(Exchange ActiveSync)

80/TCP, 443/TCP(SSL)

Kerberos

Kerberos, 인증서

예, HTTPS 사용

예, 자체 서명 인증서 사용

클라이언트 액세스 서버에서 클라이언트 액세스 서버로(Outlook Web Access)

80/TCP, 443/TCP(HTTPS)

Kerberos

Kerberos

예, SSL 사용

예

클라이언트 액세스 서버에서 클라이언트 액세스 서버로(Exchange 웹 서비스)

443/TCP(HTTPS)

Kerberos

Kerberos

예, SSL 사용

예

클라이언트 액세스 서버에서 클라이언트 액세스 서버로(POP3)

995(SSL)

기본

기본

예, SSL 사용

예

클라이언트 액세스 서버에서 클라이언트 액세스 서버로(IMAP4)

993(SSL)

기본

기본

예, SSL 사용

예

Office Communications Server가 클라이언트 액세스 서버에 액세스(Office Communications Server 및 Outlook Web App 통합 사용 시)

5075-5077/TCP(IN), 5061/TCP(OUT)

mTLS(필수)

mTLS(필수)

예, SSL 사용

예

참고

통합된 Windows 인증(NTLM)은 POP3 또는 IMAP4 클라이언트 연결에 지원되지 않습니다. 자세한 내용은 더 이상 지원하지 않는 기능에서 "클라이언트 액세스 기능" 섹션을 참조하십시오.

클라이언트 액세스 서버 참고 사항

  • Exchange 2010에서 Microsoft Outlook과 같은 MAPI 클라이언트는 클라이언트 액세스 서버에 연결합니다.

  • 클라이언트 액세스 서버는 여러 포트를 사용하여 사서함 서버와 통신합니다. 몇 가지 예외를 제외하면 사용되는 포트는 RPC 서비스에서 결정하며 변동될 수 있습니다.

  • 협상 항목이 있는 HTTP 인증의 경우 Kerberos가 먼저 시도된 후에 NTLM이 시도됩니다.

  • Exchange 2010 클라이언트 액세스 서버가 MicrosoftExchange Server 2003을 실행하는 사서함 서버와 통신하는 경우에는 NTLM 인증과 기본 인증을 사용하지 않도록 설정하고 Kerberos를 사용하는 것이 좋습니다. 또한 신뢰할 수 있는 인증서로 폼 기반 인증을 사용하도록 Outlook Web App를 구성하는 것이 좋습니다. Exchange ActiveSync 클라이언트가 Exchange 2010 클라이언트 액세스 서버를 통해 Exchange 2003 백 엔드 서버와 통신하려면 Windows 통합 인증을 Exchange 2003 백 엔드 서버의 Microsoft-Server-ActiveSync 가상 디렉터리에서 사용하도록 설정해야 합니다. Exchange 2003 서버에서 Exchange System Manager를 사용하여 Exchange 2003 가상 디렉터리에서 인증을 관리하려면 Microsoft 기술 자료 문서 937031, 모바일 장치가 Exchange 2007 server에 연결되어 Exchange 2003 백 엔드 서버의 사서함을 액세스하는 경우 CAS 역활이 실행 중인 Exchange 2007 server에 이벤트 ID 1036이 기록됩니다.에서 참조한 핫픽스를 다운로드하고 설치합니다. 

    참고

    이 기술 자료 문서는 MicrosoftExchange Server 2007과 관련이 있지만 Exchange 2010에도 적용될 수 있습니다.

  • 클라이언트 액세스 서버가 POP3 요청을 다른 클라이언트 액세스 서버로 프록시 처리하면 포트 995/TCP를 통해 통신이 이루어집니다. 연결하는 클라이언트가 POP3를 사용하고 TLS를 요청하는 경우(포트 110/TCP)나 SSL을 사용하여 포트 995/TCP에 요청하는 경우 모두 마찬가지입니다. 마찬가지로 IMAP4 연결의 경우 포트 993/TCP는 연결 클라이언트가 포트 443/TCP에서 IMAP4를 사용하여 TLS를 요청하는지 또는 포트 995에서 SSL 암호화가 지원되는 IMAP4를 사용하는지 여부에 관계없이 요청을 프록시하는 데 사용됩니다.

클라이언트 액세스 서버 연결

사서함 서버가 포함된 모든 Active Directory 사이트에 클라이언트 액세스 서버가 있어야 하며 Exchange 서버 간의 트래픽 제한을 방지해야 합니다. Exchange에서 사용하는 모든 정의된 포트가 모든 원본 서버와 대상 서버 간에 양방향으로 열려 있는지 확인해야 합니다. Exchange 서버 간이나, Exchange 2010 사서함 또는 클라이언트 액세스 서버와 Active Directory 간에는 방화벽을 설치할 수 없습니다. 그러나 트래픽이 제한되어 있지 않고 다양한 Exchange 서버와 Active Directory 사이에 사용 가능한 모든 포트가 열려 있는 경우 네트워크 장치를 설치할 수 있습니다.

통합 메시징 서버

IP 게이트웨이 및 IP PBX는 SIP 트래픽 암호화용 상호 TLS를 사용하는 인증서 기반 인증 및 SIP(Session Initiation Protocol)/TCP 연결용 IP 기반 인증만 지원합니다. IP 게이트웨이에서는 NTLM 또는 Kerberos 인증이 지원되지 않습니다. 그러므로 IP 기반 인증을 사용하는 경우에는 연결되는 IP 주소를 사용하여 암호화되지 않은 TCP 연결에 인증 메커니즘을 제공하게 됩니다. UM(통합 메시징)에 IP 기반 인증을 사용하는 경우 UM 서버에서 해당 IP 주소에 대한 연결이 허용되는지를 확인합니다. IP 주소는 IP 게이트웨이 또는 IP PBX에서 구성됩니다.

IP 게이트웨이 및 IP PBX는 SIP 트래픽 암호화용 상호 TLS를 지원합니다. 신뢰할 수 있는 인증서를 필요한 만큼 가져오고 내보낸 후에는 IP 게이트웨이 또는 IP PBX가 UM 서버에서 인증서를 요청한 다음 IP 게이트웨이 또는 IP PBX에서 인증서를 요청합니다. IP 게이트웨이 또는 IP PBX와 UM 서버 간에 신뢰할 수 있는 인증서를 교환하면 IP 게이트웨이 또는 IP PBX와 UM 서버에서 상호 TLS를 사용하여 암호화된 연결을 통해 통신할 수 있습니다.

다음 표에서는 UM 서버와 다른 서버 간의 포트, 인증 및 데이터 경로 암호화에 대한 정보를 제공합니다.

통합 메시징 서버 데이터 경로

데이터 경로 필요한 포트 기본 인증 지원되는 인증 암호화 지원 여부 암호화 작업 기본 수행 여부

Active Directory 액세스

389/TCP/UDP(LDAP), 3268/TCP(LDAP GC), 88/TCP/UDP(Kerberos), 53/TCP/UDP(DNS), 135/TCP(RPC netlogon)

Kerberos

Kerberos

예, Kerberos 암호화 사용

예

통합 메시징 전화 상호 작용(IP PBX/VoIP 게이트웨이)

5060/TCP, 5065/TCP, 5067/TCP(보안되지 않음), 5061/TCP, 5066/TCP, 5068/TCP(보안), 16000-17000/TCP 범위의 동적 포트(제어), 1024-65535/UDP 범위의 동적 UDP 포트(RTP)

IP 주소별

IP 주소별, MTLS

예, SIP/TLS, SRTP 사용

아니요

통합 메시징 웹 서비스

80/TCP, 443/TCP(SSL)

통합된 Windows 인증(협상)

기본, 다이제스트, NTLM, 협상(Kerberos)

예, SSL 사용

예

통합 메시징 서버에서 클라이언트 액세스 서버로

5075, 5076, 5077(TCP)

통합된 Windows 인증(협상)

기본, 다이제스트, NTLM, 협상(Kerberos)

예, SSL 사용

예

통합 메시징 서버에서 클라이언트 액세스 서버로(전화에서 재생)

동적 RPC

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

통합 메시징 서버에서 허브 전송 서버로

25/TCP(TLS)

Kerberos

Kerberos

예, TLS 사용

예

통합 메시징 서버에서 사서함 서버로

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예, RPC 암호화 사용

예

통합 메시징 서버 참고 사항

  • Active Directory에서 UM IP 게이트웨이 개체를 만들 때는 실제 IP 게이트웨이 또는 IP PBX(Private Branch eXchange)의 IP 주소를 정의해야 합니다. UM IP 게이트웨이 개체에 IP 주소를 정의하면 UM 서버가 통신하도록 허용된 유효한 IP 게이트웨이 또는 IP PBX(SIP 피어라고도 함) 목록에 해당 IP 주소가 추가됩니다. UM IP 게이트웨이를 만들면 이를 UM 다이얼 플랜과 연결할 수 있습니다. UM IP 게이트웨이를 다이얼 플랜과 연결하면 해당 다이얼 플랜과 연결된 통합 메시징 서버가 IP 기반 인증을 사용하여 IP 게이트웨이와 통신할 수 있습니다. UM IP 게이트웨이를 만들지 않았거나 올바른 IP 주소를 사용하도록 게이트웨이를 구성하지 않은 경우에는 인증이 실패하고 UM 서버는 해당 IP 게이트웨이 IP 주소로부터의 연결을 수락하지 않습니다. 또한 상호 TLS 및 IP 게이트웨이 또는 IP PBX 및 UM 서버를 구현할 때 FQDN을 사용하도록 UM IP 게이트웨이를 구성해야 합니다. FQDN으로 UM IP 게이트웨이를 구성한 후에는 또한 UM IP 게이트웨이의 DNS 정방향 조회 영역에 호스트 레코드를 추가해야 합니다.

  • Exchange 2010에서 UM 서버는 포트 5060/TCP(보안되지 않음) 또는 포트 5061/TCP(보안)에서 통신하거나 둘 다를 사용하도록 구성될 수 있습니다.

자세한 내용은 통합 메시징 VoIP 보안 이해 및 통합 메시징의 프로토콜, 포트 및 서비스 이해를 참조하십시오.

Exchange 2010 설치 프로그램에서 만들어지는 Windows 방화벽 규칙

고급 보안이 포함된 Windows 방화벽은 방화벽 규칙에 기반하여 인바운드 및 아웃바운드 트래픽을 필터링하는 상태 저장 호스트 기반 방화벽입니다. Exchange 2010 설치 프로그램은 각 서버 역할에서 서버와 클라이언트의 통신에 필요한 포트를 열기 위한 Windows 방화벽 규칙을 만듭니다. 따라서 더 이상 SCW(보안 구성 마법사)를 사용하여 이러한 설정을 구성하지 않아도 됩니다. 고급 보안이 포함된 Windows 방화벽에 대한 자세한 내용은 고급 보안이 포함된 Windows 방화벽 및 IPsec을 참조하십시오.

이 표에는 Exchange 설치 프로그램에서 만들어지는 Windows 방화벽 규칙이 나와 있습니다(예: 각 서버 역할에서 열리는 포트). 고급 보안이 포함된 Windows 방화벽 MMC 스냅인을 사용하여 이러한 규칙을 볼 수 있습니다.

규칙 이름 서버 역할 포트 프로그램

MSExchangeADTopology - RPC(TCP-In)

클라이언트 액세스, 허브 전송, 사서함, 통합 메시징

동적 RPC

Bin\MSExchangeADTopologyService.exe

MSExchangeMonitoring - RPC(TCP-In)

클라이언트 액세스, 허브 전송, Edge 전송, 통합 메시징

동적 RPC

Bin\Microsoft.Exchange.Management.Monitoring.exe

MSExchangeServiceHost - RPC(TCP-In)

모든 역할

동적 RPC

Bin\Microsoft.Exchange.ServiceHost.exe

MSExchangeServiceHost - RPCEPMap(TCP-In)

모든 역할

RPC-EPMap

Bin\Microsoft.Exchange.Service.Host

MSExchangeRPCEPMap(GFW)(TCP-In)

모든 역할

RPC-EPMap

모두

MSExchangeRPC(GFW)(TCP-In)

클라이언트 액세스, 허브 전송, 사서함, 통합 메시징

동적 RPC

모두

MSExchange - IMAP4(GFW)(TCP-In)

클라이언트 액세스

143, 993(TCP)

모두

MSExchangeIMAP4(TCP-In)

클라이언트 액세스

143, 993(TCP)

ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe

MSExchange - POP3(FGW)(TCP-In)

클라이언트 액세스

110, 995(TCP)

모두

MSExchange - POP3(TCP-In)

클라이언트 액세스

110, 995(TCP)

ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe

MSExchange - OWA(GFW)(TCP-In)

클라이언트 액세스

5075, 5076, 5077(TCP)

모두

MSExchangeOWAAppPool(TCP-In)

클라이언트 액세스

5075, 5076, 5077(TCP)

Inetsrv\w3wp.exe

MSExchangeAB-RPC(TCP-In)

클라이언트 액세스

동적 RPC

Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RPCEPMap(TCP-In)

클라이언트 액세스

RPC-EPMap

Bin\Microsoft.Exchange.AddressBook.Service.exe

MSExchangeAB-RpcHttp(TCP-In)

클라이언트 액세스

6002, 6004(TCP)

Bin\Microsoft.Exchange.AddressBook.Service.exe

RpcHttpLBS(TCP-In)

클라이언트 액세스

동적 RPC

System32\Svchost.exe

MSExchangeRPC - RPC(TCP-In)

클라이언트 액세스, 사서함

동적 RPC

Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC - PRCEPMap(TCP-In)

클라이언트 액세스, 사서함

RPC-EPMap

Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeRPC(TCP-In)

클라이언트 액세스, 사서함

6001(TCP)

Bin\Microsoft.Exchange.RpcClientAccess.Service.exe

MSExchangeMailboxReplication(GFW)(TCP-In)

클라이언트 액세스

808(TCP)

모두

MSExchangeMailboxReplication(TCP-In)

클라이언트 액세스

808(TCP)

Bin\MSExchangeMailboxReplication.exe

MSExchangeIS - RPC(TCP-In)

사서함

동적 RPC

Bin\Store.exe

MSExchangeIS RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\Store.exe

MSExchangeIS(GFW)(TCP-In)

사서함

6001, 6002, 6003, 6004(TCP)

모두

MSExchangeIS(TCP-In)

사서함

6001(TCP)

Bin\Store.exe

MSExchangeMailboxAssistants - RPC(TCP-In)

사서함

동적 RPC

Bin\MSExchangeMailboxAssistants.exe

MSExchangeMailboxAssistants - RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSExchangeMailboxAssistants.exe

MSExchangeMailSubmission - RPC(TCP-In)

사서함

동적 RPC

Bin\MSExchangeMailSubmission.exe

MSExchangeMailSubmission - RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSExchangeMailSubmission.exe

MSExchangeMigration - RPC(TCP-In)

사서함

동적 RPC

Bin\MSExchangeMigration.exe

MSExchangeMigration - RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSExchangeMigration.exe

MSExchangerepl - 로그 복사기(TCP-In)

사서함

64327(TCP)

Bin\MSExchangeRepl.exe

MSExchangerepl - RPC(TCP-In)

사서함

동적 RPC

Bin\MSExchangeRepl.exe

MSExchangerepl - RPC-EPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSExchangeRepl.exe

MSExchangeSearch - RPC(TCP-In)

사서함

동적 RPC

Bin\Microsoft.Exchange.Search.ExSearch.exe

MSExchangeThrottling - RPC(TCP-In)

사서함

동적 RPC

Bin\MSExchangeThrottling.exe

MSExchangeThrottling - RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSExchangeThrottling.exe

MSFTED - RPC(TCP-In)

사서함

동적 RPC

Bin\MSFTED.exe

MSFTED - RPCEPMap(TCP-In)

사서함

RPC-EPMap

Bin\MSFTED.exe

MSExchangeEdgeSync - RPC(TCP-In)

허브 전송

동적 RPC

Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeEdgeSync - RPCEPMap(TCP-In)

허브 전송

RPC-EPMap

Bin\Microsoft.Exchange.EdgeSyncSvc.exe

MSExchangeTransportWorker - RPC(TCP-In)

허브 전송

동적 RPC

Bin\edgetransport.exe

MSExchangeTransportWorker - RPCEPMap(TCP-In)

허브 전송

RPC-EPMap

Bin\edgetransport.exe

MSExchangeTransportWorker(GFW)(TCP-In)

허브 전송

25, 587(TCP)

모두

MSExchangeTransportWorker(TCP-In)

허브 전송

25, 587(TCP)

Bin\edgetransport.exe

MSExchangeTransportLogSearch - RPC(TCP-In)

허브 전송, Edge 전송, 사서함

동적 RPC

Bin\MSExchangeTransportLogSearch.exe

MSExchangeTransportLogSearch - RPCEPMap(TCP-In)

허브 전송, Edge 전송, 사서함

RPC-EPMap

Bin\MSExchangeTransportLogSearch.exe

SESWorker(GFW)(TCP-In)

통합 메시징

모두

모두

SESWorker(TCP-In)

통합 메시징

모두

UnifiedMessaging\SESWorker.exe

UMService(GFW)(TCP-In)

통합 메시징

5060, 5061

모두

UMService(TCP-In)

통합 메시징

5060, 5061

Bin\UMService.exe

UMWorkerProcess(GFW)(TCP-In)

통합 메시징

5065, 5066, 5067, 5068

모두

UMWorkerProcess(TCP-In)

통합 메시징

5065, 5066, 5067, 5068

Bin\UMWorkerProcess.exe

UMWorkerProcess - RPC(TCP-In)

통합 메시징

동적 RPC

Bin\UMWorkerProcess.exe

Exchange 2010 설치 프로그램에서 만들어지는 Windows 방화벽 규칙에 대한 참고 사항

  • 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 끝점 매퍼에 연결하여 서버 프로세서에서 사용하는 끝점을 확인합니다. 기본적으로 RPC 끝점 매퍼는 포트 135(TCP)에서 수신 대기합니다. RPC를 사용하는 프로세스에 대해 Windows 방화벽을 구성하면 Exchange 2010 설치 프로그램이 이 프로세스에 대해 두 가지 방화벽 규칙을 만듭니다. 한 규칙은 RPC 끝점 매퍼와의 통신을 허용하고 다른 규칙은 동적으로 할당된 끝점과의 통신을 허용합니다. RPC에 대한 자세한 내용은 RPC 작동 방식을 참조하십시오. 동적 RPC용 Windows 방화벽 규칙 만들기에 대한 자세한 내용은 동적 RPC를 사용하는 인바운드 네트워크 트래픽 허용을 참조하십시오.

참고

Exchange 2010 설치 프로그램에서 만든 Windows 방화벽 규칙은 수정할 수 없습니다. 이 규칙을 기반으로 사용자 지정 규칙을 만든 다음 사용하지 않도록 설정하거나 삭제할 수 있습니다.

자세한 내용은 Microsoft 기술 자료 문서 179442, 도메인 및 트러스트를 위한 방화벽을 구성하는 방법을 참조하십시오.

 © 2010 Microsoft Corporation. 모든 권리 보유.