다음을 통해 공유

데이터 경로 보안 참조

  • 아티클

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2009-06-05

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

전송 서버

Exchange 2007에는 다음과 같이 메시지 전송 기능을 수행하는 두 가지 서버 역할이 있습니다. 허브 전송 서버 및 Edge 전송 서버.

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

전송 서버 데이터 경로

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

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

25/TCP(TLS[전송 계층 보안])

Kerberos

Kerberos

예(TLS)

예

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

25/TCP(TLS)

직접 신뢰

직접 신뢰

예(TLS)

예

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

25/TCP(TLS)

직접 신뢰

직접 신뢰

예(TLS)

예

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

25/TCP(TLS), 389/TCP/UDP 및 80/TCP(인증서 인증)

익명, 인증서

익명, 인증서

예(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(TLS)

Kerberos

Kerberos

예(TLS)

예

Microsoft Exchange EdgeSync Service

50636/TCP(SSL), 50389/TCP(SSL 없음)

기본

기본

예(LDAPS)

예

Edge 전송 서버의 ADAM(Active Directory Application Mode) 디렉터리 서비스

50389/TCP(SSL 없음)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

허브 전송 서버에서 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 암호화)

예

허브 전송에 대한 최종 사용자 SMTP 클라이언트(예: Outlook Express)

25/TCP(TLS), 587(TLS)

NTLM/Kerberos

NTLM/Kerberos

예(TLS)

예

전송 서버 참고 사항

허브 전송 서버 간의 모든 트래픽은 Exchange 2007 설치 프로그램에서 기본적으로 설치되는 자체 서명 인증서와 TLS를 사용하여 암호화됩니다. 허브 전송 서버 간의 트래픽은 Kerberos 인증을 통해 인증됩니다.

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

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

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

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

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

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

다른 모든 스팸 방지 기능은 로컬 컴퓨터에서만 수집, 저장 및 액세스되는 데이터를 사용합니다. 받는 사람 필터링용 받는 사람 데이터나 수신 허용 목록 집계와 같은 데이터는 Microsoft Exchange EdgeSync Service를 통해 로컬 ADAM 디렉터리로 자주 전달됩니다.

저널링 및 메시지 분류는 허브 전송 서버에서 실행되며 Active Directory 데이터를 사용하여 작동합니다.

사서함 서버

사서함 서버 역할 컨텍스트에서 NTLM 또는 Kerberos 중 실제로 사용될 인증은 Exchange 비즈니스 논리 계층 소비자를 실행하는 프로세스 컨텍스트나 사용자에 따라 달라집니다. 이러한 컨텍스트에서 볼 때 소비자는 Exchange 비즈니스 논리 계층을 사용하는 모든 응용 프로그램 또는 프로세스입니다. 이 섹션에 있는 "사서함 서버 데이터 경로" 표에서 대부분의 "기본 인증" 셀에는 인증이 "NTLM/Kerberos"로 표기되어 있습니다.

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

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

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

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

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

사서함 서버 데이터 경로

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

CCR(클러스터 연속 복제) 및 SCR(대기 연속 복제) 로그 전달

445/TCP

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

CCR 및 SCR 시드

임의의 포트

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

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

SMB(로컬 메시지 블록)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

레거시 백업

임의의 포트

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

클러스터링

135/TCP(RPC), 이 표 다음에 나오는 "사서함 서버 참고 사항" 참조

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

MAPI 액세스

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예(RPC 암호화)

예

사서함 도우미

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

아니요

아니요

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

135/TCP(RPC)

NTLM/Kerberos

NTLM/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 암호화)

예

콘텐츠 인덱싱

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예(RPC 암호화)

예

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

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

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

445/TCP(SMB)

NTLM/Kerberos

NTLM/Kerberos

예(IPsec)

아니요

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

135/TCP(RPC)

Kerberos

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 암호화)

예

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 암호화)

예

Active Directory로의 DSAccess

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

Kerberos

Kerberos

예(Kerberos 암호화)

예

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

참고

Outlook 2003 이하 버전에 적용됩니다. 오프라인 주소록의 웹 배포 기능을 사용하도록 설정하지 않으면 Office Outlook 2007 클라이언트에도 적용됩니다.

135/TCP(RPC)

NTLM/Kerberos

NTLM/Kerberos

예(RPC 암호화)

예

WebDav

80/TCP, 443/TCP(SSL)

기본, NTLM, 협상

기본, NTLM, 협상

예(HTTPS)

예

사서함 서버 참고 사항

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

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

WebDav 응용 프로그램 또는 클라이언트는 80/TCP 또는 443/TCP를 사용하여 사서함 서버에 연결할 수 있지만 대부분의 경우 이러한 응용 프로그램 또는 클라이언트는 클라이언트 액세스 서버에 연결됩니다. 그러면 클라이언트 액세스 서버가 80/TCP 또는 443/TCP를 통해 사서함 서버에 연결됩니다.

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

클라이언트 액세스 서버

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

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

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

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

Autodiscover 서비스

80/TCP, 443/TCP(SSL)

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

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

예(HTTPS)

예

가용성 서비스

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

NTLM, Kerberos

예(HTTPS)

예

Outlook Web Access

80/TCP, 443/TCP(SSL)

폼 기반 인증

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

예(HTTPS)

예(자체 서명 인증서 사용)

POP3

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

기본, NTLM, Kerberos

기본, NTLM, Kerberos

예(SSL, TLS)

예

IMAP4

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

기본, NTLM, Kerberos

기본, NTLM, 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 주소별

예(TLS를 통한 SIP(Session Initiation Protocol))

예

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

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

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

예(IPsec)

아니요

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

RPC. 이 표 다음에 나오는 "클라이언트 액세스 서버 참고 사항" 참조

Kerberos

NTLM/Kerberos

예(RPC 암호화)

예

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

80/TCP, 443/TCP(SSL)

Kerberos

Kerberos, 인증서

예(HTTPS)

예(자체 서명 인증서 사용)

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

80/TCP, 443/TCP(SSL)

Kerberos

Kerberos

예(HTTPS)

예

WebDAV

80/TCP, 443/TCP(SSL)

HTTP 기본 또는 Outlook Web Access 폼 기반 인증

기본, Outlook Web Access 폼 기반 인증

예(HTTPS)

예

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

참고

오프라인 주소록의 웹 배포 기능을 사용하도록 설정하면 Office Outlook 2007에 적용됩니다.

80/TCP, 443/TCP(SSL)

NTLM/Kerberos

NTLM/Kerberos

예(HTTPS)

아니요

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

클라이언트 액세스 서버는 사서함 서버와 통신할 때 여러 포트를 사용합니다. 몇 가지 예외를 제외하면 사용되는 포트는 RPC(원격 프로시저 호출) 서비스에서 결정하며 변동될 수 있습니다. RPC 서비스에서 사용하는 동적 포트 범위를 지정할 수 있습니다. RPC 서비스에 사용되는 동적 포트 범위를 제한하는 방법에 대한 자세한 내용은 Microsoft 기술 자료 문서 154596, 방화벽에 사용할 RPC 동적 포트 할당을 구성하는 방법을 참조하십시오.

중요

방화벽이 같은 Active Directory 사이트에 있는 클라이언트 액세스 서버와 사서함 서버 간에 추가된 구성은 지원되지 않습니다.

중요

클라이언트 액세스 서버가 경계 네트워크에 설치된 구성도 지원되지 않습니다. 클라이언트 액세스 서버는 Active Directory 도메인의 구성원이어야 하며 클라이언트 액세스 서버 컴퓨터 계정은 Exchange Servers Active Directory 보안 그룹의 구성원이어야 합니다. Exchange Servers Active Directory 보안 그룹은 조직 내의 모든 Exchange 서버에 대한 읽기 및 쓰기 권한을 가집니다. 조직 내의 클라이언트 액세스 서버와 사서함 서버 간의 통신은 RPC 서비스를 통해 수행됩니다. 이는 경계 네트워크에는 클라이언트 액세스 서버를 설치할 수 없다는 사항 때문입니다.

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

Exchange 2007 클라이언트 액세스 서버가 Exchange 2003을 실행하는 사서함 서버와 통신하는 경우에는 NTLM 인증과 기본 인증을 사용하지 않도록 설정하고 Kerberos를 사용하는 것이 좋습니다. 또한 신뢰할 수 있는 인증서로 폼 기반 인증을 사용하도록 Outlook Web Access를 구성하는 것이 좋습니다. Exchange ActiveSync 클라이언트가 Exchange 2007 클라이언트 액세스 서버를 통해 Exchange 2003 백 엔드 서버와 통신하려면 Windows 통합 인증이 Exchange 2003 백 엔드 서버의 Microsoft-Server-ActiveSync 가상 디렉터리에서 사용되도록 설정되어야 합니다. Exchange 2003을 실행하는 서버에서 Exchange 시스템 관리자를 사용하여 Exchange 2003 가상 디렉터리에서 인증을 관리하려면 Microsoft 기술 자료 문서 937301, Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server(영문)에서 참조하는 핫픽스를 다운로드하고 설치합니다.

통합 메시징 서버

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

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

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

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

통합 메시징 팩스

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

IP 주소별

IP 주소별

SIP를 통한 TLS(미디어는 암호화되지 않음)

예(SIP의 경우)

통합 메시징 전화 상호 작용(PBX)

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

IP 주소별

IP 주소별

SIP를 통한 TLS(미디어는 암호화되지 않음)

예(SIP의 경우)

통합 메시징 웹 서비스

80/TCP, 443/TCP(SSL)

통합 Windows 인증(협상)

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

예(SSL)

예

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

25/TCP(SSL)

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 주소를 정의하면 통합 메시징 서버가 통신하도록 허용된 유효한 IP 게이트웨이 목록에 해당 IP 주소가 추가됩니다. UM IP 게이트웨이를 만들면 UM 다이얼 플랜과 연결됩니다. UM IP 게이트웨이를 다이얼 플랜과 연결하면 해당 다이얼 플랜과 연결된 통합 메시징 서버가 IP 기반 인증을 사용하여 IP 게이트웨이와 통신할 수 있습니다. UM IP 게이트웨이를 만들지 않았거나 올바른 IP 주소를 사용하도록 게이트웨이를 구성하지 않은 경우에는 인증이 실패하고 통합 메시징 서버는 해당 IP 게이트웨이 IP 주소로부터의 연결을 수락하지 않습니다.

원본 RTM(Release To Manufacturing) 버전의 Exchange 2007에서는 통합 메시징 서버가 5060/TCP(비보안) 포트 또는 5061/TCP(보안) 포트에서 통신할 수 있지만 두 포트 모두에서 통신할 수는 없습니다.

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

자세한 내용

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