Office 365용 ExpressRoute를 사용한 라우팅

아티클
04/28/2022
읽는 데 15분 걸림

이 문서는 Microsoft 365 Enterprise와 Office 365 Enterprise에 모두 적용됩니다.

Azure ExpressRoute를 사용하여 Office 365 라우팅 트래픽을 제대로 이해하려면 핵심 ExpressRoute 라우팅 요구 사항과 ExpressRoute 회로 및 라우팅 도메인에 대한 확고한 이해가 필요합니다. 이는 고객이 의존할 Office 365 ExpressRoute 사용에 대한 기본 사항을 설명합니다.

이해해야 하는 위 문서의 주요 항목 중 일부는 다음과 같습니다.

ExpressRoute 회로는 특정 물리적 인프라에 매핑되지 않지만 Microsoft 및 사용자 대신 피어링 공급자가 단일 피어링 위치에서 만든 논리적 연결입니다.
ExpressRoute 회로와 고객 s-key 간에는 1:1 매핑이 있습니다.
각 회로는 두 개의 독립적인 피어링 관계(Azure 프라이빗 피어링 및 Microsoft 피어링)를 지원할 수 있습니다. Office 365 Microsoft 피어링이 필요합니다.
각 회로에는 모든 피어링 관계에서 공유되는 고정 대역폭이 있습니다.
ExpressRoute 회로에 사용할 공용 IPv4 주소 및 공용 AS 번호는 사용자가 소유하거나 주소 범위의 소유자가 귀하에게 독점적으로 할당한 것으로 유효성을 검사해야 합니다.
가상 ExpressRoute 회로는 전역적으로 중복되며 표준 BGP 라우팅 방법을 따릅니다. 따라서 활성/활성 구성에서 공급자에게 송신당 두 개의 물리적 회로를 사용하는 것이 좋습니다.

지원되는 서비스, 비용 및 구성 세부 정보에 대한 자세한 내용은 FAQ 페이지를 참조하세요. Microsoft 피어링 지원을 제공하는 연결 공급자 목록에 대한 자세한 내용은 ExpressRoute 위치 문서를 참조하세요. 또한 10부로 구성된 Azure ExpressRoute for Office 365 Training 시리즈를 Channel 9에 기록하여 개념을 보다 철저하게 설명했습니다.

경로 대칭 확인

Office 365 프런트 엔드 서버는 인터넷과 ExpressRoute 모두에서 액세스할 수 있습니다. 이러한 서버는 둘 다 사용할 수 있는 경우 ExpressRoute 회로를 통해 온-프레미스로 다시 라우팅하는 것을 선호합니다. 이 때문에 네트워크의 트래픽이 인터넷 회로를 통해 라우팅하는 것을 선호하는 경우 경로 비대칭이 발생할 수 있습니다. 상태 저장 패킷 검사를 수행하는 디바이스는 다음에 나오는 아웃바운드 패킷과 다른 경로를 따르는 반환 트래픽을 차단할 수 있기 때문에 비대칭 경로는 문제가 됩니다.

인터넷 또는 ExpressRoute를 통해 Office 365 연결을 시작하든 관계없이 원본은 공개적으로 라우팅 가능한 주소여야 합니다. 많은 고객이 Microsoft와 직접 피어링하므로 고객 간에 중복이 가능한 개인 주소가 있는 것은 불가능합니다.

다음은 Office 365 온-프레미스 네트워크로의 통신이 시작되는 시나리오입니다. 네트워크 디자인을 간소화하려면 인터넷 경로를 통해 다음을 라우팅하는 것이 좋습니다.

Exchange Online 테넌트에서 온-프레미스 호스트로의 메일 또는 SharePoint Online에서 온-프레미스 호스트로 전송된 SharePoint Online Mail과 같은 SMTP 서비스입니다. SMTP 프로토콜은 ExpressRoute 회로를 통해 공유되는 경로 접두사보다 Microsoft 네트워크 내에서 더 광범위하게 사용되며 ExpressRoute를 통해 온-프레미스 SMTP 서버를 보급하면 이러한 다른 서비스에서 오류가 발생합니다.
로그인에 대한 암호 유효성 검사 중 ADFS입니다.
Exchange Server 하이브리드 배포.
페더레이션된 하이브리드 검색을 SharePoint.
SharePoint 하이브리드 BCS.
하이브리드 및/또는 비즈니스용 Skype 페더레이션을 비즈니스용 Skype.
비즈니스용 Skype Cloud Connector.

Microsoft가 이러한 양방향 트래픽 흐름을 위해 네트워크로 다시 라우팅하려면 온-프레미스 디바이스에 대한 BGP 경로를 Microsoft와 공유해야 합니다. ExpressRoute를 통해 Microsoft에 경로 접두사 보급 시 다음 모범 사례를 따라야 합니다.

공용 인터넷 및 ExpressRoute를 통해 동일한 공용 IP 주소 경로 접두사로 보급하지 마세요. ExpressRoute를 통해 Microsoft에 대한 IP BGP 경로 접두사 광고는 인터넷에 전혀 보급되지 않는 범위에서 제공하는 것이 좋습니다. 사용 가능한 IP 주소 공간으로 인해 이 작업을 수행할 수 없는 경우 인터넷 회로보다 ExpressRoute를 통해 보다 구체적인 범위를 보급해야 합니다.
ExpressRoute 회로당 별도의 NAT IP 풀을 사용하고 인터넷 회로와 분리합니다.
Microsoft에 보급된 모든 경로는 ExpressRoute를 통해 네트워크에 보급되는 경로뿐만 아니라 Microsoft 네트워크의 모든 서버에서 네트워크 트래픽을 유치합니다. 라우팅 시나리오가 정의되고 팀에서 잘 이해되는 서버에 대한 경로만 보급합니다. 네트워크에서 여러 ExpressRoute 회로 각각에 별도의 IP 주소 경로 접두사 보급

ExpressRoute를 통해 라우팅되는 애플리케이션 및 기능 결정

Microsoft 피어링 라우팅 도메인을 사용하여 피어링 관계를 구성하고 적절한 액세스에 대한 승인을 받으면 ExpressRoute를 통해 사용할 수 있는 모든 PaaS 및 SaaS 서비스를 볼 수 있습니다. ExpressRoute용으로 설계된 Office 365 서비스는 BGP 커뮤니티 또는 경로 필터를 사용하여 관리할 수 있습니다.

Microsoft 피어링을 사용하여 사용할 수 있는 각 Office 365 기능은 애플리케이션 유형 및 FQDN별로 Office 365 엔드포인트 문서에 나열됩니다. 테이블에서 FQDN을 사용하는 이유는 고객이 PAC 파일 또는 기타 프록시 구성을 사용하여 트래픽을 관리할 수 있도록 하기 위한 것입니다. 예를 들어 PAC 파일과 같은 Office 365 엔드포인트 관리에 대한 가이드를 참조하세요.

일부 상황에서는 하나 이상의 하위 FQDN이 상위 수준 와일드카드 도메인과 다르게 보급되는 와일드카드 도메인을 사용했습니다. 일반적으로 와일드카드는 ExpressRoute 및 인터넷에 모두 보급되는 서버의 긴 목록을 나타내고, 대상의 작은 하위 집합은 인터넷에만 보급되거나 반대로 보급될 때 발생합니다. 차이점을 이해하려면 아래 표를 참조하세요.

이 표에는 인터넷에만 보급되는 하위 FQDN과 함께 인터넷과 Azure ExpressRoute 모두에 보급되는 와일드카드 FQDN이 표시됩니다.

ExpressRoute 및 인터넷 회로에 보급된 와일드카드 도메인	인터넷 회로에만 보급된 하위 FQDN
*.microsoftonline.com	click.email.microsoftonline.com portal.microsoftonline.com provisioningapi.microsoftonline.com adminwebservice.microsoftonline.com
*.officeapps.live.com	nexusRules.officeapps.live.com nexus.officeapps.live.com odc.officeapps.live.com odc.officeapps.live.com cdn.odc.officeapps.live.com ols.officeapps.live.com ocsredir.officeapps.live.com ocws.officeapps.live.com ocsa.officeapps.live.com

일반적으로 PAC 파일은 ExpressRoute 보급 엔드포인트에 네트워크 요청을 회로에 직접 보내고 다른 모든 네트워크 요청을 프록시에 보내기 위한 것입니다. 이와 같이 PAC 파일을 구성하는 경우 다음 순서로 PAC 파일을 작성합니다.

PAC 파일의 맨 위에 있는 위의 표에 있는 열 2의 하위 FQDN을 포함하여 프록시로 트래픽을 보냅니다. Office 365 엔드포인트 관리에 대한 문서에서 사용할 샘플 PAC 파일을 빌드했습니다.
첫 번째 섹션 아래 의 이 문서에서 ExpressRoute에 보급된 것으로 표시된 모든 FQDN을 포함하여 트래픽을 ExpressRoute 회로로 직접 보냅니다.
이 두 항목 아래에 다른 네트워크 엔드포인트 또는 규칙을 포함하여 프록시로 트래픽을 보냅니다.

이 표에는 Azure ExpressRoute 및 인터넷 회로에 보급되는 하위 FQDN과 함께 인터넷 회로에 보급되는 와일드카드 도메인이 표시됩니다. 위의 PAC 파일의 경우 아래 표의 열 2에 있는 FQDN은 참조된 링크에서 ExpressRoute에 보급되는 것으로 나열됩니다. 즉, 파일의 두 번째 항목 그룹에 포함됩니다.

인터넷 회로에만 보급된 와일드카드 도메인	ExpressRoute 및 인터넷 회로에 보급된 하위 FQDN
*.office.com	*.outlook.office.com home.office.com outlook.office.com portal.office.com www.office.com
*.office.net	agent.office.net
*.office365.com	outlook.office365.com smtp.office365.com
*.outlook.com	.protection.outlook.com .mail.protection.outlook.com autodiscover-<tenant>.outlook.com
*.windows.net	login.windows.net

인터넷 및 ExpressRoute를 통해 Office 365 트래픽 라우팅

선택한 Office 365 애플리케이션으로 라우팅하려면 여러 가지 주요 요소를 결정해야 합니다.

애플리케이션에 필요한 대역폭입니다. 조직에서 이를 결정하는 유일한 신뢰할 수 있는 방법은 기존 사용량을 샘플링하는 것입니다.
네트워크 트래픽이 네트워크를 벗어나게 하려는 송신 위치입니다. 성능에 영향을 주기 때문에 Office 365 연결에 대한 네트워크 대기 시간을 최소화할 계획입니다. 비즈니스용 Skype 실시간 음성 및 비디오를 사용하기 때문에 네트워크 대기 시간이 저하되기 쉽습니다.
네트워크 위치의 전체 또는 하위 집합이 ExpressRoute를 사용하도록 하려면
선택한 네트워크 공급자가 ExpressRoute를 제공하는 위치

이러한 질문에 대한 답변을 확인하면 대역폭 및 위치 요구 사항을 충족하는 ExpressRoute 회로를 프로비전할 수 있습니다. 더 많은 네트워크 계획 지원을 보려면 Office 365 네트워크 튜닝 가이드 및 Microsoft가 네트워크 성능 계획을 처리하는 방법에 대한 사례 연구를 참조하세요.

예제 1: 단일 지리적 위치

이 예제는 단일 지리적 위치를 가진 Trey Research라는 가상의 회사에 대한 시나리오입니다.

Trey Research의 직원은 보안 부서에서 회사 네트워크와 ISP 사이에 있는 아웃바운드 프록시 쌍에서 명시적으로 허용하는 인터넷의 서비스 및 웹 사이트에만 연결할 수 있습니다.

Trey Research는 Office 365 Azure ExpressRoute를 사용할 계획이며 콘텐츠 배달 네트워크로 향하는 트래픽과 같은 일부 트래픽은 Office 365 연결을 위해 ExpressRoute를 통해 라우팅할 수 없음을 인식합니다. 모든 트래픽은 기본적으로 프록시 디바이스로 이미 라우팅되므로 이러한 요청은 이전과 같이 계속 작동합니다. Trey Research는 Azure ExpressRoute 라우팅 요구 사항을 충족할 수 있다고 판단한 후 회로를 만들고, 라우팅을 구성하고, 새 ExpressRoute 회로를 가상 네트워크에 연결합니다. 기본 Azure ExpressRoute 구성이 설정되면 Trey Research는 게시하는 #2 PAC 파일을 사용하여 Office 365 연결을 위해 직접 ExpressRoute를 통해 고객별 데이터로 트래픽을 라우팅합니다.

다음 다이어그램과 같이 Trey Research는 라우팅 및 아웃바운드 프록시 구성 변경의 조합을 사용하여 인터넷을 통해 Office 365 트래픽 및 ExpressRoute를 통해 트래픽의 하위 집합을 라우팅해야 하는 요구 사항을 충족할 수 있습니다.

게시하는 #2 PAC 파일을 사용하여 Office 365 Azure ExpressRoute에 대한 별도의 인터넷 송신 지점을 통해 트래픽을 라우팅합니다.
클라이언트는 Trey Research의 프록시에 대한 기본 경로로 구성됩니다.

이 예제 시나리오에서 Trey Research는 아웃바운드 프록시 디바이스를 사용합니다. 마찬가지로, Office 365 Azure ExpressRoute를 사용하지 않는 고객은 잘 알려진 대용량 엔드포인트로 향하는 트래픽을 검사하는 비용에 따라 트래픽을 라우팅하는 데 이 기술을 사용할 수 있습니다.

Exchange Online, SharePoint Online 및 비즈니스용 Skype Online에 대한 가장 높은 볼륨 FQDN은 다음과 같습니다.

ExpressRoute 고객 에지 네트워크.

outlook.office365.com, outlook.office.com
<tenant-name>.sharepoint.com, <tenant-name>-my.sharepoint.com, <tenant-name>-<app>.sharepoint.com
*TCP가 아닌 트래픽에 대한 IP 범위와 함께 .Lync.com
*broadcast.officeapps.live.com, *excel.officeapps.live.com, *onenote.officeapps.live.com, *powerpoint.officeapps.live.com, view.officeapps.live.com, *visio.officeapps.live.com, *word-edit.officeapps.live.com, **word-view.officeapps.live.com, office.live.com

Windows 8 프록시 설정을 배포 및 관리하고 Office 365 프록시에 의해 제한되지 않도록 하는 방법에 대해 자세히 알아봅니다.

단일 ExpressRoute 회로를 사용하면 Trey Research에 대한 고가용성이 없습니다. ExpressRoute 연결을 제공하는 Trey의 중복 에지 디바이스 쌍이 실패하는 경우 장애 조치(failover)할 추가 ExpressRoute 회로가 없습니다. 인터넷으로 장애 조치(failover)하려면 수동 재구성이 필요하고 경우에 따라 새 IP 주소가 필요하므로 Trey Research는 곤경에 처하게 됩니다. Trey가 고가용성을 추가하려는 경우 가장 간단한 솔루션은 각 위치에 대한 ExpressRoute 회로를 추가하고 활성/활성 방식으로 회로를 구성하는 것입니다.

여러 위치가 있는 Office 365 대한 ExpressRoute 라우팅

ExpressRoute를 통해 Office 365 트래픽을 라우팅하는 마지막 시나리오는 훨씬 더 복잡한 라우팅 아키텍처의 기초입니다. 위치 수, 해당 위치가 있는 대륙 수, ExpressRoute 회로 수 등에 관계없이 일부 트래픽을 인터넷으로 라우팅할 수 있고 ExpressRoute를 통해 일부 트래픽을 라우팅할 수 있어야 합니다.

여러 지역에 여러 위치가 있는 고객을 위해 답변해야 하는 추가 질문은 다음과 같습니다.

모든 위치에 ExpressRoute 회로가 필요한가요? 비즈니스용 Skype Online을 사용하거나 SharePoint Online 또는 Exchange Online 대기 시간 민감도와 관련된 경우 각 위치에서 중복 쌍의 활성/활성 ExpressRoute 회로를 사용하는 것이 좋습니다. 자세한 내용은 비즈니스용 Skype 미디어 품질 및 네트워크 연결 가이드를 참조하세요.
특정 지역에서 ExpressRoute 회로를 사용할 수 없는 경우 Office 365 대상 트래픽을 어떻게 라우팅해야 하나요?
작은 위치가 많은 네트워크의 경우 트래픽을 통합하는 데 선호되는 방법은 무엇인가요?

이러한 각 문제는 고유한 네트워크와 Microsoft에서 사용할 수 있는 옵션을 평가해야 하는 고유한 과제를 제시합니다.

고려 사항	평가할 네트워크 구성 요소
둘 이상의 위치에 있는 회로	활성/활성 방식으로 구성된 최소 2개의 회로를 사용하는 것이 좋습니다. 비용, 대기 시간 및 대역폭 요구 사항을 비교해야 합니다. BGP 경로 비용, PAC 파일 및 NAT를 사용하여 여러 회로로 라우팅을 관리합니다.
ExpressRoute 회로가 없는 위치에서 라우팅	송신 및 DNS 확인은 Office 365 요청을 시작하는 사용자와 가까운 것이 좋습니다. DNS 전달을 사용하여 원격 사무실에서 적절한 엔드포인트를 검색할 수 있습니다. 원격 사무실의 클라이언트에는 ExpressRoute 회로에 대한 액세스를 제공하는 경로를 사용할 수 있어야 합니다.
소규모 사무실 통합	사용 가능한 대역폭 및 데이터 사용량을 신중하게 비교해야 합니다.

참고

물리적 위치에 관계없이 경로를 사용할 수 있는 경우 Microsoft는 인터넷을 통해 ExpressRoute를 선호합니다.

각 고유 네트워크에 대해 이러한 각 고려 사항을 고려해야 합니다. 다음은 예제입니다.

예제 2: 다중 지리적 위치

이 예제는 지리적 위치가 여러 개 있는 'Humongous Insurance'라는 가상의 회사에 대한 시나리오입니다.

Humongous 보험은 지리적으로 전 세계 사무실로 분산되어 있습니다. Office 365 Azure ExpressRoute를 구현하여 대부분의 Office 365 트래픽을 직접 네트워크 연결에 유지하려고 합니다. Humongous 보험은 또한 두 개의 추가 대륙에 사무실을 가지고 있습니다. ExpressRoute를 사용할 수 없는 원격 사무실의 직원은 ExpressRoute 연결을 사용하려면 기본 시설 중 하나 또는 둘 다로 다시 라우팅해야 합니다.

지침 원칙은 가능한 한 빨리 Microsoft 데이터 센터에 Office 365 전송되는 트래픽을 가져오는 것입니다. 이 예제에서 Humongous Insurance은 원격 사무실이 가능한 한 빨리 연결을 통해 Microsoft 데이터 센터에 액세스하도록 인터넷을 통해 라우팅해야 하는지 또는 원격 사무실이 ExpressRoute 연결을 통해 Microsoft 데이터 센터에 최대한 빨리 액세스하기 위해 내부 네트워크를 통해 라우팅해야 하는지 여부를 결정해야 합니다.

Microsoft의 데이터 센터, 네트워크 및 애플리케이션 아키텍처는 전 세계적으로 서로 다른 통신을 수행하고 가능한 가장 효율적인 방식으로 서비스를 제공하도록 설계되었습니다. 이것은 세계에서 가장 큰 네트워크 중 하나입니다. 필요 이상으로 고객 네트워크에 남아 있는 Office 365 대상으로 하는 요청은 이 아키텍처를 활용할 수 없습니다.

Humongous Insurance의 경우 ExpressRoute를 통해 사용하려는 애플리케이션에 따라 진행해야 합니다. 예를 들어 비즈니스용 Skype Online 고객이거나 외부 비즈니스용 Skype Online 모임에 연결할 때 ExpressRoute 연결을 사용하려는 경우 비즈니스용 Skype Online 미디어 품질 및 네트워크 연결 가이드에서 권장되는 디자인은 세 번째 위치에 대한 추가 ExpressRoute 회로를 프로비전하는 것입니다. 네트워킹 관점에서 보면 비용이 더 많이 들 수 있습니다. 그러나 Microsoft 데이터 센터에 전달하기 전에 한 대륙에서 다른 대륙으로 요청을 라우팅하면 비즈니스용 Skype Online 모임 및 통신 중에 사용이 좋지 않거나 사용할 수 없는 환경이 발생할 수 있습니다.

Humongous Insurance를 사용하지 않거나 비즈니스용 Skype Online을 어떤 식으로든 사용할 계획이 없는 경우 ExpressRoute 연결이 있는 대륙으로 Office 365 라우팅하는 것이 가능할 수 있지만 불필요한 대기 시간 또는 TCP 정체가 발생할 수 있습니다. 두 경우 모두 로컬 사이트에서 인터넷으로 향하는 인터넷 트래픽을 라우팅하는 것이 Office 365 의존하는 콘텐츠 배달 네트워크를 활용하는 것이 좋습니다.

ExpressRoute 다중 지리.

Humongous Insurance이 다중 지리 전략을 계획할 때 회로 크기, 회로 수, 장애 조치(failover) 등에 대해 고려해야 할 사항이 많이 있습니다.

ExpressRoute가 회로를 사용하려고 하는 여러 지역이 있는 단일 위치에 있는 Humongous Insurance은 원격 사무실에서 Office 365 연결이 가장 가까운 Office 365 데이터 센터로 전송되고 본사 위치에서 수신되도록 하려고 합니다. 이를 위해 Humongous Insurance는 본사 인터넷 송신 지점에 가장 가까운 Office 365 환경과의 적절한 연결을 설정하는 데 필요한 왕복 및 DNS 조회 수를 줄이기 위해 DNS 전달을 구현합니다. 이렇게 하면 클라이언트가 로컬 프런트 엔드 서버를 확인할 수 없으며, 사용자가 연결하는 Front-End 서버가 Humongous Insurance가 Microsoft와 피어링하는 본사 근처에 있는지 확인합니다. 도메인 이름에 조건부 전달자를 할당하는 방법도 알아볼 수 있습니다.

이 시나리오에서 원격 사무실의 트래픽은 북아메리카 Office 365 프런트 엔드 인프라를 확인하고 Office 365 사용하여 Office 365 애플리케이션의 아키텍처에 따라 백 엔드 서버에 연결합니다. 예를 들어 Exchange Online 북아메리카 연결을 종료하고 해당 프런트 엔드 서버는 테넌트가 있는 곳마다 백 엔드 사서함 서버에 연결합니다. 모든 서비스에는 유니캐스트 및 애니캐스트 대상으로 구성된 널리 분산된 Front Door 서비스가 있습니다.

여러 대륙에 주요 사무소가 있는 경우 비즈니스용 Skype Online과 같은 중요한 애플리케이션의 대기 시간을 줄이기 위해 지역당 최소 2개의 활성/활성 회로를 사용하는 것이 좋습니다. 모든 사무실이 단일 대륙에 있거나 실시간 협업을 사용하지 않는 경우 통합 또는 분산 송신 지점을 갖는 것은 고객별 결정입니다. 여러 회로를 사용할 수 있는 경우 BGP 라우팅은 단일 회로를 사용할 수 없게 되면 장애 조치(failover)를 보장합니다.

샘플 라우팅 구성 및 https://azure.microsoft.com/documentation/articles/expressroute-config-samples-nat/.

ExpressRoute를 사용하여 선택적 라우팅

ExpressRoute를 사용한 선택적 라우팅은 테스트, 사용자 하위 집합에 ExpressRoute 배포와 같은 다양한 이유로 필요할 수 있습니다. 고객이 ExpressRoute를 통해 Office 365 네트워크 트래픽을 선택적으로 라우팅하는 데 사용할 수 있는 다양한 도구가 있습니다.

경로 필터링/분리 - BGP 경로가 ExpressRoute를 통해 서브넷 또는 라우터의 하위 집합으로 Office 365 수 있도록 합니다. 이는 고객 네트워크 세그먼트 또는 실제 사무실 위치별로 선택적으로 라우팅됩니다. 이는 Office 365 ExpressRoute의 엄청난 롤아웃에 일반적이며 BGP 디바이스에 구성됩니다.
PAC 파일/URL - 특정 FQDN에 대한 Office 365 대상 네트워크 트래픽을 특정 경로로 라우팅하도록 지시합니다. 이렇게 하면 PAC 파일 배포에서 식별한 대로 클라이언트 컴퓨터별로 선택적으로 라우팅됩니다.
경로 필터링 - 경로 필터는 Microsoft 피어링을 통해 지원되는 서비스의 하위 집합을 사용하는 방법입니다.
BGP 커뮤니티 - BGP 커뮤니티 태그를 기반으로 필터링하면 고객이 ExpressRoute를 트래버스할 Office 365 애플리케이션과 인터넷을 트래버스할 애플리케이션을 결정할 수 있습니다.